On Sat, Jan 3, 2026 at 4:21 AM Oliver Hartkopp [off-list ref] wrote:

Hello Jakub,

thanks for stepping in!

On 02.01.26 21:04, Jakub Kicinski wrote:

quoted

You're asking the wrong person, IIUC Andrii is tangentially involved
in XDP (via bpf links?):

(..)

quoted

Without looking too deeply - XDP has historically left the new space
uninitialized after push, expecting programs to immediately write the
headers in that space. syzbot had run into this in the past but I can't
find any references to past threads quickly :(

To identify Andrii I mainly looked into the code with 'git blame' that

Hey, sorry for a late response, I've been out on vacation for the past
~2 weeks. But as Jakub correctly pointed out, I'm probably not the
right person to help with this, I touched XDP bits only superficially
to wire up some generic BPF infrastructure, while the issue at hand
goes deeper than that. I'll let you guys figure this out.

led to this problematic call chain:

   pskb_expand_head+0x226/0x1a60 net/core/skbuff.c:2275
   netif_skb_check_for_xdp net/core/dev.c:5081 [inline]
   netif_receive_generic_xdp net/core/dev.c:5112 [inline]
   do_xdp_generic+0x9e3/0x15a0 net/core/dev.c:5180

Having in mind that the syzkaller refers to
6.13.0-rc7-syzkaller-00039-gc3812b15000c I wonder if we can leave this
report as-is, as the problem might be solved in the meantime??

In any case I wonder, if we should add some code to re-check if the
headroom of the CAN-related skbs is still consistent and not changed in
size by other players. And maybe add some WARN_ON_ONCE() before dropping
the skb then.

When the skb headroom is not safe to be used we need to be able to
identify and solve it.

Best regards,
Oliver