ipv6: avoid write to a possibly cloned skb
authorFlorian Westphal <fw@strlen.de>
Mon, 13 Mar 2017 15:24:28 +0000 (16:24 +0100)
committerDavid S. Miller <davem@davemloft.net>
Mon, 13 Mar 2017 19:53:35 +0000 (12:53 -0700)
commit79e49503efe53a8c51d8b695bedc8a346c5e4a87
tree32f0df53aabe84ca5f00ed52967dc95e8aa1e868
parent6e526fdff7be4f13b24f929a04c0e9ae6761291e
ipv6: avoid write to a possibly cloned skb

ip6_fragment, in case skb has a fraglist, checks if the
skb is cloned.  If it is, it will move to the 'slow path' and allocates
new skbs for each fragment.

However, right before entering the slowpath loop, it updates the
nexthdr value of the last ipv6 extension header to NEXTHDR_FRAGMENT,
to account for the fragment header that will be inserted in the new
ipv6-fragment skbs.

In case original skb is cloned this munges nexthdr value of another
skb.  Avoid this by doing the nexthdr update for each of the new fragment
skbs separately.

This was observed with tcpdump on a bridge device where netfilter ipv6
reassembly is active:  tcpdump shows malformed fragment headers as
the l4 header (icmpv6, tcp, etc). is decoded as a fragment header.

Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Reported-by: Andreas Karis <akaris@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/ipv6/ip6_output.c