lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 16 Sep 2015 17:30:56 +0200 From: Florian Westphal <fw@...len.de> To: David Woodhouse <dwmw2@...radead.org> Cc: Florian Westphal <fw@...len.de>, netdev <netdev@...r.kernel.org>, johannes@...solutions.net Subject: Re: IPv6 routing/fragmentation panic David Woodhouse <dwmw2@...radead.org> wrote: > > if (frag->len > mtu || > > ((frag->len & 7) && frag->next) || > > - skb_headroom(frag) < hlen) > > + skb_headroom(frag) < (hlen + hroom)) > > goto slow_path_clean; > > > > /* Partially cloned skb? */ > > My test is 'ping -s 2000', and I end up with a fragment of 1280 bytes > followed by a fragment of 776 bytes. > > The test cited above is only actually running on the latter fragment > (which for some reason is fine and has headroom of 58 bytes). > > The first, larger, fragment isn't being checked. And that's the one > with only 10 bytes of headroom. Thanks for this detailed analysis. I've sent a patch that should address all of these issues. Turns out that all tests are wrong in your case. ip6_fragment doesn't expand headroom, since this skb had the ipv6 fragment header pulled, so that part thinks there are 18 bytes available (we later push the frag header back when sending fragments). The 'skb_headroom(frag) < hlen))' is wrong since it neither accounts for device header length nor the fragment header that we need to push. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists