Date: Wed, 18 Apr 2012 08:40:03 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: <201204180840.q3I8e3BV073472@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: Wed, 18 Apr 2012 02:37:27 -0600 Did a bit of history review. When an ioctl goes through the linux = driver, it goes through a pool allocator to get a scratch buffer for the = command. The pool sizes are PAGE_SIZE (4K) and power-of-2 multiples = above that, up to 64k. So when an application requests a buffer size of = 0-4k, a 4k buffer gets sent to the card. A ~25k buffer request actually = gets 32k sent to the card. The firmware seems to exploit this and = basically ignores the specified length, happily filling the provided = buffer with whatever power-of-2 data count it feels like. According to = an old conversation with Dell and LSI, the LSI engineers consider this = to be a necessary feature, not a bug. As I mentioned previously, I fixed this as a special case of len=3D=3D0 = in the linux ioctl emulation path. Based on the bug report here, the = fix needs to be expanded to rounding up to power-of-2 sizes in both the = native and emulated paths. Anyone who wants to tackle this is welcome to do so. The existing hack = also suffers from bug in the form of it copying the 4k buffer back to = user land, even though userland specified a length of 0. This is = probably a bad thing, and it's something that linux appears to handle = correctly.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201204180840.q3I8e3BV073472>