netdev - Re: KASAN: use-after-free Read in ipv6_gso_pull

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAF=yD-+VNTOqAQzOmOr-ReXSy-zOU33gN0AjZso_8jW3htya7g@mail.gmail.com>
Date:   Wed, 11 Jul 2018 12:08:35 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Jiri Benc <jbenc@...hat.com>
Cc:     syzbot+7b9ed9872dab8c32305d@...kaller.appspotmail.com,
        David Miller <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        LKML <linux-kernel@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        syzkaller-bugs@...glegroups.com,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: KASAN: use-after-free Read in ipv6_gso_pull_exthdrs

On Wed, Jul 11, 2018 at 6:07 AM Jiri Benc <jbenc@...hat.com> wrote:
>
> Sorry for the delayed reply, I'm working through a pile of stuff after
> being off.
>
> On Sun, 8 Jul 2018 18:58:14 -0400, Willem de Bruijn wrote:
> > Setting skb->mac_len to 0, similar to mpls_gs_segment,
> > is sufficient if the encapsulated packet is not ETH_P_TEB.
> >
> > If the packet is encapsulated at L2, __skb_pull(skb, vlan_depth)
> > has to pull the inner mac header before passing to l3 handlers like
> > inet_gso_segment.
> >
> > If that header includes VLAN tags, skb_network_protocol will
> > parse then and update the mac length in vlan_depth. So
> > hardcoding to ETH_HLEN should be fine:
> >
> > @@ -104,7 +95,7 @@ static struct sk_buff *nsh_gso_segment(struct sk_buff *skb,
> >         __skb_pull(skb, nsh_len);
> >
> >         skb_reset_mac_header(skb);
> > -       skb_reset_mac_len(skb);
> > +       skb->mac_len = proto == ETH_P_TEB ? ETH_HLEN : 0;
> >         skb->protocol = proto;
> >
> >         features &= NETIF_F_SG;
>
> I agree. I think my original intention was to set mac_len to 0. Which
> is obviously not done by calling skb_reset_mac_len...
>
> Strangely, skb_network_protocol does not set *depth to ETH_HLEN if it
> is 0 and the type is ETH_P_TEB, which is something I would expect it to
> do. Thus we indeed have to differentiate between the two cases before
> calling skb_mac_gso_segment.
>
> Willem, will you send the patch formally (with the htons fix)? Thanks a
> lot for the analysis and the patch!

Thanks for verifying, Jiri.

Posted as http://patchwork.ozlabs.org/patch/942588/. I forgot to cc:
you directly in git send-email, sorry.