[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1205776662.27115.1.camel@iris.sw.ru>
Date: Mon, 17 Mar 2008 20:57:42 +0300
From: "Denis V. Lunev" <den@...nvz.org>
To: Patrick McHardy <kaber@...sh.net>
Cc: Pavel Emelyanov <xemul@...nvz.org>,
Phil Oester <kernel@...uxace.com>, netdev@...r.kernel.org
Subject: Re: 2.6.25-rc: Null dereference in ip_defrag
On Mon, 2008-03-17 at 18:43 +0100, Patrick McHardy wrote:
> Pavel Emelyanov wrote:
> > Phil Oester wrote:
> >> And the packets causing the problem are all multicast fragments being
> >> generated by Quagga's OSPFD (see debug output below). Tried manually generating
> >> some multicast fragments with iperf, but couldn't reproduce it.
> >>
> >> Any ideas?
> >
> > This is the same as the problem fixed here:
> >
> > commit 4136cd523eb0c0bd53173e16fd7406d31d05824f
> > [IPV4]: route: fix crash ip_route_input
> >
> > The sk_buff does not have a valid dev sometimes in ip_defrag() :(
> > and you have to setup conntrack rules to make packets go this way.
> > But unlike the above problem we cannot even trust the skb->dst to
> > be not NULL...
>
>
> We can on output. Usually we don't even see fragments in conntrack
> on output since we've defer fragmentation until all netfilter hooks
> have been processed. Quagga is generating fragments using raw sockets
> and IP_HDRINCL though.
>
> > Can you check with this patch, please (untested, but should work)?
>
> This is getting pretty ugly. Shouldn't
>
> int ip_defrag(struct sk_buff *skb, u32 user)
> {
> ...
> - net = skb->dev->nd_net;
> + net = skb->dev ? skb->dev->nd_net : skb->dst->dev->nd_net;
>>From my POW the we can just get skb->dst->dev. Could we?
I think that on IP level dealing with fragments we always have the
destination entry. I'll recheck this tomorrow.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists