Re: [bpf, xdp] headroom - was: Re: Question about to KMSAN: uninit-value in can_receive

[Oliver Hartkopp]

On 21.12.25 20:06, Marc Kleine-Budde wrote:
> On 21.12.2025 19:29:37, Oliver Hartkopp wrote:
> > we have a "KMSAN: uninit value" problem which is created by
> > netif_skb_check_for_xdp() and later pskb_expand_head().
> >
> > The CAN netdev interfaces (ARPHRD_CAN) don't have XDP support and the CAN
> > bus related skbs allocate 16 bytes of pricate headroom.
> >
> > Although CAN netdevs don't support XDP the KMSAN issue shows that the
> > headroom is expanded for CAN skbs and a following access to the CAN skb
> > private data via skb->head now reads from the beginning of the XDP expanded
> > head which is (of course) uninitialized.
> >
> > Prithvi thankfully did some investigation (see below!) which proved my
> > estimation about "someone is expanding our CAN skb headroom".
> >
> > Prithvi also proposed two ways to solve the issue (at the end of his mail
> > below), where I think the first one is a bad hack (although it was my idea).
> >
> > The second idea is a change for dev_xdp_attach() where your expertise would
> > be necessary.
> >
> > My sugestion would rather go into the direction to extend dev_xdp_mode()
> >
> > https://elixir.bootlin.com/linux/v6.19-rc1/source/net/core/dev.c#L10170
> >
> > in a way that it allows to completely disable XDP for CAN skbs, e.g. with a
> > new XDP_FLAGS_DISABLED that completely keeps the hands off such skbs.
>
> That sounds not like a good idea to me.
>
> > Do you have any (better) idea how to preserve the private data in the
> > skb->head of CAN related skbs?
>
> We probably have to place the data somewhere else.

Maybe in the tail room or inside struct sk_buff with some #ifdef 
CONFIG_CAN handling?

But let's wait for Andrii's feedback first, whether he is generally 
aware of this XDP behavior effect on CAN skbs.

Best regards,
Oliver