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: > >> 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. > > So I built a new kernel with DEBUG_MEMGUARD. When > vm.memguard.desc="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. > > 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. > Try the patch at http://people.freebsd.org/~scottl/mps.memguard.diff I haven’t even compile tested it, so hopefully any mistakes are easy to fix and aren’t too embarrassing. The target array is an obvious culprit since it’s often indexed without bounds. If this doesn’t fix it then I’ll 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>