Message ID | 1480367886.18162.88.camel@edumazet-glaptop3.roam.corp.google.com |
---|---|
State | RFC, archived |
Delegated to: | David Miller |
Headers | show |
Eric Dumazet <eric.dumazet@gmail.com> wrote: > > Might be a bug added in commit daaa7d647f81f3 > > ("netfilter: ipv6: avoid nf_iterate recursion") > > > > Florian, what do you think of dropping a packet that presumably was > > mangled badly by nf_ct_frag6_queue() ? ipv4 definitely frees malformed packets. In general, I think netfilter should avoid 'silent' drops if possible and let skb continue, but of course such skbs should not be made worse as what we ate to begin with... > > (Like about 48 byte pulled :(, and/or skb->csum changed ) I think this warrants a review of ipv6 reassembly too, bug reported here is because ipv6 nf defrag is also done on output. > diff --git a/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c b/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c > index f7aab5ab93a5..508739a3ca2a 100644 > --- a/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c > +++ b/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c > @@ -65,9 +65,9 @@ static unsigned int ipv6_defrag(void *priv, > > err = nf_ct_frag6_gather(state->net, skb, > nf_ct6_defrag_user(state->hook, skb)); > - /* queued */ > - if (err == -EINPROGRESS) > - return NF_STOLEN; > + /* queued or mangled ... */ > + if (err) > + return (err == -EINPROGRESS) ? NF_STOLEN : NF_DROP; > > return NF_ACCEPT; Looks good, we'll need to change some of the errno return codes in nf_ct_frag6_gather to 0 though for this to work, which should not be too hard ;)
On Mon, 2016-11-28 at 22:34 +0100, Florian Westphal wrote: > Eric Dumazet <eric.dumazet@gmail.com> wrote: > > > Might be a bug added in commit daaa7d647f81f3 > > > ("netfilter: ipv6: avoid nf_iterate recursion") > > > > > > Florian, what do you think of dropping a packet that presumably was > > > mangled badly by nf_ct_frag6_queue() ? > > ipv4 definitely frees malformed packets. > In general, I think netfilter should avoid 'silent' drops if possible > and let skb continue, but of course such skbs should not be made worse > as what we ate to begin with... > > > > (Like about 48 byte pulled :(, and/or skb->csum changed ) > > I think this warrants a review of ipv6 reassembly too, bug reported here > is because ipv6 nf defrag is also done on output. ip6_frag_queue() definitely frees bad/mangled skbs() > Looks good, we'll need to change some of the errno return codes in > nf_ct_frag6_gather to 0 though for this to work, which should not be too > hard ;) If the goal is to let buggy packets pass, then we might need to undo changes in nf_ct_frag6_queue()
Eric Dumazet <eric.dumazet@gmail.com> wrote: > On Mon, 2016-11-28 at 22:34 +0100, Florian Westphal wrote: > > Eric Dumazet <eric.dumazet@gmail.com> wrote: > > > > Might be a bug added in commit daaa7d647f81f3 > > > > ("netfilter: ipv6: avoid nf_iterate recursion") > > > > > > > > Florian, what do you think of dropping a packet that presumably was > > > > mangled badly by nf_ct_frag6_queue() ? > > > > ipv4 definitely frees malformed packets. > > In general, I think netfilter should avoid 'silent' drops if possible > > and let skb continue, but of course such skbs should not be made worse > > as what we ate to begin with... > > > > > > (Like about 48 byte pulled :(, and/or skb->csum changed ) > > > > I think this warrants a review of ipv6 reassembly too, bug reported here > > is because ipv6 nf defrag is also done on output. > > > ip6_frag_queue() definitely frees bad/mangled skbs() Yes, sorry. nf_ct_frag6_queue is mostly derived from ip6_frag_queue so any bugs in one might also exist in other. Thats all I wanted to say here. I'll check this tomorrow. > > Looks good, we'll need to change some of the errno return codes in > > nf_ct_frag6_gather to 0 though for this to work, which should not be too > > hard ;) > > If the goal is to let buggy packets pass, then we might need to undo > changes in nf_ct_frag6_queue() It currently returns -EINVAL in cases where skb wasn't changed/altered (e.g. because it doesn't have a fragment header), so we should ACCEPT in that case. As for 'buggy' packet, I think its ok to mimic ip6_frag_queue, i.e. if it tosses returning NF_DROP under same circumstance seems ok. (Passing however will -- on ingress side -- cause snmp stat increments in ipv6 reassembly, this still might be desireable). I'll check where undo might be possible/not too hard. Thanks Eric for debugging this!
On Mon, 2016-11-28 at 23:19 +0100, Florian Westphal wrote: > It currently returns -EINVAL in cases where skb wasn't changed/altered > (e.g. because it doesn't have a fragment header), so we should ACCEPT in > that case. > Maybe nf_ct_frag6_queue() should return direct NF_ codes then ...
diff --git a/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c b/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c index f7aab5ab93a5..508739a3ca2a 100644 --- a/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c +++ b/net/ipv6/netfilter/nf_defrag_ipv6_hooks.c @@ -65,9 +65,9 @@ static unsigned int ipv6_defrag(void *priv, err = nf_ct_frag6_gather(state->net, skb, nf_ct6_defrag_user(state->hook, skb)); - /* queued */ - if (err == -EINPROGRESS) - return NF_STOLEN; + /* queued or mangled ... */ + if (err) + return (err == -EINPROGRESS) ? NF_STOLEN : NF_DROP; return NF_ACCEPT; }