Re: [PATCH net v2 0/2] net/sched: act_vlan: pop_eth can strip non-Ethernet skbs and panic loopback

[Guillaume Nault <gnault@redhat.com>]

On Sat, Jul 25, 2026 at 08:21:52AM -0400, Jamal Hadi Salim wrote:
> On Sat, Jul 25, 2026 at 6:46 AM Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> >
> > On Thu, Jul 23, 2026 at 1:54 PM Ren Wei <enjou1224z@gmail.com> wrote:
> > >
> > > From: Wyatt Feng <bronzed_45_vested@icloud.com>
> > >
> > > Hi Linux kernel maintainers,
> > >
> > > We found an issue in net/sched/act_vlan.c.
> > > The bug is reachable by an unprivileged user using private user and network namespaces.
> > > The relevant details are provided below.
> > >
> >
> > Please remove bouncing @bytedance emails from the CC list.
> >
> > You did not address the discussion we had earlier, which is a very
> > good example of an issue Yuan brought up at the bof - "fixing the root
> > cause".
> > Attaching the last email from Guillaume since this was not on a public list.
> > I had argued you only need patch 2 (and to be safe handle both pop and
> > push) and Guillaume argued that would not fix the root cause and there
> > is potential the bug could still happen and patch 1 would be needed.
> > His exact wording is:
> > "
> > So, if patch 1 isn't needed, that means we must guarantee all skbs
> > reaching an ARPHRD_ETHER device to have at least ETH_HLEN bytes of
> > headroom.
> > "
> > after some back and forth we steered into drivers and pskb_may_pull()
> > invocation.
> >
> > In any case it would be a good idea for you to review and consider the
> > discussion and infact test with suggested vrf device (which doesnt
> > pskb_may_pull())
> >
> 
> After some coffee, _my view_:
> The root cause is the missing pskb_may_pull(skb, ETH_HLEN) in
> loopback_xmit() and vrf_local_xmit() (thats why i was asking to repro
> with vrf).

vrf_local_xmit() is only invoked from vrf_process_v6_outbound() and
vrf_process_v4_outbound(), which both start with a pskb_may_pull()
call since commit 107e47cc80ec ("vrf: make sure skb->data contains ip
header to make routing"). So the problem shouldn't be reproducible with
VRF.

I also think that the problem should be fixed by adding pskb_may_pull()
to loopback_xmit().

> The proper fix belongs in those drivers, not in the tc action.
> Guillaume's point is valid: limiting POP_ETH to ARPHRD_ETHER devices
> doesn't fix the  problem, it just makes the existing reproducer stop
> crashing while leaving the underlying  driver defect exploitable
> through other paths.
> 
> That said, another stack or code path might lead to vlan/skbmod so
> fixing the actions might make sense as a follow-up.
> 
> cheers,
> jamal
>