The following reply was made to PR kern/155658; it has been noted by GNATS.
From: Scott Long <[email protected]> To: [email protected], [email protected] 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.= _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
