From: Patrick McHardy <kaber@trash.net>
To: Pavel Emelyanov <xemul@openvz.org>
Cc: Phil Oester <kernel@linuxace.com>, netdev@vger.kernel.org
Subject: Re: 2.6.25-rc: Null dereference in ip_defrag
Date: Mon, 17 Mar 2008 18:43:32 +0100 [thread overview]
Message-ID: <47DEADC4.4010609@trash.net> (raw)
In-Reply-To: <47DEACF7.10202@openvz.org>
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;
work as well?
next prev parent reply other threads:[~2008-03-17 17:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-17 17:00 2.6.25-rc: Null dereference in ip_defrag Phil Oester
2008-03-17 17:40 ` Pavel Emelyanov
2008-03-17 17:43 ` Patrick McHardy [this message]
2008-03-17 17:57 ` Denis V. Lunev
2008-03-17 17:51 ` Patrick McHardy
2008-03-17 19:40 ` Phil Oester
2008-03-18 7:53 ` Pavel Emelyanov
2008-03-18 9:51 ` Pavel Emelyanov
2008-03-20 0:39 ` Phil Oester
2008-03-20 14:47 ` Patrick McHardy
2008-03-20 15:30 ` Phil Oester
2008-03-20 15:33 ` Patrick McHardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47DEADC4.4010609@trash.net \
--to=kaber@trash.net \
--cc=kernel@linuxace.com \
--cc=netdev@vger.kernel.org \
--cc=xemul@openvz.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).