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: <a2b9fde3-6c50-4003-bc9b-0d6f359e7ac9@redhat.com>
Date: Thu, 15 Jan 2026 16:37:10 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Oliver Hartkopp <socketcan@...tkopp.net>, linux-can@...r.kernel.org,
 Marc Kleine-Budde <mkl@...gutronix.de>, Jakub Kicinski <kuba@...nel.org>
Cc: 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 1/12/26 4:09 PM, Oliver Hartkopp wrote:
> This patch set aims to remove the unconventional skb headroom usage for
> CAN bus related skbuffs. To store the data for CAN specific use-cases
> unused space in CAN skbs is used, namely the inner protocol space for
> ethernet/IP encapsulation.

I don't like much that the CAN information are scattered in different
places (skb->hash and tunnel header section). Also it's unclear to me if
a can bus skb could end-up landing (even via completely
insane/intentionally evil configuration/setup) in a plain netdev interface.

In the such a case this solution will be problematic.

Could you please explain in details why the metadata_dst option has been
deemed unsuitable?!? I *think* something vaguely alike the following
would do?!?

---
diff --git a/include/net/dst_metadata.h b/include/net/dst_metadata.h
index 1fc2fb03ce3f..d6ee45631fea 100644
--- a/include/net/dst_metadata.h
+++ b/include/net/dst_metadata.h
@@ -13,6 +13,13 @@ enum metadata_type {
 	METADATA_HW_PORT_MUX,
 	METADATA_MACSEC,
 	METADATA_XFRM,
+	METADATA_CAN,
+};
+
+struct can_md_info {
+	int can_iif;
+	int len;
+	int uid;
 };

 struct hw_port_info {
@@ -38,6 +45,7 @@ struct metadata_dst {
 		struct hw_port_info	port_info;
 		struct macsec_info	macsec_info;
 		struct xfrm_md_info	xfrm_info;
+		struct can_md_info	can_info;
 	} u;
 };