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

Andreas Longwitz longwitz at
Sun Sep 11 21:00:24 UTC 2011

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

From: Andreas Longwitz <longwitz at>
To: bug-followup at
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 <dev/amr/amrvar.h>
  #include <dev/amr/amr_tables.h>
 +#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

More information about the freebsd-bugs mailing list