netdev - Re: [PATCH net v3] net: atm: implement pre_send to check input before sending

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: <tencent_58BAB3BB5133049EA81B004B7D1B0D255508@qq.com>
Date: Thu, 11 Dec 2025 14:55:45 +0800
From: Edward Adam Davis <eadavis@...com>
To: horms@...nel.org
Cc: davem@...emloft.net,
	eadavis@...com,
	edumazet@...gle.com,
	kuba@...nel.org,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	syzbot+5dd615f890ddada54057@...kaller.appspotmail.com,
	syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH net v3] net: atm: implement pre_send to check input before sending

On Wed, 10 Dec 2025 13:02:56 +0000, Simon Horman wrote:
> On Wed, Dec 10, 2025 at 06:50:02PM +0800, Edward Adam Davis wrote:
> > Sun, Wed, 10 Dec 2025 10:31:34 +0000, Simon Horman wrote:
> > > > syzbot found an uninitialized targetless variable. The user-provided
> > > > data was only 28 bytes long, but initializing targetless requires at
> > > > least 44 bytes. This discrepancy ultimately led to the uninitialized
> > > > variable access issue reported by syzbot [1].
> > > >
> > > > Besides the issues reported by syzbot regarding targetless messages
> > > > [1], similar problems exist in other types of messages as well. We will
> > > > uniformly add input data checks to pre_send to prevent uninitialized
> > > > issues from recurring.
> > > >
> > > > Additionally, for cases where sizeoftlvs is greater than 0, the skb
> > > > requires more memory, and this will also be checked.
> > > >
> > > > [1]
> > > > BUG: KMSAN: uninit-value in lec_arp_update net/atm/lec.c:1845 [inline]
> > > >  lec_arp_update net/atm/lec.c:1845 [inline]
> > > >  lec_atm_send+0x2b02/0x55b0 net/atm/lec.c:385
> > > >  vcc_sendmsg+0x1052/0x1190 net/atm/common.c:650
> > > >
> > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > > Reported-by: syzbot+5dd615f890ddada54057@...kaller.appspotmail.com
> > > > Closes: https://syzkaller.appspot.com/bug?extid=5dd615f890ddada54057
> > > > Signed-off-by: Edward Adam Davis <eadavis@...com>
> > > > ---
> > > > v3:
> > > >   - update coding style and practices
> > > > v2: https://lore.kernel.org/all/tencent_E83074AB763967783C9D36949674363C4A09@qq.com/
> > > >   - update subject and comments for pre_send
> > > > v1: https://lore.kernel.org/all/tencent_B31D1B432549BA28BB5633CB9E2C1B124B08@qq.com
> > >
> > > FTR, a similar patch has been posted by Dharanitharan (CCed)
> > Didn't you check the dates? I released the third version of the patch
> > on December 4th (the first version was on November 28th), while this
> > person above released their first version of the patch on December 7th.
> > Their patch is far too similar to mine!
> 
> Yes, I was aware of the timeline when I wrote my previous email.
> 
> My preference is for some consensus to be reached on the way forward:
> both technically and in terms of process.
I'm a little confused. Why are you explaining the process to someone
who submitted a patch 99% similar to mine, just a few days after I did?