From owner-freebsd-bugs@FreeBSD.ORG Tue Apr 17 20:10:05 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5A29106564A for ; Tue, 17 Apr 2012 20:10:05 +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 A02F28FC08 for ; Tue, 17 Apr 2012 20:10:05 +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 q3HKA5tX037836 for ; Tue, 17 Apr 2012 20:10:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3HKA5gq037835; Tue, 17 Apr 2012 20:10:05 GMT (envelope-from gnats) Date: Tue, 17 Apr 2012 20:10:05 GMT Message-Id: <201204172010.q3HKA5gq037835@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: Tue, 17 Apr 2012 20:10:05 -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: 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.