netdev - Re: [PATCH v2 0/2] net: sched: act_ife: initialize struct tc

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: <20251105100403.17786-1-vnranganath.20@gmail.com>
Date: Wed,  5 Nov 2025 15:33:58 +0530
From: Ranganath V N <vnranganath.20@...il.com>
To: horms@...nel.org
Cc: davem@...emloft.net,
	david.hunter.linux@...il.com,
	edumazet@...gle.com,
	jhs@...atatu.com,
	jiri@...nulli.us,
	khalid@...nel.org,
	kuba@...nel.org,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	skhan@...uxfoundation.org,
	syzbot+0c85cae3350b7d486aee@...kaller.appspotmail.com,
	vnranganath.20@...il.com,
	xiyou.wangcong@...il.com
Subject: Re: [PATCH v2 0/2] net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleak

On 11/4/25 19:38, Simon Horman wrote:
> On Sat, Nov 01, 2025 at 06:04:46PM +0530, Ranganath V N wrote:
>> Fix a KMSAN kernel-infoleak detected  by the syzbot .
>>
>> [net?] KMSAN: kernel-infoleak in __skb_datagram_iter
>>
>> In tcf_ife_dump(), the variable 'opt' was partially initialized using a
>> designatied initializer. While the padding bytes are reamined
>> uninitialized. nla_put() copies the entire structure into a
>> netlink message, these uninitialized bytes leaked to userspace.
>>
>> Initialize the structure with memset before assigning its fields
>> to ensure all members and padding are cleared prior to beign copied.
>
> Perhaps not important, but this seems to only describe patch 1/2.
>
>>
>> Signed-off-by: Ranganath V N <vnranganath.20@...il.com>
>
> Sorry for not looking more carefully at v1.
>
> The presence of this padding seems pretty subtle to me.
> And while I agree that your change fixes the problem described.
> I wonder if it would be better to make things more obvious
> by adding a 2-byte pad member to the structures involved.

Thanks for the input.

One question — even though adding a 2-byte `pad` field silences KMSAN,
would that approach be reliable across all architectures?
Since the actual amount and placement of padding can vary depending on
structure alignment and compiler behavior, I’m wondering if this would only
silence the report on certain builds rather than fixing the root cause.

The current memset-based initialization explicitly clears all bytes in the
structure (including any compiler-inserted padding), which seems safer and
more consistent across architectures.

Also, adding a new member — even a padding field — could potentially alter
the structure size or layout as seen from user space. That might 
unintentionally affect existing user-space expectations.

Do you think relying on a manual pad field is good enough?

regards,  
--Ranganath