[syzbot] [net?] KMSAN: uninit-value in lec_atm_send

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: ac3fd01e4c1e Linux 6.18-rc7
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=139a1612580000
kernel config: https://syzkaller.appspot.com/x/.config?x=61a9bf3cc5d17a01
dashboard link: https://syzkaller.appspot.com/bug?extid=5dd615f890ddada54057
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10f4b8b4580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=129d0e58580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/227434a45737/disk-ac3fd01e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/d8117003dbb5/vmlinux-ac3fd01e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/a13125fb7a7d/bzImage-ac3fd01e.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5dd615...@syzkaller.appspotmail.com

=====================================================
BUG: KMSAN: uninit-value in lec_arp_update net/atm/lec.c:1845 [inline]
BUG: KMSAN: uninit-value in lec_atm_send+0x2b02/0x55b0 net/atm/lec.c:385
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
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg+0x333/0x3d0 net/socket.c:742
____sys_sendmsg+0x7e0/0xd80 net/socket.c:2630
___sys_sendmsg+0x271/0x3b0 net/socket.c:2684
__sys_sendmsg net/socket.c:2716 [inline]
__do_sys_sendmsg net/socket.c:2721 [inline]
__se_sys_sendmsg net/socket.c:2719 [inline]
__x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2719
x64_sys_call+0x1dfd/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
slab_post_alloc_hook mm/slub.c:4985 [inline]
slab_alloc_node mm/slub.c:5288 [inline]
kmem_cache_alloc_node_noprof+0x989/0x16b0 mm/slub.c:5340
kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579
__alloc_skb+0x347/0x7d0 net/core/skbuff.c:670
alloc_skb include/linux/skbuff.h:1383 [inline]
vcc_sendmsg+0x602/0x1190 net/atm/common.c:628
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg+0x333/0x3d0 net/socket.c:742
____sys_sendmsg+0x7e0/0xd80 net/socket.c:2630
___sys_sendmsg+0x271/0x3b0 net/socket.c:2684
__sys_sendmsg net/socket.c:2716 [inline]
__do_sys_sendmsg net/socket.c:2721 [inline]
__se_sys_sendmsg net/socket.c:2719 [inline]
__x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2719
x64_sys_call+0x1dfd/0x3e30 arch/x86/include/generated/asm/syscalls_64.h:47
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xd9/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
=====================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Edward Adam Davis]

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].

Adding a message length check to the arp update process eliminates
the uninitialized issue in [1].

[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

Reported-by: syzbot+5dd615...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <ead...@qq.com>
---
net/atm/lec.c | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/net/atm/lec.c b/net/atm/lec.c
index afb8d3eb2185..178132b2771a 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -382,6 +382,15 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb)
break;
fallthrough;
case l_arp_update:
+ {
+ int need_size = offsetofend(struct atmlec_msg,
+ content.normal.targetless_le_arp);
+ if (skb->len < need_size) {
+ pr_info("Input msg size too small, need %d got %u\n",
+ need_size, skb->len);
+ dev_kfree_skb(skb);
+ return -EINVAL;
+ }
lec_arp_update(priv, mesg->content.normal.mac_addr,
mesg->content.normal.atm_addr,
mesg->content.normal.flag,
@@ -394,6 +403,7 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb)
tmp, mesg->sizeoftlvs);
}
break;
+ }
case l_config:
priv->maximum_unknown_frame_count =
mesg->content.config.maximum_unknown_frame_count;
--
2.43.0

[Simon Horman]

Hi Edward,

Thanks for taking time to look into this issue.

On Fri, Nov 28, 2025 at 11:56:25PM +0800, Edward Adam Davis 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].
>
> Adding a message length check to the arp update process eliminates
> the uninitialized issue in [1].
>
> [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
>
> Reported-by: syzbot+5dd615...@syzkaller.appspotmail.com

I think it would be useful to also include:

Closes: https://syzkaller.appspot.com/bug?extid=5dd615f890ddada54057

And as a fix for Networking code it should include a fixes tag.
Briefly examining the history of this code, using git annotate,
it seems that this problem has existed since the beginning of git history.
If so, this tag seems appropriate:

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")

Also, as a fix for Networking code present in the net tree,
it should be targeted at that tree, like this:

Subject: [PATCH net] ...

More information on the Networking development workflow can be found here:
https://docs.kernel.org/process/maintainer-netdev.html

> Signed-off-by: Edward Adam Davis <ead...@qq.com>
> ---
> net/atm/lec.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/net/atm/lec.c b/net/atm/lec.c
> index afb8d3eb2185..178132b2771a 100644
> --- a/net/atm/lec.c
> +++ b/net/atm/lec.c
> @@ -382,6 +382,15 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb)
> break;
> fallthrough;
> case l_arp_update:
> + {
> + int need_size = offsetofend(struct atmlec_msg,
> + content.normal.targetless_le_arp);
> + if (skb->len < need_size) {

As per Eric's comment on a similar fix [1],
you should probably be using pskb_may_pull().

Also, I see that this patch addresses the l_arp_update case.
But it looks like a similar problem exist in least in the l_config case
too.

So I think it would be useful take a more holistic approach.
Perhaps in the form of a patchset if you want to restrict this
patch to addressing the specific problem flagged by syzbot.

[1] https://lore.kernel.org/netdev/20251126034601.23...@gmail.com/

> + pr_info("Input msg size too small, need %d got %u\n",
> + need_size, skb->len);
> + dev_kfree_skb(skb);
> + return -EINVAL;
> + }
> lec_arp_update(priv, mesg->content.normal.mac_addr,
> mesg->content.normal.atm_addr,
> mesg->content.normal.flag,

--
pw-bot: changes-requested

[Edward Adam Davis]

Sun, 30 Nov 2025 15:56:42 +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].
> >
> > Adding a message length check to the arp update process eliminates
> > the uninitialized issue in [1].
> >
> > [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
> >
> > Reported-by: syzbot+5dd615...@syzkaller.appspotmail.com
>
> I think it would be useful to also include:
>
> Closes: https://syzkaller.appspot.com/bug?extid=5dd615f890ddada54057
>
> And as a fix for Networking code it should include a fixes tag.
> Briefly examining the history of this code, using git annotate,
> it seems that this problem has existed since the beginning of git history.
> If so, this tag seems appropriate:
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>
> Also, as a fix for Networking code present in the net tree,
> it should be targeted at that tree, like this:
>
> Subject: [PATCH net] ...

Thanks very much for your oppinions. I will send v2 for it.

>
> More information on the Networking development workflow can be found here:
> https://docs.kernel.org/process/maintainer-netdev.html
>
>
> > Signed-off-by: Edward Adam Davis <ead...@qq.com>
> > ---
> > net/atm/lec.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/net/atm/lec.c b/net/atm/lec.c
> > index afb8d3eb2185..178132b2771a 100644
> > --- a/net/atm/lec.c
> > +++ b/net/atm/lec.c
> > @@ -382,6 +382,15 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb)
> > break;
> > fallthrough;
> > case l_arp_update:
> > + {
> > + int need_size = offsetofend(struct atmlec_msg,
> > + content.normal.targetless_le_arp);
> > + if (skb->len < need_size) {
>
> As per Eric's comment on a similar fix [1],
> you should probably be using pskb_may_pull().

The pskb_may_pull() function performs a more thorough check of the skb
length, which is especially suitable for handling non-linear data areas.

>
> Also, I see that this patch addresses the l_arp_update case.
> But it looks like a similar problem exist in least in the l_config case
> too.

I noticed this, and it's not just these; several types of atmlec_msg
handled in lec_atm_send() are also involved.
Strictly speaking, they all require relevant checks.

>
> So I think it would be useful take a more holistic approach.
> Perhaps in the form of a patchset if you want to restrict this
> patch to addressing the specific problem flagged by syzbot.

Okay, I'll carefully consider how to handle the others.

[Edward Adam Davis]

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+5dd615...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=5dd615f890ddada54057

Signed-off-by: Edward Adam Davis <ead...@qq.com>
---

v2:
- update subject and comments for pre_send
v1: https://lore.kernel.org/all/tencent_B31D1B432549BA...@qq.com

net/atm/lec.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)

diff --git a/net/atm/lec.c b/net/atm/lec.c
index afb8d3eb2185..8a9660abd134 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -340,6 +340,23 @@ static int lec_close(struct net_device *dev)
return 0;
}

+static int lec_atm_pre_send(struct atm_vcc *vcc, struct sk_buff *skb)
+{
+ struct atmlec_msg *mesg;
+ int sizeoftlvs;
+ int msg_size = sizeof(struct atmlec_msg);
+
+ if (skb->len < msg_size)
+ return -EINVAL;
+
+ mesg = (struct atmlec_msg *)skb->data;
+ sizeoftlvs = mesg->sizeoftlvs;
+ if (sizeoftlvs > 0 && !pskb_may_pull(skb, msg_size + sizeoftlvs))
+ return -EINVAL;
+
+ return 0;
+}
+

static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb)

{
static const u8 zero_addr[ETH_ALEN] = {};
@@ -491,6 +508,7 @@ static void lec_atm_close(struct atm_vcc *vcc)

static const struct atmdev_ops lecdev_ops = {
.close = lec_atm_close,
+ .pre_send = lec_atm_pre_send,
.send = lec_atm_send
};

--
2.43.0

[Paolo Abeni]

On 11/28/25 4:56 PM, Edward Adam Davis 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].
>
> Adding a message length check to the arp update process eliminates
> the uninitialized issue in [1].
>
> [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
>
> Reported-by: syzbot+5dd615...@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <ead...@qq.com>

This needs a suitable fixes tag, and you should specify the target tree
into the subj prefix, see:

https://elixir.bootlin.com/linux/v6.18/source/Documentation/process/maintainer-netdev.rst#L61

> ---
> net/atm/lec.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/net/atm/lec.c b/net/atm/lec.c
> index afb8d3eb2185..178132b2771a 100644
> --- a/net/atm/lec.c
> +++ b/net/atm/lec.c
> @@ -382,6 +382,15 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb)
> break;
> fallthrough;
> case l_arp_update:
> + {
> + int need_size = offsetofend(struct atmlec_msg,
> + content.normal.targetless_le_arp);
> + if (skb->len < need_size) {
> + pr_info("Input msg size too small, need %d got %u\n",
> + need_size, skb->len);
> + dev_kfree_skb(skb);
> + return -EINVAL;
> + }

Can this be reached by pppoatm_send?
Are you sure that the data will always be available in the linear part?

/P

[Paolo Abeni]

On 12/1/25 5:31 AM, Edward Adam Davis wrote:
> diff --git a/net/atm/lec.c b/net/atm/lec.c
> index afb8d3eb2185..8a9660abd134 100644
> --- a/net/atm/lec.c
> +++ b/net/atm/lec.c
> @@ -340,6 +340,23 @@ static int lec_close(struct net_device *dev)
> return 0;
> }
>
> +static int lec_atm_pre_send(struct atm_vcc *vcc, struct sk_buff *skb)
> +{
> + struct atmlec_msg *mesg;
> + int sizeoftlvs;
> + int msg_size = sizeof(struct atmlec_msg);

Please respect the revers christmas tree above.

> +
> + if (skb->len < msg_size)
> + return -EINVAL;
> +
> + mesg = (struct atmlec_msg *)skb->data;
> + sizeoftlvs = mesg->sizeoftlvs;
> + if (sizeoftlvs > 0 && !pskb_may_pull(skb, msg_size + sizeoftlvs))

AI based review noticed that negative `sizeoftlvs` values will foul the
above check:

https://netdev-ai.bots.linux.dev/ai-review.html?id=8b2b0db8-e11a-4215-85a6-a0735c7d908b

AFAICS the lec code always interpret `sizeoftlvs` as u32, regardless of
the type used by `struct atmlec_msg`. I suggest doing the same.

/P

[Edward Adam Davis]

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+5dd615...@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=5dd615f890ddada54057

Signed-off-by: Edward Adam Davis <ead...@qq.com>

---
v3:
- update coding style and practices
v2: https://lore.kernel.org/all/tencent_E83074AB763967...@qq.com/

- update subject and comments for pre_send
v1: https://lore.kernel.org/all/tencent_B31D1B432549BA...@qq.com

net/atm/lec.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)

diff --git a/net/atm/lec.c b/net/atm/lec.c
index afb8d3eb2185..423503d2e7a7 100644

--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -340,6 +340,23 @@ static int lec_close(struct net_device *dev)
return 0;
}

+static int lec_atm_pre_send(struct atm_vcc *vcc, struct sk_buff *skb)
+{

+ u32 sizeoftlvs;
+ struct atmlec_msg *mesg;
+ int msg_size = sizeof(struct atmlec_msg);

+
+ if (skb->len < msg_size)
+ return -EINVAL;
+
+ mesg = (struct atmlec_msg *)skb->data;
+ sizeoftlvs = mesg->sizeoftlvs;

+ if (sizeoftlvs && !pskb_may_pull(skb, msg_size + sizeoftlvs))
+ return -EINVAL;
+