netdev - Re: [net-next 0/6] move CAN skb headroom content to skb extensions

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4909066f-cf9c-49ac-b02f-d2e16908bbd9@hartkopp.net>
Date: Wed, 28 Jan 2026 13:52:58 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Florian Westphal <fw@...len.de>, Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, linux-can@...r.kernel.org
Subject: Re: [net-next 0/6] move CAN skb headroom content to skb extensions



On 28.01.26 12:35, Florian Westphal wrote:
> Jakub Kicinski <kuba@...nel.org> wrote:
>> This is fine. Wish we could make md_dst work, since skb_ext still burns
>> a bit in the skb (last extension bit in fact, next user will have to
>> bump the filed size). And you very much do not route these frames,
>> so dst would work perfectly fine. But whatever.
> 
> An alternative would be to 'union' extensions that cannot be
> active at the same time.  Something like the br netfilter extension
> for example.
> 
> When the first extensions were added all of them could be enabled
> at same time, but I think that has changed.

IMO we do not need to 'union' extensions as long as automatic enum 
calculation does it job with the enabled Kconfig options.

My only concern would be distribution kernels that have an all-yes 
config policy ;-)

Btw. while we are at it ...

With my patch set the enum would now look like this:

#ifdef CONFIG_SKB_EXTENSIONS
enum skb_ext_id {
#if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
         SKB_EXT_BRIDGE_NF,
#endif
#ifdef CONFIG_XFRM
         SKB_EXT_SEC_PATH,
#endif
#if IS_ENABLED(CONFIG_NET_TC_SKB_EXT)
         TC_SKB_EXT,
#endif
#if IS_ENABLED(CONFIG_MPTCP)
         SKB_EXT_MPTCP,
#endif
#if IS_ENABLED(CONFIG_MCTP_FLOWS)
         SKB_EXT_MCTP,
#endif
#if IS_ENABLED(CONFIG_INET_PSP)
         SKB_EXT_PSP,
#endif
#if IS_ENABLED(CONFIG_CAN)
         SKB_EXT_CAN,
#endif
         SKB_EXT_NUM, /* must be last */
};

=> SKB_EXT_NUM is then 7

When we (correctly) add another extension, SKB_EXT_NUM would become 8 
which is still fine IMO. But then the BUILD_BUG_ON check in 
skb_extensions_init() would need the below fix, right?

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 648c20e19038..609851d70173 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5156,11 +5156,11 @@ static __always_inline unsigned int 
skb_ext_total_length(void)
         return l;
  }

  static void skb_extensions_init(void)
  {
-       BUILD_BUG_ON(SKB_EXT_NUM >= 8);
+       BUILD_BUG_ON(SKB_EXT_NUM > 8);
  #if !IS_ENABLED(CONFIG_KCOV_INSTRUMENT_ALL)
         BUILD_BUG_ON(skb_ext_total_length() > 255);
  #endif

         skbuff_ext_cache = kmem_cache_create("skbuff_ext_cache",


Should I send a proper patch?

Best regards,
Oliver