linux-kernel - Re: Feedback provided on question about 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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20251130120442.289280-1-activprithvi@gmail.com>
Date: Sun, 30 Nov 2025 17:34:42 +0530
From: Prithvi Tambewagh <activprithvi@...il.com>
To: socketcan@...tkopp.net
Cc: Prithvi Tambewagh <activprithvi@...il.com>,
	linux-can@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	syzkaller-bugs@...glegroups.com
Subject: Re: Feedback provided on question about KMSAN: uninit-value in can_receive

Hello Oliver,

Thanks for the feedback! I now understand how struct can_skb_priv is 
reserved in the headroom, more clearly, given that I am relatively new
to kernel development. I agree on your patch. 

I tested it locally  using the reproducer program for this bug provided by
syzbot and it didn't crash the kernel. Also, I checked the patch here

https://lore.kernel.org/linux-can/20191207183418.28868-1-socketcan@hartkopp.net/

looking at it, I think your patch will work fine with the above patch as 
well, since data will be accessed at 

skb->data - sizeof(struct can_skb_priv)

which is the intended place for it, according to te action of 
can_skb_reserve() which increases headroom by length 
sizeof(struct can_skb_priv), reserving the space just before skb->data.

I think it solves this specific KMSAN bug. Kindly correct me if I am wrong.

Would you like to fix this bug by sending your patch upstream? Or else
shall I send this patch upstream and mention your name in Suggested-by tag?

Thank you,
Prithvi Tambewagh