Re: memguard for mbufs (fwd)

From: Mike Silbersack <silby_at_silby.com>
Date: Mon, 27 Jun 2005 22:14:15 -0500 (CDT)
Here's a note I just sent to the people who have been experiencing "memory 
used after free" panics - if you're also affected, please try the 
described change as well.

Thanks,

Mike "Silby" Silbersack

---------- Forwarded message ----------
Date: Mon, 27 Jun 2005 22:13:21 -0500 (CDT)
From: Mike Silbersack <silby_at_silby.com>
To: Peter Holm <peter_at_holm.cc>
Cc: Andrey Chernov <ache_at_freebsd.org>, Thierry Herbelot <thierry_at_herbelot.com>
Subject: Re: memguard for mbufs


On Mon, 27 Jun 2005, Peter Holm wrote:

> On Mon, Jun 27, 2005 at 04:21:54AM -0500, Mike Silbersack wrote:
> 
>> 
>> When memguard trips (which I did test with a trivial mbuf overwrite),
>> it'll immediately trap and enter ddb - there will be no helpful message
>> about use after free or anything.  So, when that happens, take a trace.
>> Hopefully everyone will report the same backtrace, and we'll have our
>> culprit. :)
>> 
> 
> I have now been stress testing for 0+04:10:05 without any panics.
> 
> I'll let the test run the nite over. If I still don't get a panic I
> plan to add a second NIC and revert to the previous kernel. This may
> tell if the problem is related to the rl driver or not.
> 
> - Peter

Well, there's a reason for that.  Bosko doublechecked my original mbuf use 
after free patch and found an error.  I'll provide a "manual patch", since this 
is a three line change.

Go into kern_mbuf.c, and find the procedure mb_fini_pack:

static void
mb_fini_pack(void *mem, int size)
{
         struct mbuf *m;

         m = (struct mbuf *)mem;
#ifdef INVARIANTS
         trash_fini(m->m_ext.ext_buf, MCLBYTES);
#endif
         uma_zfree_arg(zone_clust, m->m_ext.ext_buf, NULL);
         m->m_ext.ext_buf = NULL;
         mbstat.m_mclusts += 1;  /* XXX */
#ifdef INVARIANTS
         trash_fini(mem, size);
#endif
}

Add those last three lines in, and everything should be peachy.

Those of you running the memguard patch will have to take that back off, of 
course.

The problem arose because there are three UMA zones - the mbuf zone, the clust 
zone, and the packet zone.  Well, under certain memory conditions, objects from 
the packet zone are freed back into the mbuf.  And, since I was only running 
the trash function on the mbuf and clust zones, this led to false errors when 
something from the packet zone was freed back to the mbuf zone.

Sorry for all the debugging time, I hope this fixes the issue.

Mike "Silby" Silbersack
Received on Tue Jun 28 2005 - 01:14:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:37 UTC