From owner-freebsd-bugs@FreeBSD.ORG Sun Sep 11 21:00:24 2011 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 DAB10106566B for ; Sun, 11 Sep 2011 21:00:24 +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 CA2068FC0C for ; Sun, 11 Sep 2011 21:00:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p8BL0Ohq088442 for ; Sun, 11 Sep 2011 21:00:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p8BL0O7J088441; Sun, 11 Sep 2011 21:00:24 GMT (envelope-from gnats) Date: Sun, 11 Sep 2011 21:00:24 GMT Message-Id: <201109112100.p8BL0O7J088441@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Andreas Longwitz 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: Andreas Longwitz List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Sep 2011 21:00:24 -0000 The following reply was made to PR kern/155658; it has been noted by GNATS. From: Andreas Longwitz To: bug-followup@freebsd.org Cc: Subject: Re: kern/155658: [amr] [patch] amr_ioctl(): call of malloc() causes memory corruption and panic Date: Sun, 11 Sep 2011 22:58:17 +0200 As John Baldwin pointed out to me, this problem is caused by overrunnig the memory buffer by a specific megarc command. Further analysis showed that indeed this happens. There are several commands leading megarc to acquire a buffer of 12868 bytes but in this case the controller always sends back 25412 bytes. That is the memory corruption. This problem can be patched in megarc, see ports/137938. But I have also seen seen sporadic situations like this: megarc wants a buffer of 36 bytes, but the controller sends 1k data back. Therefore I think it is the best to be on the safe side and allocate always a buffer big enough for all answers of the controller. The following patch now looks good for me: --- amr.c.orig 2010-02-11 19:34:06.000000000 +0100 +++ amr.c 2011-09-09 16:23:07.000000000 +0200 @@ -87,6 +87,7 @@ #include #define AMR_DEFINE_TABLES #include +#define MAX_AMR_IOCTL 25600 /* observed: 25412 */ SYSCTL_NODE(_hw, OID_AUTO, amr, CTLFLAG_RD, 0, "AMR driver parameters"); @@ -843,7 +844,7 @@ /* handle inbound data buffer */ if (au_length != 0 && au_cmd[0] != 0x06) { - if ((dp = malloc(au_length, M_AMR, M_WAITOK|M_ZERO)) == NULL) { + if ((dp = malloc(MAX_AMR_IOCTL, M_AMR, M_WAITOK|M_ZERO)) == NULL) { error = ENOMEM; goto out; } -- Dr. Andreas Longwitz Data Service GmbH Beethovenstr. 2A 23617 Stockelsdorf Amtsgericht Lübeck, HRB 318 BS Geschäftsführer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau