[PATCH] ieee802154: fix kernel-infoleak in dgram_recvmsg()

[PATCH] ieee802154: fix kernel-infoleak in dgram_recvmsg()

[syzbot]

From: Aleksandr Nogikh <nogikh@google.com>

KMSAN reported a kernel-infoleak in move_addr_to_user():

BUG: KMSAN: kernel-infoleak in instrument_copy_to_user
include/linux/instrumented.h:131 [inline]
BUG: KMSAN: kernel-infoleak in _inline_copy_to_user
include/linux/uaccess.h:205 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xcc/0x120
lib/usercopy.c:26
 instrument_copy_to_user include/linux/instrumented.h:131 [inline]
 _inline_copy_to_user include/linux/uaccess.h:205 [inline]
 _copy_to_user+0xcc/0x120 lib/usercopy.c:26
 copy_to_user include/linux/uaccess.h:236 [inline]
 move_addr_to_user+0x2e7/0x440 net/socket.c:302
 ____sys_recvmsg+0x232/0x610 net/socket.c:2925
 ...
 Uninit was stored to memory at:
 ieee802154_addr_to_sa include/net/ieee802154_netdev.h:369 [inline]
 dgram_recvmsg+0xa09/0xbe0 net/ieee802154/socket.c:739

The issue occurs because the `pan_id` field of `struct ieee802154_addr`
is left uninitialized when the address mode is `IEEE802154_ADDR_NONE`.
The execution flow is as follows:

1. `__ieee802154_rx_handle_packet()` declares a local `struct
ieee802154_hdr hdr` on the stack.
2. `ieee802154_hdr_pull()` calls `ieee802154_hdr_get_addr()` to parse
the source and destination addresses into this structure.
3. If the address mode is `IEEE802154_ADDR_NONE`,
`ieee802154_hdr_get_addr()` previously only set the `mode` field,
leaving the `pan_id` field containing uninitialized stack memory.
4. This uninitialized `pan_id` is later copied into a `struct
sockaddr_ieee802154` in `dgram_recvmsg()` via `ieee802154_addr_to_sa()`.
5. Finally, `move_addr_to_user()` copies the socket address structure to
user space, leaking the uninitialized bytes.

Fix this by using `memset` to zero out the address structure in
`ieee802154_hdr_get_addr()` when the mode is `IEEE802154_ADDR_NONE`.

Fixes: 94b4f6c21cf5 ("ieee802154: add header structs with endiannes and operations")
Assisted-by: Gemini:gemini-3.1-pro-preview Gemini:gemini-3-flash-preview syzbot
Reported-by: syzbot+346474e3bf0b26bd3090@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=346474e3bf0b26bd3090
Link: https://syzkaller.appspot.com/ai_job?id=a507a109-d683-4a2c-bc03-93394f491b17
Signed-off-by: Aleksandr Nogikh <nogikh@google.com>

---
diff --git a/net/ieee802154/header_ops.c b/net/ieee802154/header_ops.c
index 41a556be1..a9f0c8df5 100644
--- a/net/ieee802154/header_ops.c
+++ b/net/ieee802154/header_ops.c
@@ -173,10 +173,13 @@ ieee802154_hdr_get_addr(const u8 *buf, int mode, bool omit_pan,
 {
 	int pos = 0;
 
-	addr->mode = mode;
-
-	if (mode == IEEE802154_ADDR_NONE)
+	if (mode == IEEE802154_ADDR_NONE) {
+		memset(addr, 0, sizeof(*addr));
+		addr->mode = IEEE802154_ADDR_NONE;
 		return 0;
+	}
+
+	addr->mode = mode;
 
 	if (!omit_pan) {
 		memcpy(&addr->pan_id, buf + pos, 2);


base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8
-- 
See https://github.com/google/syzkaller/blob/master/docs/syzbot_ai_patches.md for information about AI-generated patches.
You can comment on the patch as usual, syzbot will try to address
the comments and send a new version of the patch if necessary.
syzbot engineers can be reached at syzkaller@googlegroups.com.

Re: [PATCH] ieee802154: fix kernel-infoleak in dgram_recvmsg()

[netdev-bot]

Welcome to the netdev mailing list!

We noticed this may be one of your first submissions to netdev
(at least with this email address).

See https://www.kernel.org/doc/html/next/process/ for kernel
process guidelines, and most importantly:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html
for netdev-specific guidelines.

Here are a few ground rules which are frequently broken by newcomers:

 - You must wait at least 24 hours before posting a new version to give
   reviewers time to respond. This is a hard rule, no matter what your
   reason to repost is.

 - Each new version of your series should be a fresh / separate thread
   Add a https://lore.kernel.org/.. link to the previous version to
   the cover letter or changelog, instead of threading the submissions.

 - Until you gain experience submit one of two patches at a time,
   do not send multiple changes at once until some of your changes
   were accepted. This avoids reviewers having to provide the same
   feedback on multiple patches.

 - Avoid changing the subject of the changes or cover letter unless
   necessary, it breaks our patch tracking.

 - If you're submitting changes for issues discovered using automated
   tools - commit message should explain the discovery and testing
   process (for drivers explicitly mention that you don't have access
   to the device, it's not a blocker).

Happy hacking!

Re: [PATCH] ieee802154: fix kernel-infoleak in dgram_recvmsg()

[Miquel Raynal]

Hello,

LGTM.

> -	addr->mode = mode;
> -
> -	if (mode == IEEE802154_ADDR_NONE)
> +	if (mode == IEEE802154_ADDR_NONE) {
> +		memset(addr, 0, sizeof(*addr));
> +		addr->mode = IEEE802154_ADDR_NONE;
>  		return 0;
> +	}
> +
> +	addr->mode = mode;
>  
>  	if (!omit_pan) {
>  		memcpy(&addr->pan_id, buf + pos, 2);
>
>

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

Thanks,
Miquèl