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

[Simon Horman <horms@kernel.org>]

On Thu, Dec 11, 2025 at 02:55:45PM +0800, Edward Adam Davis wrote:
> 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@syzkaller.appspotmail.com
> > > > > Closes: https://syzkaller.appspot.com/bug?extid=5dd615f890ddada54057
> > > > > Signed-off-by: Edward Adam Davis <eadavis@qq.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?

It's always tricky when similar patches are on the ML on the same time.
Ultimately what I would like is for a correct solution to be merged.
Ideally in a way that makes everyone happy.

I'm explaining that to everyone: in this thread, and elsewhere.