Re: kernel BUG in __skb_gso_segment

[Tudor Ambarus]

Hi,

I added Greg KH to the thread, maybe he can shed some light on whether
new support can be marked as fixes and backported to stable. The rules
on what kind of patches are accepted into the -stable tree don't mention
new support:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

On 20.12.2022 20:27, Willem de Bruijn wrote:
> On Tue, Dec 20, 2022 at 8:21 AM Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> 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.

I confirm both patches can be backported without conflicts.

> 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

I agree that a fork would make backporting additional fixes harder.
I'm no networking guy, but I can debug further to understand whether the
patch that I proposed or other would make sense for both mainline and
stable kernels. We'll avoid the fork this way.

> fix, but evidently together they are for this case. And the additional
> logic and risk backported seems manageable.

It is, indeed.

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

Thanks. Let's wait for others to comment so that we have an agreement.

Cheers,
ta