netdev - Re: [can-next 0/5] can: remove private skb headroom infrastructure

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: <dfbcab83-095d-4ed1-ae98-baada95d4cad@hartkopp.net>
Date: Sun, 18 Jan 2026 13:53:49 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Paolo Abeni <pabeni@...hat.com>, linux-can@...r.kernel.org,
 Marc Kleine-Budde <mkl@...gutronix.de>, Vincent Mailhol
 <mailhol@...nel.org>, netdev@...r.kernel.org,
 Eric Dumazet <edumazet@...gle.com>, Simon Horman <horms@...nel.org>,
 davem@...emloft.net
Subject: Re: [can-next 0/5] can: remove private skb headroom infrastructure

On 17.01.26 18:15, Jakub Kicinski wrote:
> On Fri, 16 Jan 2026 11:31:14 +0100 Oliver Hartkopp wrote:
>> Long story short: Using the common pattern to wrap a union around
>> dual-usable skb space is the most efficient and least risky solution IMHO.
> 
> The concern is that we're making a precedent for, let's call it -
> not-routable-networking technology to redefine fields in skb that
> it doesn't need. From the maintainability perspective that's a big
> risk, IMHO. I fully acknowledge tho that using md dst will be a lot
> more work. Which makes this situation an unpleasant judgment call :(
> 

I checked out more of the "destination cache" code, the dst_metadata and 
its users.

And also this scary union in struct sk_buff:

union {
         struct {
                 unsigned long   _skb_refdst;
                 void            (*destructor)(struct sk_buff *skb);
         };
         struct list_head        tcp_tsorted_anchor;
#ifdef CONFIG_NET_SOCK_MSG
         unsigned long           _sk_redir;
#endif
};

Despite the fact that the required 8 bytes content for the CAN skb has 
nothing to do with destinations or other of these above use cases that 
share the unsigned long pointer magic above, I doubt that the current 
flow of CAN skbs between socket layer, driver layer and forth and back 
would survive this.

My first approach to "just" extend the skb header space for CAN skbs did 
not work out because people obviously have other things in mind with 
skb->head. I'm sure I can count the days until something breaks with the 
CAN specific SKB data when attaching them to the next infrastructure 
build for ethernet/IP use cases for the same reason.

After all these experiences I would tend to add the required 8 bytes 
directly to struct sk_buff covered by "#if IS_ENABLED(CONFIG_CAN)".

Or save those 8 bytes by using the "inner protocol space" and 
additionally setting skb->encapsulation to false. Which is a safe thing 
to protect the CAN specific content against accidentally assaults and 
can be clearly proved to be correct.

Best regards,
Oliver