netdev - Re: 2.6.25-rc: Null dereference in ip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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