On Tue, 2016-11-29 at 02:17 +0100, Florian Westphal wrote:
> Dmitry Vyukov reported GPF in network stack that Andrey traced down to
> negative nh offset in nf_ct_frag6_queue().
>
> Problem is that all network headers before fragment header are pulled.
> Normal ipv6 reassembly will drop the skb when errors occur further down
> the line.
>
> netfilter doesn't do this, and instead passed the original fragment
> along. That was also fine back when netfilter ipv6 defrag worked with
> cloned fragments, as the original, pristine fragment was passed on.
>
> So we either have to undo the pull op, or discard such fragments.
> Since they're malformed after all (e.g. overlapping fragment) it seems
> preferrable to just drop them.
>
> Same for temporary errors -- it doesn't make sense to accept (and
> perhaps forward!) only some fragments of same datagram.
>
> Fixes: 029f7f3b8701cc7ac ("netfilter: ipv6: nf_defrag: avoid/free clone
> operations")
> Reported-by: Dmitry Vyukov <[email protected]>
> Debugged-by: Andrey Konovalov <[email protected]>
> Diagnosed-by: Eric Dumazet <Eric Dumazet <[email protected]>
> Signed-off-by: Florian Westphal <[email protected]>
> ---
> KASAN no longer complains, ping6 -s $bignum still works and gets picked up
> by ipv6 conntrack.
>
> Eric, I did think about changing nf_ct_frag6_gather but since its not a
> netfilter hook a hook retval doesn't seem to be appropriate (and also
> increases patch size).
Right, I guess nf_ prefix in its name is a bit misleading ;)
>
> This doesn't conflict with recent
> 'openvswitch: Fix skb leak in IPv6 reassembly' patch.
Seems fine to me, thanks !
Acked-by: Eric Dumazet <[email protected]>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
