All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bandan Das <bandan.das@stratus.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>,
	NetDev <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Patrick McHardy <kaber@trash.net>
Subject: Re: [PATCH net-next-2.6] net/ipv4: push IP options to CB in ip_fragment
Date: Mon, 30 Aug 2010 19:21:47 -0400	[thread overview]
Message-ID: <20100830232147.GB10754@stratus.com> (raw)
In-Reply-To: <1283204118.2405.32.camel@edumazet-laptop>

On  0, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le lundi 30 août 2010 à 16:09 -0400, Bandan Das a écrit :
> > The bridge layer can overwrite the IPCB using the
> > BR_INPUT_SKB_CB macro. In br_nf_dev_queue_xmit, 
> > if we recieve a packet greater in size than the bridge 
> > device MTU, we call ip_fragment which in turn will lead to 
> > icmp_send calling ip_options_echo if the DF flag is set. 
> > ip_options_echo will then incorrectly try to parse the IPCB as 
> > IP options resulting in a buffer overflow. 
> > This change refills the CB area back with IP 
> > options before ip_fragment calls icmp_send. If we fail parsing, 
> > we zero out the IPCB area to guarantee that the stack does 
> > not get corrupted.
> > 
> > Test setup that can exhibit this behavior:
> > <Remote Machine>--<Host Machine>--<Bridge>--<Tun/Tap>--<KVM Guest>
> >   1500 mtu          576 mtu        576 mtu   576 mtu    1500 mtu
> > 
> > Example of crash :
> > Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff8146dff3
> > Pid: 3173, comm: qemu-kvm Not tainted 2.6.32-63.el6.x86_64 #1
> > Call Trace:
> > Message from <IRQ>  syslogd@kvm at  [<ffffffff814c8285>] panic+0x78/0x137
> > Aug 30 14:09:50  [<ffffffff8146dff3>] ? icmp_send+0x743/0x780
> > 
> > Signed-off-by: Bandan Das <bandan.das@stratus.com>
> > ---
> >  net/ipv4/ip_output.c |   11 +++++++++++
> >  1 files changed, 11 insertions(+), 0 deletions(-)
> > 
> > diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> > index e427620..5fef4a9 100644
> > --- a/net/ipv4/ip_output.c
> > +++ b/net/ipv4/ip_output.c
> > @@ -445,6 +445,7 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
> >  	struct iphdr *iph;
> >  	int ptr;
> >  	struct net_device *dev;
> > +	struct ip_options *opt;
> >  	struct sk_buff *skb2;
> >  	unsigned int mtu, hlen, left, len, ll_rs;
> >  	int offset;
> > @@ -462,6 +463,16 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
> >  
> >  	if (unlikely((iph->frag_off & htons(IP_DF)) && !skb->local_df)) {
> >  		IP_INC_STATS(dev_net(dev), IPSTATS_MIB_FRAGFAILS);
> > +
> > +		/* Refill CB with IP options */
> > +		opt = &(IPCB(skb)->opt);
> > +		opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
> > +		if (ip_options_compile(dev_net(dev), opt, skb)) {
> > +			IP_INC_STATS(dev_net(dev), IPSTATS_MIB_INHDRERRORS);
> > +			/* If we fail, zero out IPCB and continue */
> > +			memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
> > +		}
> > +
> >  		icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
> >  			  htonl(ip_skb_dst_mtu(skb)));
> >  		kfree_skb(skb);
> 
> 
> I wonder if we want this.
> 
> Maybe setting skb->local_df = 1 in bridge should be enough ?
> 
> 
Thanks Eric for looking at this. Indeed, setting local_df to 1 seems to be enough! I will
respin and post a different patch.

-- 
Bandan Das

  reply	other threads:[~2010-08-30 23:24 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-30 20:09 [PATCH net-next-2.6] net/ipv4: push IP options to CB in ip_fragment Bandan Das
2010-08-30 21:35 ` Eric Dumazet
2010-08-30 23:21   ` Bandan Das [this message]
2010-08-31  5:20     ` Eric Dumazet
2010-08-31  5:20       ` Eric Dumazet
2010-08-31  8:24       ` Herbert Xu
2010-08-31  8:24         ` Herbert Xu
2010-08-31  9:17         ` Eric Dumazet
2010-08-31  9:17           ` Eric Dumazet
2010-08-31 12:36           ` Herbert Xu
2010-08-31 12:36             ` Herbert Xu
2010-08-31 13:13             ` Eric Dumazet
2010-08-31 13:13               ` Eric Dumazet
2010-08-31 13:50               ` Bandan Das
2010-09-01 16:57             ` Bandan Das
2010-09-03  4:49               ` Herbert Xu
2010-09-03  4:49                 ` Herbert Xu
2010-09-15 17:32                 ` Bandan Das
2010-09-17  6:51                   ` Herbert Xu
2010-09-17  6:51                     ` Herbert Xu
2010-09-17 23:43                     ` David Miller
2010-09-17 23:43                       ` David Miller
2010-09-19 19:36                       ` Bandan Das
2010-09-01 21:46       ` David Miller
2010-09-01 21:46         ` David Miller
2010-09-01 23:30         ` Herbert Xu
2010-09-01 23:30           ` Herbert Xu
2010-09-02  1:09           ` David Miller
2010-09-02  1:09             ` David Miller
2010-09-02  2:05             ` Bandan Das
2010-09-02  2:17               ` David Miller

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=20100830232147.GB10754@stratus.com \
    --to=bandan.das@stratus.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.