linux-kernel - Re: kernel BUG in __skb_gso

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF=yD-KEwVnH6PRyxbJZt4iGfKasadYwU_6_V+hHW2s+ZqFNcw@mail.gmail.com>
Date:   Tue, 20 Dec 2022 13:27:22 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Tudor Ambarus <tudor.ambarus@...aro.org>
Cc:     mst@...hat.com, jasowang@...hat.com,
        virtualization@...ts.linux-foundation.org, edumazet@...gle.com,
        davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
        netdev@...r.kernel.org, willemb@...gle.com,
        syzkaller@...glegroups.com, liuhangbin@...il.com,
        linux-kernel@...r.kernel.org, joneslee@...gle.com
Subject: Re: kernel BUG in __skb_gso_segment

On Tue, Dec 20, 2022 at 8:21 AM Tudor Ambarus <tudor.ambarus@...aro.org> wrote:
>
> Hi,
>
> There's a bug [1] reported by syzkaller in linux-5.15.y that I'd like
> to squash. The commit in stable that introduces the bug is:
> b99c71f90978 net: skip virtio_net_hdr_set_proto if protocol already set
> The upstream commit for this is:
> 1ed1d592113959f00cc552c3b9f47ca2d157768f
>
> I discovered that in mainline this bug was squashed by the following
> commits:
> e9d3f80935b6 ("net/af_packet: make sure to pull mac header")
> dfed913e8b55 ("net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO")
>
> I'm seeking for some guidance on how to fix linux-5.15.y. From what I
> understand, the bug in stable is triggered because we end up with a
> header offset of 18, that eventually triggers the GSO crash in
> __skb_pull. If I revert the commit in culprit from linux-5.15.y, we'll
> end up with a header offset of 14, the bug is not hit and the packet is
> dropped at validate_xmit_skb() time. I'm wondering if reverting it is
> the right thing to do, as the commit is marked as a fix. Backporting the
> 2 commits from mainline is not an option as they introduce new support.
> Would such a patch be better than reverting the offending commit?

If both patches can be backported without conflicts, in this case I
think that is the preferred solution.

If the fix were obvious that would be an option. But the history for
this code indicates that it isn't. It has a history of fixes for edge
cases.

Backporting the two avoids a fork that would make backporting
additional fixes harder. The first of the two is technically not a
fix, but evidently together they are for this case. And the additional
logic and risk backported seems manageable.

Admittedly that is subjective. I can help take a closer look at a
custom fix if consensus is that is preferable.