Re: [PATCH net] udp: Fix out-of-bounds read with unset mac header in unexpected GSO path

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Boyan Liu wrote:
> Hi Willem,
> 
> On Thu, Oct 15, 2026 at 10:49 AM, Willem de Bruijn wrote:
> > I wonder if the right fix here is to not call skb_unset_mac_header in
> > the first place.
> >
> > There are plenty of L3 device type with no L2 header. They still have
> > a valid skb_mac_header.
> >
> > This fix may be papering over a tunnel doing something non-standard.
> 
> You're right, and after digging into it I agree the seg6local side is
> the real offender.
> 
> I checked every skb_unset_mac_header() call site in the tree. There
> are exactly two: net/ipv6/seg6_local.c (end_dt_vrf_rcv) and
> net/core/filter.c (BPF egress, unrelated to the rx path). Every other
> receive path delivers packets with a valid mac header: NIC drivers set
> it in eth_type_trans(), and L3 tunnels without an L2 header (ipip,
> sit, gre, tun, loopback) reset it to the network header after
> decapsulation. seg6local is the only producer that lets a packet
> continue up the stack with mac_header unset, which is also the state
> skb_mac_header() warns about with DEBUG_NET_WARN_ON_ONCE().
> 
> One complication: the unset in end_dt_vrf_rcv() is not gratuitous.
> vrf_l3_rcv() -> vrf_add_mac_header_if_unset() relies on it to
> synthesize a fake Ethernet header when a sniffer (e.g. tcpdump) is
> attached to the VRF device. Dropping the unset entirely would change
> what sniffers see on VRF devices.
> 
> So instead of removing it, I restore a valid mac header once the VRF
> rx handler returns:
> 
>         if (!skb_mac_header_was_set(skb))
>                 skb_reset_mac_header(skb);
> 
> The sniffer rebuild happens inside the handler while the header is
> still unset, so tap behavior is unchanged; when no rebuild happened,
> the packet now carries the same mac header state as any packet
> received on an L3 device.
> 
> Tested under QEMU with the original reproducer:
> - unpatched kernel: KASAN slab-out-of-bounds in inet_gso_segment,
>   same stack as the original report;
> - patched kernel: no crash, the re-segmented datagrams are delivered
>   intact, and the unexpected GSO path is confirmed taken;
> - with a sniffer attached to the VRF device, the fake Ethernet header
>   presented to the tap is identical before and after the patch.
> 
> I'll send this as v2 with the fix moved to seg6_local.c. If you'd
> rather drop the skb_unset_mac_header() altogether and accept the
> sniffer behavior change, I'm happy to do that instead.

Thanks Boyan. This sounds good to me too.