kern/155658: [amr] [patch] amr_ioctl(): call of malloc() causes memory corruption and panic

[Scott Long]

The following reply was made to PR kern/155658; it has been noted by GNATS.

From: Scott Long <scottl at samsco.org>
To: bug-followup at FreeBSD.org, longwitz at 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.=