Date: Sun, 25 Oct 1998 10:34:34 -0500 (EST) From: Brian Feldman <green@zone.syracuse.net> To: Doug Rabson <dfr@nlsystems.com> Cc: Don Lewis <Don.Lewis@tsc.tdk.com>, Kris Kennaway <kkennawa@physics.adelaide.edu.au>, wollman@khavrinen.lcs.mit.edu, current@FreeBSD.ORG Subject: Re: nestea v2 against freebsd 3.0-Release (fwd) Message-ID: <Pine.BSF.4.05.9810251033430.22721-100000@zone.syracuse.net> In-Reply-To: <Pine.BSF.4.01.9810251214110.366-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Here's _my_ patch:
insert in sys/netinet/ip_input.c:796
if (fp->ipq_frags == NULL) /* XXX */
goto dropfrag;
(hint: goes after the "next = 0;")
Cheers,
Brian Feldman
On Sun, 25 Oct 1998, Doug Rabson wrote:
> On Sun, 25 Oct 1998, Don Lewis wrote:
>
> > Ok, I figured out what's going on. When I compiled the nestea2.c under
> > FreeBSD, it didn't run at all because rip_output() does some sanity
> > checking between ip_len in the packet and the actual packet length, so
> > it doesn't send the third fragment and causes sendto() to return
> > EINVAL. The Linux emulation code in the kernel is kind enough to fix
> > ip_len, so the sanity check passes. Even after I fixed this in
> > nestea2.c, running it still didn't cause the system to panic. The
> > reason for this is some differences in byte swapping in the IP header
> > fields between Linux and FreeBSD that nestea2.c attempted to compensate
> > for, but didn't get right. Once I fixed the byte swapping problem, I
> > got the same panic you did, except for the linux emulation which I was
> > not using.
> >
> > The panic is caused by a bug in the new ip fragment reassembly code
> > that can be provoked into playing with an mbuf after it has been freed.
> > Here's a patch.
> >
> > --- ip_input.c.orig Fri Oct 23 02:17:19 1998
> > +++ ip_input.c Sun Oct 25 01:50:20 1998
> > @@ -750,7 +750,7 @@
> > * if they are completely covered, dequeue them.
> > */
> > for (; q != NULL && ip->ip_off + ip->ip_len > GETIP(q)->ip_off;
> > - p = q, q = nq) {
> > + q = nq) {
> > i = (ip->ip_off + ip->ip_len) -
> > GETIP(q)->ip_off;
> > if (i < GETIP(q)->ip_len) {
> >
>
> I don't understand how this patch works. Won't it end up using the wrong
> value for 'p' later on in the loop? Could you explain which mbuf is being
> used after its freed and in what circumstances.
>
> --
> Doug Rabson Mail: dfr@nlsystems.com
> Nonlinear Systems Ltd. Phone: +44 181 951 1891
> Fax: +44 181 381 1039
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9810251033430.22721-100000>