From owner-freebsd-bugs@FreeBSD.ORG Wed Apr 18 08:40:04 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 24F9A1065670 for ; Wed, 18 Apr 2012 08:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0F9C08FC0A for ; Wed, 18 Apr 2012 08:40:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3I8e35j073473 for ; Wed, 18 Apr 2012 08:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3I8e3BV073472; Wed, 18 Apr 2012 08:40:03 GMT (envelope-from gnats) Date: Wed, 18 Apr 2012 08:40:03 GMT Message-Id: <201204180840.q3I8e3BV073472@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Scott Long Cc: Subject: Re: kern/155658: [amr] [patch] amr_ioctl(): call of malloc() causes memory corruption and panic X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Scott Long List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:40:04 -0000 The following reply was made to PR kern/155658; it has been noted by GNATS. From: Scott Long 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.=