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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <af5fd6da-f747-4f34-a866-f489c17dbe5a@hartkopp.net>
Date: Thu, 8 Jan 2026 17:27:27 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Jakub Kicinski <kuba@...nel.org>
Cc: mkl@...gutronix.de, Prithvi <activprithvi@...il.com>, andrii@...nel.org,
 linux-can@...r.kernel.org, linux-kernel@...r.kernel.org,
 syzkaller-bugs@...glegroups.com, netdev@...r.kernel.org
Subject: Re: [bpf, xdp] headroom - was: Re: Question about to KMSAN:
 uninit-value in can_receive

On 08.01.26 16:17, Jakub Kicinski wrote:
> On Wed, 7 Jan 2026 16:34:13 +0100 Oliver Hartkopp wrote:
>>> Alternatively perhaps for this particular use case you could use
>>> something like metadata_dst to mark the frame as forwarded / annotate
>>> with the originating ifindex?
>>
>> I looked into it and the way how skb_dst is shared in the union behind
>> cb[] does not look very promising for skbs that wander up and down in
>> the network layer.
> 
> Maybe I'm misunderstanding, but skb_dst is only unioned with some
> socket layer (TCP and sockmsg) fields, not with cb[]. It'd be
> problematic if CAN gw frames had to traverse routing but I don't
> think they do?

We are using skb's that are e.g. created on socket level and only 
contain fixed struct can[|fd|xl]_frames that are written into CAN 
controllers registers on netdev level. The skb is just a dumb container, 
which passes qdiscs and are stored in the CAN device cache until the CAN 
frame is sent successfully on the CAN bus. And when it was sent, the skb 
is echo'ed back via netif_rx() so that all local applications can see 
the real traffic on the CAN bus. So our skb's can go down and up.

I did some more investigation and created 5 RFC patches that solve the 
issue with the problematic private headroom (struct can_skb_priv) in CAN 
skbs.

I'll continue testing - but it looks pretty good so far.

Best regards,
Oliver