Date: Thu, 16 Oct 2003 12:09:09 -0700 (PDT) From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: RE: cvs commit: src/sys/netinet ip_fw2.c Message-ID: <20031016115801.S38049@root.org> In-Reply-To: <XFMail.20031016143026.jhb@FreeBSD.org> References: <XFMail.20031016143026.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 16 Oct 2003, John Baldwin wrote: > On 16-Oct-2003 Kirk McKusick wrote: > > Modified files: > > sys/netinet ip_fw2.c > > Log: > > Malloc buckets of size 128 have been having their 64-byte offset > > trashed after being freed. This has caused several panics including > > kern/42277 related to soft updates. Jim Kuhn tracked the problem > > down to ipfw limit rule processing. In the expiry of dynamic rules, > > it is possible for an O_LIMIT_PARENT rule to be removed when it still > > has live children. When the children eventually do expire, a pointer > > to the (long gone) parent is dereferenced and a count decremented. > > Since this memory can, and is, allocated for other purposes (in the > > case of kern/42277 an inodedep structure), chaos ensues. The offset > > in question in inodedep is the offset of the 16 bit count field in > > the ipfw2 ipfw_dyn_rule. > > > > Submitted by: Jim Kuhn <jkuhn@sandvine.com> > > Reviewed by: "Evgueni V. Gavrilov" <aquatique@rusunix.org> > > Reviewed by: Ben Pfountz <netprince@vt.edu> > > MFC after: 1 week > > Wow, impressive find! I agree, but this is also aggravating. We need more maintainers hunting down their own problems. This problem was found in -stable and has been around for at least 14 months. I believe options INVARIANTS would have shown this earlier via mtrash_ctor() (if the subsystem had been testing under -current). -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031016115801.S38049>