Date: Tue, 4 Feb 2014 16:34:36 -0700 From: Scott Long <scott4long@yahoo.com> To: Garrett Wollman <wollman@csail.mit.edu> Cc: freebsd-stable@freebsd.org, "Kenneth D. Merry" <ken@freebsd.org>, "FreeBSD-scsi@freebsd.org" <freebsd-scsi@freebsd.org> Subject: Re: Heap overflow in mps(4) (was: Re: stable/9 mps(4) rev 254938 == BOOM!) Message-ID: <E775293C-C688-4174-A224-F35090C36BF9@yahoo.com> In-Reply-To: <21233.25909.355102.743155@khavrinen.csail.mit.edu> References: <21225.19508.683025.581620@khavrinen.csail.mit.edu> <201401292137.s0TLbD5G006716@hergotha.csail.mit.edu> <20140129221514.GA47535@nargothrond.kdm.org> <21225.38749.179621.454579@khavrinen.csail.mit.edu> <20140131003342.GA11755@nargothrond.kdm.org> <21233.25909.355102.743155@khavrinen.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 4, 2014, at 3:09 PM, Garrett Wollman <wollman@csail.mit.edu> = wrote: > <<On Thu, 30 Jan 2014 17:33:42 -0700, "Kenneth D. Merry" = <ken@freebsd.org> said: >=20 >> The fact that the redzone code doesn't expose any problems makes it = more >> likely that it is a problem other than a heap overflow. >=20 > So I built a new kernel with DEBUG_MEMGUARD. When > vm.memguard.desc=3D"mps", everything works fine both through two > load/unload cycles and statically compiled into the kernel. When > vm.memguard.desc is not set, instapanic as before. (I'm trying > memguard rather than redzone as it has much less of a performance > impact, so I can start doing some of the performance testing I was > originally intending to do. >=20 > Are there any debugging options that I could usefully enable that > would show just what mps is doing when the fault happens? I see that > there are lots of tracing options but I don't know what would actually > be useful. >=20 Try the patch at http://people.freebsd.org/~scottl/mps.memguard.diff I haven=92t even compile tested it, so hopefully any mistakes are easy = to fix and aren=92t too embarrassing. The target array is an obvious culprit = since it=92s often indexed without bounds. If this doesn=92t fix it then I=92ll have = to think of some other culprits. Another next step would be to further divide and = test the M_MPT2 malloc allocation type. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E775293C-C688-4174-A224-F35090C36BF9>