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: <20251221-ochre-macaw-of-serenity-f3ed07-mkl@pengutronix.de>
Date: Sun, 21 Dec 2025 20:06:44 +0100
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Oliver Hartkopp <socketcan@...tkopp.net>
Cc: Andrii Nakryiko <andrii@...nel.org>, Prithvi <activprithvi@...il.com>, 
	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 21.12.2025 19:29:37, Oliver Hartkopp wrote:
> we have a "KMSAN: uninit value" problem which is created by
> netif_skb_check_for_xdp() and later pskb_expand_head().
>
> The CAN netdev interfaces (ARPHRD_CAN) don't have XDP support and the CAN
> bus related skbs allocate 16 bytes of pricate headroom.
>
> Although CAN netdevs don't support XDP the KMSAN issue shows that the
> headroom is expanded for CAN skbs and a following access to the CAN skb
> private data via skb->head now reads from the beginning of the XDP expanded
> head which is (of course) uninitialized.
>
> Prithvi thankfully did some investigation (see below!) which proved my
> estimation about "someone is expanding our CAN skb headroom".
>
> Prithvi also proposed two ways to solve the issue (at the end of his mail
> below), where I think the first one is a bad hack (although it was my idea).
>
> The second idea is a change for dev_xdp_attach() where your expertise would
> be necessary.
>
> My sugestion would rather go into the direction to extend dev_xdp_mode()
>
> https://elixir.bootlin.com/linux/v6.19-rc1/source/net/core/dev.c#L10170
>
> in a way that it allows to completely disable XDP for CAN skbs, e.g. with a
> new XDP_FLAGS_DISABLED that completely keeps the hands off such skbs.

That sounds not like a good idea to me.

> Do you have any (better) idea how to preserve the private data in the
> skb->head of CAN related skbs?

We probably have to place the data somewhere else.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ