Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Apr 2012 20:10:05 GMT
From:      Scott Long <scottl@samsco.org>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/155658: [amr] [patch] amr_ioctl(): call of malloc() causes memory corruption and panic
Message-ID:  <201204172010.q3HKA5gq037835@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/155658; it has been noted by GNATS.

From: Scott Long <scottl@samsco.org>
To: bug-followup@FreeBSD.org, longwitz@incore.de
Cc:  
Subject: Re: kern/155658: [amr] [patch] amr_ioctl(): call of malloc() causes memory corruption and panic
Date: Tue, 17 Apr 2012 14:01:21 -0600

 Is the problem that the buffer in allocated to be too big, or too small?
 
 The bug report talks about a 36 byte buffer being requested from megarc, =
 but the firmware returning 1k instead.  If this is the bug that I'm =
 thinking, then it was fixed in the linux ioctl path a few years ago.  I =
 had hoped that megarc would never be compiled and run natively on =
 FreeBSD, so I didn't fix it in the native path.
 
 The fix is to always allocate a minimum of 4k and attach it to the =
 command sent to the card, but only copy back to user land the length =
 that the ioctl requests.  This is what linux does.  It's a bug in the =
 megaraid firmware, and it's a bug in megarc, and I had hoped that LSI =
 would be better than this.  Note that the linux ioctl path in the driver =
 that I mentioned only does this as a special case when the length is 0.  =
 It sounds like it needs to be done for all cases of min(au_lenth, 4096).
 
 I'm not sure why there's a discussion on max length; if I'm not =
 understanding the problem, please let me know.
 
 
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201204172010.q3HKA5gq037835>