* Re: [PATCH] mac802154: Prevent overwrite return code in mac802154_perform_association()
From: Simon Horman @ 2026-06-04 17:28 UTC (permalink / raw)
To: Robertus Diawan Chris
Cc: alex.aring, stefan, miquel.raynal, davem, edumazet, kuba, pabeni,
linux-wpan, netdev, linux-kernel, linux-kernel-mentees, skhan, me
In-Reply-To: <20260602054133.470293-1-robertusdchris@gmail.com>
On Tue, Jun 02, 2026 at 12:41:33PM +0700, Robertus Diawan Chris wrote:
> When assoc_status not equal to IEEE802154_ASSOCIATION_SUCCESSFUL, the
> return value assigned to either "-ERANGE" or "-EPERM" but this return
> value will be overwritten to 0 after exiting the conditional scope.
> So, jump to clear_assoc label to preserve the return value when
> assoc_status not equal to IEEE802154_ASSOCIATION_SUCCESSFUL.
>
> This is reported by Coverity Scan as "Unused value".
>
> Fixes: fefd19807fe9 ("mac802154: Handle associating")
> Signed-off-by: Robertus Diawan Chris <robertusdchris@gmail.com>
FTR: An AI generated review of this patch is available on sashiko.dev.
I believe that review can be treated in the context of possible follow-up
and should not effect the progress of this patch.
^ permalink raw reply
* [syzbot] [wpan?] KMSAN: uninit-value in lowpan_xmit
From: syzbot @ 2026-06-03 7:27 UTC (permalink / raw)
To: alex.aring, davem, edumazet, horms, kuba, linux-kernel,
linux-wpan, miquel.raynal, netdev, pabeni, stefan, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: e8c2f9fdadee Merge tag 'for-7.1/hpfs-fixes' of git://git.k..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10883b06580000
kernel config: https://syzkaller.appspot.com/x/.config?x=91978e795dcd971b
dashboard link: https://syzkaller.appspot.com/bug?extid=f13c19f75e1097abd116
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6d28568f6ffa/disk-e8c2f9fd.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/68a9eec5e7f1/vmlinux-e8c2f9fd.xz
kernel image: https://storage.googleapis.com/syzbot-assets/e6a7381a5e55/bzImage-e8c2f9fd.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f13c19f75e1097abd116@syzkaller.appspotmail.com
dev_queue_xmit include/linux/netdevice.h:3418 [inline]
tx+0xb6/0x440 drivers/block/aoe/aoenet.c:62
kthread+0x17d/0x370 drivers/block/aoe/aoecmd.c:1241
kthread+0x53a/0x5f0 kernel/kthread.c:436
ret_from_fork+0x20f/0x8d0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---[ end trace 0000000000000000 ]---
=====================================================
BUG: KMSAN: uninit-value in lowpan_header net/ieee802154/6lowpan/tx.c:240 [inline]
BUG: KMSAN: uninit-value in lowpan_xmit+0xa6b/0x1d00 net/ieee802154/6lowpan/tx.c:282
lowpan_header net/ieee802154/6lowpan/tx.c:240 [inline]
lowpan_xmit+0xa6b/0x1d00 net/ieee802154/6lowpan/tx.c:282
__netdev_start_xmit include/linux/netdevice.h:5368 [inline]
netdev_start_xmit include/linux/netdevice.h:5377 [inline]
xmit_one net/core/dev.c:3888 [inline]
dev_hard_start_xmit+0x22f/0xa80 net/core/dev.c:3904
__dev_queue_xmit+0x2990/0x5a00 net/core/dev.c:4870
dev_queue_xmit include/linux/netdevice.h:3418 [inline]
tx+0xb6/0x440 drivers/block/aoe/aoenet.c:62
kthread+0x17d/0x370 drivers/block/aoe/aoecmd.c:1241
kthread+0x53a/0x5f0 kernel/kthread.c:436
ret_from_fork+0x20f/0x8d0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Uninit was stored to memory at:
lowpan_header net/ieee802154/6lowpan/tx.c:231 [inline]
lowpan_xmit+0x68f/0x1d00 net/ieee802154/6lowpan/tx.c:282
__netdev_start_xmit include/linux/netdevice.h:5368 [inline]
netdev_start_xmit include/linux/netdevice.h:5377 [inline]
xmit_one net/core/dev.c:3888 [inline]
dev_hard_start_xmit+0x22f/0xa80 net/core/dev.c:3904
__dev_queue_xmit+0x2990/0x5a00 net/core/dev.c:4870
dev_queue_xmit include/linux/netdevice.h:3418 [inline]
tx+0xb6/0x440 drivers/block/aoe/aoenet.c:62
kthread+0x17d/0x370 drivers/block/aoe/aoecmd.c:1241
kthread+0x53a/0x5f0 kernel/kthread.c:436
ret_from_fork+0x20f/0x8d0 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4577 [inline]
slab_alloc_node mm/slub.c:4899 [inline]
kmem_cache_alloc_node_noprof+0x3cd/0x12c0 mm/slub.c:4951
kmalloc_reserve net/core/skbuff.c:613 [inline]
__alloc_skb+0x855/0x1190 net/core/skbuff.c:713
alloc_skb include/linux/skbuff.h:1383 [inline]
new_skb+0x4a/0x550 drivers/block/aoe/aoecmd.c:66
aoecmd_cfg_pkts drivers/block/aoe/aoecmd.c:430 [inline]
aoecmd_cfg+0x2c2/0xb70 drivers/block/aoe/aoecmd.c:1374
discover_timer+0x64/0x80 drivers/block/aoe/aoemain.c:25
call_timer_fn+0x4c/0x510 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1799 [inline]
__run_timers kernel/time/timer.c:2374 [inline]
__run_timer_base+0x80a/0xdb0 kernel/time/timer.c:2386
run_timer_base kernel/time/timer.c:2395 [inline]
run_timer_softirq+0x3a/0x70 kernel/time/timer.c:2405
handle_softirqs+0x171/0x7b0 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x9a/0x1e0 kernel/softirq.c:735
irq_exit_rcu+0x12/0x20 kernel/softirq.c:752
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1061 [inline]
sysvec_apic_timer_interrupt+0x84/0x90 arch/x86/kernel/apic/apic.c:1061
asm_sysvec_apic_timer_interrupt+0x1f/0x30 arch/x86/include/asm/idtentry.h:697
CPU: 0 UID: 0 PID: 1310 Comm: aoe_tx0 Tainted: G W syzkaller #0 PREEMPT(full)
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
=====================================================
---
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 syzkaller@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 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
^ permalink raw reply
* Re: [PATCH] mac802154: Prevent overwrite return code in mac802154_perform_association()
From: Miquel Raynal @ 2026-06-02 10:35 UTC (permalink / raw)
To: Robertus Diawan Chris
Cc: alex.aring, stefan, davem, edumazet, kuba, pabeni, horms,
linux-wpan, netdev, linux-kernel, linux-kernel-mentees, skhan, me
In-Reply-To: <20260602054133.470293-1-robertusdchris@gmail.com>
Hello,
On 02/06/2026 at 12:41:33 +07, Robertus Diawan Chris <robertusdchris@gmail.com> wrote:
> When assoc_status not equal to IEEE802154_ASSOCIATION_SUCCESSFUL, the
> return value assigned to either "-ERANGE" or "-EPERM" but this return
> value will be overwritten to 0 after exiting the conditional scope.
> So, jump to clear_assoc label to preserve the return value when
> assoc_status not equal to IEEE802154_ASSOCIATION_SUCCESSFUL.
>
> This is reported by Coverity Scan as "Unused value".
>
> Fixes: fefd19807fe9 ("mac802154: Handle associating")
> Signed-off-by: Robertus Diawan Chris <robertusdchris@gmail.com>
This is correct.
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Thanks,
Miquèl
^ permalink raw reply
* [PATCH] mac802154: Prevent overwrite return code in mac802154_perform_association()
From: Robertus Diawan Chris @ 2026-06-02 5:41 UTC (permalink / raw)
To: alex.aring, stefan, miquel.raynal
Cc: davem, edumazet, kuba, pabeni, horms, linux-wpan, netdev,
linux-kernel, linux-kernel-mentees, skhan, me
When assoc_status not equal to IEEE802154_ASSOCIATION_SUCCESSFUL, the
return value assigned to either "-ERANGE" or "-EPERM" but this return
value will be overwritten to 0 after exiting the conditional scope.
So, jump to clear_assoc label to preserve the return value when
assoc_status not equal to IEEE802154_ASSOCIATION_SUCCESSFUL.
This is reported by Coverity Scan as "Unused value".
Fixes: fefd19807fe9 ("mac802154: Handle associating")
Signed-off-by: Robertus Diawan Chris <robertusdchris@gmail.com>
---
I am still not sure how to test this change. I look around the function
and use the previous error handler as a guidance to make this change,
like error handler for "No ASSOC REQ ACK received" and "No ASSOC RESP
received".
Thank you.
net/mac802154/scan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac802154/scan.c b/net/mac802154/scan.c
index 0a31ac8d8415..300d4584533e 100644
--- a/net/mac802154/scan.c
+++ b/net/mac802154/scan.c
@@ -594,6 +594,7 @@ int mac802154_perform_association(struct ieee802154_sub_if_data *sdata,
"Negative ASSOC RESP received from %8phC: %s\n", &ceaddr,
local->assoc_status == IEEE802154_PAN_AT_CAPACITY ?
"PAN at capacity" : "access denied");
+ goto clear_assoc;
}
ret = 0;
base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net] 6lowpan: fix off-by-one in multicast context address compression
From: patchwork-bot+netdevbpf @ 2026-06-02 2:30 UTC (permalink / raw)
To: Yizhou Zhao
Cc: netdev, alex.aring, davem, edumazet, kuba, pabeni, horms,
linux-bluetooth, linux-wpan, linux-kernel, yangyx22, wangao,
fengxw06, qli01, xuke
In-Reply-To: <20260527081806.42747-1-zhaoyz24@mails.tsinghua.edu.cn>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 27 May 2026 16:18:01 +0800 you wrote:
> The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses
> &data[1] as destination and &ipaddr->s6_addr[11] as source, but
> both should be offset by one: &data[2] and &ipaddr->s6_addr[12]
> respectively.
>
> This off-by-one has two consequences:
> 1. data[1] is overwritten with s6_addr[11], corrupting the RIID
> field in the compressed multicast address
> 2. data[5] is never written, so uninitialized kernel stack memory
> is transmitted over the network via lowpan_push_hc_data(),
> leaking kernel stack contents
>
> [...]
Here is the summary with links:
- [net] 6lowpan: fix off-by-one in multicast context address compression
https://git.kernel.org/netdev/net/c/2a58899d1100
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2] mac802154: llsec: add skb_cow_data() before in-place crypto
From: Simon Horman @ 2026-06-01 20:43 UTC (permalink / raw)
To: Doruk Tan Ozturk
Cc: alex.aring, stefan, miquel.raynal, aleksander.lobakin, linux-wpan,
netdev, security, stable
In-Reply-To: <20260526183726.56100-1-doruk@0sec.ai>
On Tue, May 26, 2026 at 08:37:26PM +0200, Doruk Tan Ozturk wrote:
> llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(),
> llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform
> in-place cryptographic transformations on skb data. They build a
> scatterlist with sg_init_one() pointing into the skb's linear data area
> and then pass the same scatterlist as both src and dst to the crypto API
> (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt).
>
> On the RX path, __ieee802154_rx_handle_packet() clones the received skb
> before handing it to each subscriber via ieee802154_subif_frame(). The
> cloned skb shares the same underlying data buffer via reference
> counting. When llsec_do_decrypt() subsequently modifies this shared
> buffer in place, it corrupts data that other clones -- potentially
> belonging to other sockets or subsystems -- still reference.
>
> On the TX path, similar data sharing can occur when an skb's head has
> been cloned (skb_cloned() returns true).
>
> The fix is to call skb_cow_data() before performing any in-place crypto
> operation. skb_cow_data() ensures that the skb's data area is not
> shared: if the skb head is cloned or the data spans multiple fragments,
> it copies the data into a private buffer that can be safely modified in
> place. This is the same pattern used by:
>
> - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c)
> - MACsec (drivers/net/macsec.c)
> - WireGuard (drivers/net/wireguard/receive.c)
> - TIPC (net/tipc/crypto.c)
>
> Without this guard, in-place crypto on shared skb data leads to:
> - Silent data corruption of other skb clones
> - Use-after-free when the crypto API scatterwalk writes through a
> page that has already been freed by another clone's kfree_skb()
> - Kernel crashes under concurrent 802.15.4 traffic with security
> enabled (KASAN/KMSAN reports slab-use-after-free)
>
> Found by 0sec (https://0sec.ai) using automated source analysis.
>
> Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method")
> Fixes: 03556e4d0dbb ("mac802154: add llsec encryption method")
> Cc: stable@vger.kernel.org
> Reported-by: Doruk Tan Ozturk <doruk@0sec.ai>
> Closes: https://lore.kernel.org/linux-wpan/20260525161806.96158-1-doruk@0sec.ai/
> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
> ---
> v2:
> - mark as net fix per Olek's review
> - add Closes tag
> - add Reviewed-by
FTR: An AI generated review of this patch is available on sashiko.dev.
I believe that review can be treated in the context of possible follow-up
and should not effect the progress of this patch.
^ permalink raw reply
* Re: [PATCH net] 6lowpan: fix off-by-one in multicast context address compression
From: Alexander Aring @ 2026-05-31 22:41 UTC (permalink / raw)
To: Yizhou Zhao
Cc: netdev, Alexander Aring, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-bluetooth,
linux-wpan, linux-kernel, Yuxiang Yang, Ao Wang, Xuewei Feng,
Qi Li, Ke Xu
In-Reply-To: <20260527081806.42747-1-zhaoyz24@mails.tsinghua.edu.cn>
Hi,
On Wed, May 27, 2026 at 4:19 AM Yizhou Zhao
<zhaoyz24@mails.tsinghua.edu.cn> wrote:
>
> The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses
> &data[1] as destination and &ipaddr->s6_addr[11] as source, but
> both should be offset by one: &data[2] and &ipaddr->s6_addr[12]
> respectively.
>
> This off-by-one has two consequences:
> 1. data[1] is overwritten with s6_addr[11], corrupting the RIID
> field in the compressed multicast address
> 2. data[5] is never written, so uninitialized kernel stack memory
> is transmitted over the network via lowpan_push_hc_data(),
> leaking kernel stack contents
>
> The correct inline data layout must match what the decompression
> function lowpan_uncompress_multicast_ctx_daddr() expects:
> data[0..1] = s6_addr[1..2] (flags/scope + RIID)
> data[2..5] = s6_addr[12..15] (group ID)
>
> Also zero-initialize the data array as a defensive measure against
> similar bugs in the future.
>
> Fixes: 5609c185f24d ("6lowpan: iphc: add support for stateful compression")
> Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
> Reported-by: Ao Wang <wangao@seu.edu.cn>
> Reported-by: Xuewei Feng <fengxw06@126.com>
> Reported-by: Qi Li <qli01@tsinghua.edu.cn>
> Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
> Assisted-by: GLM:GLM-5.1
> Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
> ---
> diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
> index e116d30..37eaff3 100644
> --- a/net/6lowpan/iphc.c
> +++ b/net/6lowpan/iphc.c
> @@ -1086,12 +1086,12 @@ static u8 lowpan_iphc_mcast_ctx_addr_compress(u8 **hc_ptr,
> const struct lowpan_iphc_ctx *ctx,
> const struct in6_addr *ipaddr)
> {
> - u8 data[6];
> + u8 data[6] = {};
>
> /* flags/scope, reserved (RIID) */
> memcpy(data, &ipaddr->s6_addr[1], 2);
> /* group ID */
> - memcpy(&data[1], &ipaddr->s6_addr[11], 4);
> + memcpy(&data[2], &ipaddr->s6_addr[12], 4);
> lowpan_push_hc_data(hc_ptr, data, 6);
>
> return LOWPAN_IPHC_DAM_00;
Looks good to me.
Acked-by: Alexander Aring <aahringo@redhat.com>
Thanks.
- Alex
^ permalink raw reply
* Re: [PATCH] ieee802154: fix kernel-infoleak in dgram_recvmsg()
From: Miquel Raynal @ 2026-05-28 7:45 UTC (permalink / raw)
To: syzbot
Cc: syzkaller-bugs, Alexander Aring, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-wpan, netdev, Paolo Abeni, Stefan Schmidt,
horms, linux-kernel, syzbot
In-Reply-To: <62795fd9-fc0c-48eb-bb82-05ffc5a57104@mail.kernel.org>
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
^ permalink raw reply
* [PATCH] ieee802154: fix kernel-infoleak in dgram_recvmsg()
From: syzbot @ 2026-05-27 20:18 UTC (permalink / raw)
To: syzkaller-bugs, Alexander Aring, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-wpan, Miquel Raynal, netdev, Paolo Abeni,
Stefan Schmidt
Cc: horms, linux-kernel, 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.
^ permalink raw reply related
* [PATCH net] 6lowpan: fix off-by-one in multicast context address compression
From: Yizhou Zhao @ 2026-05-27 8:18 UTC (permalink / raw)
To: netdev
Cc: Yizhou Zhao, Alexander Aring, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-bluetooth,
linux-wpan, linux-kernel, Yuxiang Yang, Ao Wang, Xuewei Feng,
Qi Li, Ke Xu
The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses
&data[1] as destination and &ipaddr->s6_addr[11] as source, but
both should be offset by one: &data[2] and &ipaddr->s6_addr[12]
respectively.
This off-by-one has two consequences:
1. data[1] is overwritten with s6_addr[11], corrupting the RIID
field in the compressed multicast address
2. data[5] is never written, so uninitialized kernel stack memory
is transmitted over the network via lowpan_push_hc_data(),
leaking kernel stack contents
The correct inline data layout must match what the decompression
function lowpan_uncompress_multicast_ctx_daddr() expects:
data[0..1] = s6_addr[1..2] (flags/scope + RIID)
data[2..5] = s6_addr[12..15] (group ID)
Also zero-initialize the data array as a defensive measure against
similar bugs in the future.
Fixes: 5609c185f24d ("6lowpan: iphc: add support for stateful compression")
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: GLM:GLM-5.1
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
---
diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index e116d30..37eaff3 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -1086,12 +1086,12 @@ static u8 lowpan_iphc_mcast_ctx_addr_compress(u8 **hc_ptr,
const struct lowpan_iphc_ctx *ctx,
const struct in6_addr *ipaddr)
{
- u8 data[6];
+ u8 data[6] = {};
/* flags/scope, reserved (RIID) */
memcpy(data, &ipaddr->s6_addr[1], 2);
/* group ID */
- memcpy(&data[1], &ipaddr->s6_addr[11], 4);
+ memcpy(&data[2], &ipaddr->s6_addr[12], 4);
lowpan_push_hc_data(hc_ptr, data, 6);
return LOWPAN_IPHC_DAM_00;
--
2.43.0
^ permalink raw reply related
* [PATCH net v2] mac802154: llsec: add skb_cow_data() before in-place crypto
From: Doruk Tan Ozturk @ 2026-05-26 18:37 UTC (permalink / raw)
To: alex.aring, stefan, miquel.raynal
Cc: aleksander.lobakin, linux-wpan, netdev, security, stable,
Doruk Tan Ozturk
In-Reply-To: <20260525161806.96158-1-doruk@0sec.ai>
llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(),
llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform
in-place cryptographic transformations on skb data. They build a
scatterlist with sg_init_one() pointing into the skb's linear data area
and then pass the same scatterlist as both src and dst to the crypto API
(e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt).
On the RX path, __ieee802154_rx_handle_packet() clones the received skb
before handing it to each subscriber via ieee802154_subif_frame(). The
cloned skb shares the same underlying data buffer via reference
counting. When llsec_do_decrypt() subsequently modifies this shared
buffer in place, it corrupts data that other clones -- potentially
belonging to other sockets or subsystems -- still reference.
On the TX path, similar data sharing can occur when an skb's head has
been cloned (skb_cloned() returns true).
The fix is to call skb_cow_data() before performing any in-place crypto
operation. skb_cow_data() ensures that the skb's data area is not
shared: if the skb head is cloned or the data spans multiple fragments,
it copies the data into a private buffer that can be safely modified in
place. This is the same pattern used by:
- ESP (net/ipv4/esp4.c, net/ipv6/esp6.c)
- MACsec (drivers/net/macsec.c)
- WireGuard (drivers/net/wireguard/receive.c)
- TIPC (net/tipc/crypto.c)
Without this guard, in-place crypto on shared skb data leads to:
- Silent data corruption of other skb clones
- Use-after-free when the crypto API scatterwalk writes through a
page that has already been freed by another clone's kfree_skb()
- Kernel crashes under concurrent 802.15.4 traffic with security
enabled (KASAN/KMSAN reports slab-use-after-free)
Found by 0sec (https://0sec.ai) using automated source analysis.
Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method")
Fixes: 03556e4d0dbb ("mac802154: add llsec encryption method")
Cc: stable@vger.kernel.org
Reported-by: Doruk Tan Ozturk <doruk@0sec.ai>
Closes: https://lore.kernel.org/linux-wpan/20260525161806.96158-1-doruk@0sec.ai/
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
v2:
- mark as net fix per Olek's review
- add Closes tag
- add Reviewed-by
net/mac802154/llsec.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c
index e8512578398e..b6a4a8c93d72 100644
--- a/net/mac802154/llsec.c
+++ b/net/mac802154/llsec.c
@@ -710,6 +710,7 @@ int mac802154_llsec_encrypt(struct mac802154_llsec *sec, struct sk_buff *skb)
{
struct ieee802154_hdr hdr;
int rc, authlen, hlen;
+ struct sk_buff *trailer;
struct mac802154_llsec_key *key;
u32 frame_ctr;
@@ -769,6 +770,12 @@ int mac802154_llsec_encrypt(struct mac802154_llsec *sec, struct sk_buff *skb)
skb->mac_len = ieee802154_hdr_push(skb, &hdr);
skb_reset_mac_header(skb);
+ rc = skb_cow_data(skb, 0, &trailer);
+ if (rc < 0) {
+ llsec_key_put(key);
+ return rc;
+ }
+
rc = llsec_do_encrypt(skb, sec, &hdr, key);
llsec_key_put(key);
@@ -908,6 +915,13 @@ llsec_do_decrypt(struct sk_buff *skb, const struct mac802154_llsec *sec,
const struct ieee802154_hdr *hdr,
struct mac802154_llsec_key *key, __le64 dev_addr)
{
+ struct sk_buff *trailer;
+ int err;
+
+ err = skb_cow_data(skb, 0, &trailer);
+ if (err < 0)
+ return err;
+
if (hdr->sec.level == IEEE802154_SCF_SECLEVEL_ENC)
return llsec_do_decrypt_unauth(skb, sec, hdr, key, dev_addr);
else
--
2.45.0
^ permalink raw reply related
* Re: [PATCH] mac802154: llsec: add skb_cow_data() before in-place crypto
From: Alexander Lobakin @ 2026-05-26 16:13 UTC (permalink / raw)
To: Doruk Tan Ozturk
Cc: alex.aring, stefan, miquel.raynal, linux-wpan, security, netdev,
stable
In-Reply-To: <20260525161806.96158-1-doruk@0sec.ai>
From: Doruk Tan Ozturk <doruk@0sec.ai>
Date: Mon, 25 May 2026 18:18:06 +0200
> [PATCH] mac802154: llsec: add skb_cow_data() before in-place crypto
Pls mark as "PATCH net".
> llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(),
> llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform
> in-place cryptographic transformations on skb data. They build a
> scatterlist with sg_init_one() pointing into the skb's linear data area
> and then pass the same scatterlist as both src and dst to the crypto API
> (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt).
>
> On the RX path, __ieee802154_rx_handle_packet() clones the received skb
> before handing it to each subscriber via ieee802154_subif_frame(). The
> cloned skb shares the same underlying data buffer via reference
> counting. When llsec_do_decrypt() subsequently modifies this shared
> buffer in place, it corrupts data that other clones -- potentially
> belonging to other sockets or subsystems -- still reference.
>
> On the TX path, similar data sharing can occur when an skb's head has
> been cloned (skb_cloned() returns true).
>
> The fix is to call skb_cow_data() before performing any in-place crypto
> operation. skb_cow_data() ensures that the skb's data area is not
> shared: if the skb head is cloned or the data spans multiple fragments,
> it copies the data into a private buffer that can be safely modified in
> place. This is the same pattern used by:
>
> - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c)
> - MACsec (drivers/net/macsec.c)
> - WireGuard (drivers/net/wireguard/receive.c)
> - TIPC (net/tipc/crypto.c)
>
> Without this guard, in-place crypto on shared skb data leads to:
> - Silent data corruption of other skb clones
> - Use-after-free when the crypto API scatterwalk writes through a
> page that has already been freed by another clone's kfree_skb()
> - Kernel crashes under concurrent 802.15.4 traffic with security
> enabled (KASAN/KMSAN reports slab-use-after-free)
>
> This vulnerability was identified using 0sec.ai, an open-source
> automated security auditing platform (https://github.com/0sec-labs).
>
> Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method")
> Fixes: 03556e4d0dbb ("mac802154: add llsec encryption method")
> Cc: stable@vger.kernel.org
> Reported-by: Doruk Tan Ozturk <doruk@0sec.ai>
Did you report this on LKML? If so, you should add
Closes: <link to your mail on lore>
right after the Reported-by.
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
Other than that,
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Thanks,
Olek
^ permalink raw reply
* [PATCH] mac802154: llsec: add skb_cow_data() before in-place crypto
From: Doruk Tan Ozturk @ 2026-05-25 16:18 UTC (permalink / raw)
To: alex.aring, stefan, miquel.raynal
Cc: linux-wpan, security, netdev, Doruk Tan Ozturk, stable
llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(),
llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform
in-place cryptographic transformations on skb data. They build a
scatterlist with sg_init_one() pointing into the skb's linear data area
and then pass the same scatterlist as both src and dst to the crypto API
(e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt).
On the RX path, __ieee802154_rx_handle_packet() clones the received skb
before handing it to each subscriber via ieee802154_subif_frame(). The
cloned skb shares the same underlying data buffer via reference
counting. When llsec_do_decrypt() subsequently modifies this shared
buffer in place, it corrupts data that other clones -- potentially
belonging to other sockets or subsystems -- still reference.
On the TX path, similar data sharing can occur when an skb's head has
been cloned (skb_cloned() returns true).
The fix is to call skb_cow_data() before performing any in-place crypto
operation. skb_cow_data() ensures that the skb's data area is not
shared: if the skb head is cloned or the data spans multiple fragments,
it copies the data into a private buffer that can be safely modified in
place. This is the same pattern used by:
- ESP (net/ipv4/esp4.c, net/ipv6/esp6.c)
- MACsec (drivers/net/macsec.c)
- WireGuard (drivers/net/wireguard/receive.c)
- TIPC (net/tipc/crypto.c)
Without this guard, in-place crypto on shared skb data leads to:
- Silent data corruption of other skb clones
- Use-after-free when the crypto API scatterwalk writes through a
page that has already been freed by another clone's kfree_skb()
- Kernel crashes under concurrent 802.15.4 traffic with security
enabled (KASAN/KMSAN reports slab-use-after-free)
This vulnerability was identified using 0sec.ai, an open-source
automated security auditing platform (https://github.com/0sec-labs).
Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method")
Fixes: 03556e4d0dbb ("mac802154: add llsec encryption method")
Cc: stable@vger.kernel.org
Reported-by: Doruk Tan Ozturk <doruk@0sec.ai>
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
net/mac802154/llsec.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c
index e8512578398e..b6a4a8c93d72 100644
--- a/net/mac802154/llsec.c
+++ b/net/mac802154/llsec.c
@@ -710,6 +710,7 @@ int mac802154_llsec_encrypt(struct mac802154_llsec *sec, struct sk_buff *skb)
{
struct ieee802154_hdr hdr;
int rc, authlen, hlen;
+ struct sk_buff *trailer;
struct mac802154_llsec_key *key;
u32 frame_ctr;
@@ -769,6 +770,12 @@ int mac802154_llsec_encrypt(struct mac802154_llsec *sec, struct sk_buff *skb)
skb->mac_len = ieee802154_hdr_push(skb, &hdr);
skb_reset_mac_header(skb);
+ rc = skb_cow_data(skb, 0, &trailer);
+ if (rc < 0) {
+ llsec_key_put(key);
+ return rc;
+ }
+
rc = llsec_do_encrypt(skb, sec, &hdr, key);
llsec_key_put(key);
@@ -908,6 +915,13 @@ llsec_do_decrypt(struct sk_buff *skb, const struct mac802154_llsec *sec,
const struct ieee802154_hdr *hdr,
struct mac802154_llsec_key *key, __le64 dev_addr)
{
+ struct sk_buff *trailer;
+ int err;
+
+ err = skb_cow_data(skb, 0, &trailer);
+ if (err < 0)
+ return err;
+
if (hdr->sec.level == IEEE802154_SCF_SECLEVEL_ENC)
return llsec_do_decrypt_unauth(skb, sec, hdr, key, dev_addr);
else
--
2.45.0
^ permalink raw reply related
* [PATCH net 2/2] ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation
From: Michael Bommarito @ 2026-05-20 14:16 UTC (permalink / raw)
To: Alexander Aring, Stefan Schmidt, Miquel Raynal
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Phoebe Buckheister, linux-wpan, netdev,
linux-kernel
In-Reply-To: <20260520141640.1149513-1-michael.bommarito@gmail.com>
The LLSEC ADD/DEL doit handlers under the legacy IEEE802154_NL family
consume IEEE802154_ATTR_LLSEC_KEY_BYTES and
IEEE802154_ATTR_LLSEC_KEY_USAGE_COMMANDS, both declared in
net/ieee802154/nl_policy.c as bare length entries with no .type
(defaulting to NLA_UNSPEC). Generic netlink strict validation rejects
all NLA_UNSPEC attributes via validate_nla(), so every LLSEC_ADD_KEY,
LLSEC_DEL_KEY, LLSEC_ADD_DEV, LLSEC_DEL_DEV, LLSEC_ADD_DEVKEY,
LLSEC_DEL_DEVKEY, LLSEC_ADD_SECLEVEL, and LLSEC_DEL_SECLEVEL request
fails at the dispatcher with "Unsupported attribute" before reaching
the handler.
The doit path has been silently dead since strict validation became
the default for genl families that do not opt out. The dump path is
unaffected because dump requests carry no LLSEC attributes to
validate, which is why the LLSEC_LIST_KEY read remained reachable
(patch 1/2). Introduce IEEE802154_OP_RELAXED() mirroring
IEEE802154_OP() but with .validate = GENL_DONT_VALIDATE_STRICT, and
use it for the eight legacy LLSEC mutate ops so admin-driven LLSEC
configuration via the legacy interface works again.
Fixes: 3e9c156e2c21 ("ieee802154: add netlink interfaces for llsec")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
net/ieee802154/ieee802154.h | 9 +++++++++
net/ieee802154/netlink.c | 20 ++++++++++----------
2 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/net/ieee802154/ieee802154.h b/net/ieee802154/ieee802154.h
index fd9778f705503..e765adc4b88f2 100644
--- a/net/ieee802154/ieee802154.h
+++ b/net/ieee802154/ieee802154.h
@@ -16,6 +16,15 @@ void ieee802154_nl_exit(void);
.flags = GENL_ADMIN_PERM, \
}
+#define IEEE802154_OP_RELAXED(_cmd, _func) \
+ { \
+ .cmd = _cmd, \
+ .doit = _func, \
+ .dumpit = NULL, \
+ .flags = GENL_ADMIN_PERM, \
+ .validate = GENL_DONT_VALIDATE_STRICT,\
+ }
+
#define IEEE802154_DUMP(_cmd, _func, _dump) \
{ \
.cmd = _cmd, \
diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
index 9c9fd14d0ca8b..cacad21347eca 100644
--- a/net/ieee802154/netlink.c
+++ b/net/ieee802154/netlink.c
@@ -100,22 +100,22 @@ static const struct genl_small_ops ieee802154_ops[] = {
IEEE802154_OP(IEEE802154_LLSEC_SETPARAMS, ieee802154_llsec_setparams),
IEEE802154_DUMP_PRIV(IEEE802154_LLSEC_LIST_KEY, NULL,
ieee802154_llsec_dump_keys),
- IEEE802154_OP(IEEE802154_LLSEC_ADD_KEY, ieee802154_llsec_add_key),
- IEEE802154_OP(IEEE802154_LLSEC_DEL_KEY, ieee802154_llsec_del_key),
+ IEEE802154_OP_RELAXED(IEEE802154_LLSEC_ADD_KEY, ieee802154_llsec_add_key),
+ IEEE802154_OP_RELAXED(IEEE802154_LLSEC_DEL_KEY, ieee802154_llsec_del_key),
IEEE802154_DUMP_PRIV(IEEE802154_LLSEC_LIST_DEV, NULL,
ieee802154_llsec_dump_devs),
- IEEE802154_OP(IEEE802154_LLSEC_ADD_DEV, ieee802154_llsec_add_dev),
- IEEE802154_OP(IEEE802154_LLSEC_DEL_DEV, ieee802154_llsec_del_dev),
+ IEEE802154_OP_RELAXED(IEEE802154_LLSEC_ADD_DEV, ieee802154_llsec_add_dev),
+ IEEE802154_OP_RELAXED(IEEE802154_LLSEC_DEL_DEV, ieee802154_llsec_del_dev),
IEEE802154_DUMP_PRIV(IEEE802154_LLSEC_LIST_DEVKEY, NULL,
ieee802154_llsec_dump_devkeys),
- IEEE802154_OP(IEEE802154_LLSEC_ADD_DEVKEY, ieee802154_llsec_add_devkey),
- IEEE802154_OP(IEEE802154_LLSEC_DEL_DEVKEY, ieee802154_llsec_del_devkey),
+ IEEE802154_OP_RELAXED(IEEE802154_LLSEC_ADD_DEVKEY, ieee802154_llsec_add_devkey),
+ IEEE802154_OP_RELAXED(IEEE802154_LLSEC_DEL_DEVKEY, ieee802154_llsec_del_devkey),
IEEE802154_DUMP_PRIV(IEEE802154_LLSEC_LIST_SECLEVEL, NULL,
ieee802154_llsec_dump_seclevels),
- IEEE802154_OP(IEEE802154_LLSEC_ADD_SECLEVEL,
- ieee802154_llsec_add_seclevel),
- IEEE802154_OP(IEEE802154_LLSEC_DEL_SECLEVEL,
- ieee802154_llsec_del_seclevel),
+ IEEE802154_OP_RELAXED(IEEE802154_LLSEC_ADD_SECLEVEL,
+ ieee802154_llsec_add_seclevel),
+ IEEE802154_OP_RELAXED(IEEE802154_LLSEC_DEL_SECLEVEL,
+ ieee802154_llsec_del_seclevel),
};
static const struct genl_multicast_group ieee802154_mcgrps[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH net 1/2] ieee802154: admin-gate legacy LLSEC dump operations
From: Michael Bommarito @ 2026-05-20 14:16 UTC (permalink / raw)
To: Alexander Aring, Stefan Schmidt, Miquel Raynal
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Phoebe Buckheister, linux-wpan, netdev,
linux-kernel
In-Reply-To: <20260520141640.1149513-1-michael.bommarito@gmail.com>
In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table
builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV,
LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which
sets no .flags, so generic netlink runs them ungated. The modern
nl802154 family admin-gates the equivalent reads via
NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM.
Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve
the "802.15.4 MAC" family and dump LLSEC_LIST_KEY on any wpan netdev
that has an LLSEC key installed; the dump handler writes the raw
16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied
verbatim from struct ieee802154_llsec_key.key) into the reply.
Recovering the AES key compromises 802.15.4 LLSEC link confidentiality
and authenticity, since LLSEC uses CCM* and the same key authenticates
and encrypts frames.
Impact: any local uid with no capabilities can read the raw 16-byte
AES-128 LLSEC key from the kernel keytable on any wpan netdev that has
an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY
dump on the legacy IEEE802154_NL generic-netlink family.
Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but
setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump
entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the
modern nl802154 family exposes their equivalents to unprivileged
readers by design (NL802154_CMD_GET_WPAN_PHY and
NL802154_CMD_GET_INTERFACE carry "can be retrieved by unprivileged
users" annotations).
Fixes: 3e9c156e2c21 ("ieee802154: add netlink interfaces for llsec")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
net/ieee802154/ieee802154.h | 8 ++++++++
net/ieee802154/netlink.c | 16 ++++++++--------
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/net/ieee802154/ieee802154.h b/net/ieee802154/ieee802154.h
index c5d91f78301ad..fd9778f705503 100644
--- a/net/ieee802154/ieee802154.h
+++ b/net/ieee802154/ieee802154.h
@@ -23,6 +23,14 @@ void ieee802154_nl_exit(void);
.dumpit = _dump, \
}
+#define IEEE802154_DUMP_PRIV(_cmd, _func, _dump) \
+ { \
+ .cmd = _cmd, \
+ .doit = _func, \
+ .dumpit = _dump, \
+ .flags = GENL_ADMIN_PERM, \
+ }
+
struct genl_info;
struct sk_buff *ieee802154_nl_create(int flags, u8 req);
diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
index 7d2de4ee6992b..9c9fd14d0ca8b 100644
--- a/net/ieee802154/netlink.c
+++ b/net/ieee802154/netlink.c
@@ -98,20 +98,20 @@ static const struct genl_small_ops ieee802154_ops[] = {
IEEE802154_OP(IEEE802154_SET_MACPARAMS, ieee802154_set_macparams),
IEEE802154_OP(IEEE802154_LLSEC_GETPARAMS, ieee802154_llsec_getparams),
IEEE802154_OP(IEEE802154_LLSEC_SETPARAMS, ieee802154_llsec_setparams),
- IEEE802154_DUMP(IEEE802154_LLSEC_LIST_KEY, NULL,
- ieee802154_llsec_dump_keys),
+ IEEE802154_DUMP_PRIV(IEEE802154_LLSEC_LIST_KEY, NULL,
+ ieee802154_llsec_dump_keys),
IEEE802154_OP(IEEE802154_LLSEC_ADD_KEY, ieee802154_llsec_add_key),
IEEE802154_OP(IEEE802154_LLSEC_DEL_KEY, ieee802154_llsec_del_key),
- IEEE802154_DUMP(IEEE802154_LLSEC_LIST_DEV, NULL,
- ieee802154_llsec_dump_devs),
+ IEEE802154_DUMP_PRIV(IEEE802154_LLSEC_LIST_DEV, NULL,
+ ieee802154_llsec_dump_devs),
IEEE802154_OP(IEEE802154_LLSEC_ADD_DEV, ieee802154_llsec_add_dev),
IEEE802154_OP(IEEE802154_LLSEC_DEL_DEV, ieee802154_llsec_del_dev),
- IEEE802154_DUMP(IEEE802154_LLSEC_LIST_DEVKEY, NULL,
- ieee802154_llsec_dump_devkeys),
+ IEEE802154_DUMP_PRIV(IEEE802154_LLSEC_LIST_DEVKEY, NULL,
+ ieee802154_llsec_dump_devkeys),
IEEE802154_OP(IEEE802154_LLSEC_ADD_DEVKEY, ieee802154_llsec_add_devkey),
IEEE802154_OP(IEEE802154_LLSEC_DEL_DEVKEY, ieee802154_llsec_del_devkey),
- IEEE802154_DUMP(IEEE802154_LLSEC_LIST_SECLEVEL, NULL,
- ieee802154_llsec_dump_seclevels),
+ IEEE802154_DUMP_PRIV(IEEE802154_LLSEC_LIST_SECLEVEL, NULL,
+ ieee802154_llsec_dump_seclevels),
IEEE802154_OP(IEEE802154_LLSEC_ADD_SECLEVEL,
ieee802154_llsec_add_seclevel),
IEEE802154_OP(IEEE802154_LLSEC_DEL_SECLEVEL,
--
2.53.0
^ permalink raw reply related
* [PATCH net 0/2] ieee802154: admin-gate legacy LLSEC dumps + un-deaden ADD/DEL
From: Michael Bommarito @ 2026-05-20 14:16 UTC (permalink / raw)
To: Alexander Aring, Stefan Schmidt, Miquel Raynal
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Phoebe Buckheister, linux-wpan, netdev,
linux-kernel
The legacy IEEE802154_NL family (net/ieee802154/netlink.c) builds its
ops table from two macros in net/ieee802154/ieee802154.h. IEEE802154_OP()
sets .flags = GENL_ADMIN_PERM; IEEE802154_DUMP() sets no flags. Among
the IEEE802154_DUMP() consumers are four LLSEC dump ops (LIST_KEY,
LIST_DEV, LIST_DEVKEY, LIST_SECLEVEL), and the LLSEC_LIST_KEY dump
handler at net/ieee802154/nl-mac.c emits the raw 16-byte AES-128
keytable bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, .len = 16, copied
verbatim from struct ieee802154_llsec_key.key) into the reply skb.
The modern nl802154 family admin-gates the equivalent reads
(NL802154_CMD_GET_SEC_KEY at net/ieee802154/nl802154.c:2978 with
.flags = GENL_ADMIN_PERM) so the legacy interface is the open side.
Any local uid with no capabilities can dump the AES-128 LLSEC keytable
of any wpan netdev that has an administrator-installed key. 802.15.4
LLSEC uses CCM*, so the same key authenticates and encrypts frames at
the chosen security level. One key leak compromises confidentiality
and authenticity at the link layer.
Patches:
1/2 ieee802154: admin-gate legacy LLSEC dump operations
Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but
with .flags = GENL_ADMIN_PERM. Switch the four LLSEC dump ops to
it. LIST_PHY and LIST_IFACE keep IEEE802154_DUMP() because the
modern nl802154 family exposes their equivalents to unprivileged
readers by design.
2/2 ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation
While reproducing the dump leak the LLSEC ADD/DEL doit handlers
turned out to have been silently dead since strict netlink
validation became the default: IEEE802154_ATTR_LLSEC_KEY_BYTES
and _KEY_USAGE_COMMANDS are declared as NLA_UNSPEC in
nl_policy.c, which validate_nla() rejects under
NL_VALIDATE_STRICT. Add IEEE802154_OP_RELAXED() with
.validate = GENL_DONT_VALIDATE_STRICT and switch the eight LLSEC
mutate ops to it. The dump ops keep strict validation; their
gate from patch 1/2 stands.
This would be a good time to revisit this thread from Alexander Aring:
https://lore.kernel.org/r/20160725121450.4093-4-aar@pengutronix.de
Ten years later the legacy interface is still in mainline and
(per patch 2/2) silently dead on the doit side anyway. Maintainers
who prefer to revive that deletion series should NACK patch 2/2 and
pick patch 1/2 alone; patch 1/2 plugs the key leak whether the
legacy doit path is ever brought back to life or removed entirely.
Reproduction
============
Tree: mainline 7.1-rc2 (22be7671cc3497f68d14555285c0ac221597c8eb),
x86 UML, KASAN off. Conditions: CONFIG_IEEE802154=y, CONFIG_MAC802154=y,
CONFIG_IEEE802154_HWSIM=y; one wpan netdev exists; an administrator
has installed an LLSEC key on it.
Harness: a userspace C program opens AF_NETLINK / NETLINK_GENERIC,
resolves the "802.15.4 MAC" family, and issues a CTRL_CMD_GETFAMILY
followed by a IEEE802154_LLSEC_LIST_KEY dump on wpan0. The dump
response is parsed for IEEE802154_ATTR_LLSEC_KEY_BYTES nested
attributes and the 16-byte payload is hex-printed. The runner drops
privileges to uid=1000 via setpriv with --bounding-set=-all and
--inh-caps=-all before invoking the dump.
For patch 2/2, the same harness shape sends a IEEE802154_LLSEC_ADD_KEY
request with policy-conformant attributes (frame counter, key ID
mode, key bytes, usage frame types) as root. The harness measures
whether the doit handler is reached (ieee802154_llsec_add_key()
return code visible via the netlink ack) or the dispatcher rejects
the request at the validate phase.
Stock vs patched outcomes (per patch):
1/2: stock dump returns the installed AES-128 key bytes
byte-identical to the unprivileged dumper; patched returns
-EPERM at the generic-netlink dispatch.
2/2: stock LLSEC_ADD_KEY as root returns "Unsupported attribute"
from __nla_validate_parse(); patched reaches
ieee802154_llsec_add_key() and installs the key.
Regression-adjacent runs (per patch):
1/2: LIST_PHY and LIST_IFACE dumps continue to succeed from an
unprivileged uid post-patch, mirroring the modern
NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE
behavior.
2/2: modern nl802154 NL802154_CMD_NEW_SEC_KEY (which is admin-
gated and uses NLA_NESTED policy entries, not NLA_UNSPEC)
continues to install keys unchanged.
Mitigations: a system administrator unwilling to ship patch 1/2
can mitigate the leak by building the kernel without
CONFIG_IEEE802154 or by ensuring no LLSEC key is installed on
any wpan netdev. There is no per-process mitigation.
Selftest gate: tools/testing/selftests/ has no matching binary
for the legacy IEEE802154_NL interface.
The trigger harness sources are available off-list on request.
Scope notes:
- The dump handler reuses the same struct ieee802154_llsec_key
storage as the modern nl802154 NEW_SEC_KEY path. Both interfaces
expose the same backing keytable; gating only the legacy dump is
the minimal fix.
- The two new macros sit alongside the existing two; no existing
callers change beyond the four LIST_LLSEC* lines (patch 1/2)
and the eight LLSEC ADD/DEL lines (patch 2/2).
Michael Bommarito (2):
ieee802154: admin-gate legacy LLSEC dump operations
ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation
net/ieee802154/ieee802154.h | 17 +++++++++++++++++
net/ieee802154/netlink.c | 36 ++++++++++++++++++------------------
2 files changed, 35 insertions(+), 18 deletions(-)
base-commit: 22be7671cc3497f68d14555285c0ac221597c8eb
--
2.53.0
^ permalink raw reply
* [PATCH wpan v3] ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit
From: Shitalkumar Gandhi @ 2026-05-20 10:57 UTC (permalink / raw)
To: Miquel Raynal, Alexander Aring, Stefan Schmidt
Cc: Simon Horman, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-wpan, netdev, linux-kernel,
stable, Shitalkumar Gandhi
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 2975 bytes --]
ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange
a kmalloc'd buffer pointer through a struct kfifo, but pass a literal
'4' as the byte count to kfifo_in()/kfifo_out().
This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the
low 4 bytes of the 8-byte pointer are written into the FIFO. The reader
then reads back 4 bytes into an 8-byte local pointer variable, leaving
the upper 4 bytes uninitialized stack data. The first dereference of
the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel
address and generally results in an oops.
Use sizeof(fifo_buffer) so the byte count matches pointer width on every
architecture.
The driver has no architecture restriction in Kconfig, so any 64-bit
build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has
been latent since the driver was added in 2017 because it is most
commonly deployed on 32-bit MCUs.
Found via a custom Coccinelle semantic patch hunting for short-byte
kfifo I/O on byte-mode kfifos used to shuttle pointers.
Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Cc: stable@vger.kernel.org
Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
Reviewed-by: Simon Horman <horms@kernel.org>
---
Changes in v3:
- Move declaration of `copied` to the top of the function (Miquèl)
Changes in v2:
- Use intermediate variable for kfifo_out() return value (Miquèl)
- Add Cc: stable@vger.kernel.org (Miquèl)
- Add Reviewed-by from Simon Horman (v1)
Link to v1: https://lore.kernel.org/linux-wpan/20260513153412.1284549-1-shitalkumar.gandhi@cambiumnetworks.com/
Link to v2: https://lore.kernel.org/all/20260520050707.38055-1-shitalkumar.gandhi@cambiumnetworks.com/
drivers/net/ieee802154/ca8210.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 753215ebc67c..1f1dafc5c5f6 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -597,7 +597,7 @@ static int ca8210_test_int_driver_write(
fifo_buffer = kmemdup(buf, len, GFP_KERNEL);
if (!fifo_buffer)
return -ENOMEM;
- kfifo_in(&test->up_fifo, &fifo_buffer, 4);
+ kfifo_in(&test->up_fifo, &fifo_buffer, sizeof(fifo_buffer));
wake_up_interruptible(&priv->test.readq);
return 0;
@@ -2528,6 +2528,7 @@ static ssize_t ca8210_test_int_user_read(
struct ca8210_priv *priv = filp->private_data;
unsigned char *fifo_buffer;
unsigned long bytes_not_copied;
+ unsigned int copied;
if (filp->f_flags & O_NONBLOCK) {
/* Non-blocking mode */
@@ -2541,7 +2542,8 @@ static ssize_t ca8210_test_int_user_read(
);
}
- if (kfifo_out(&priv->test.up_fifo, &fifo_buffer, 4) != 4) {
+ copied = kfifo_out(&priv->test.up_fifo, &fifo_buffer, sizeof(fifo_buffer));
+ if (copied != sizeof(fifo_buffer)) {
dev_err(
&priv->spi->dev,
"test_interface: Wrong number of elements popped from upstream fifo\n"
--
2.25.1
^ permalink raw reply related
* Re: [PATCH wpan v2] ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit
From: Miquel Raynal @ 2026-05-20 8:11 UTC (permalink / raw)
To: Shitalkumar Gandhi
Cc: Alexander Aring, Stefan Schmidt, Simon Horman, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-wpan, netdev, linux-kernel, stable, Shitalkumar Gandhi
In-Reply-To: <20260520050707.38055-1-shitalkumar.gandhi@cambiumnetworks.com>
Hi,
> @@ -2540,8 +2540,10 @@ static ssize_t ca8210_test_int_user_read(
> !kfifo_is_empty(&priv->test.up_fifo)
> );
> }
> + unsigned int copied;
Why is this declaration in the middle of the code? It should be at the
top,no?
Thanks,
Miquèl
^ permalink raw reply
* [PATCH wpan v2] ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit
From: Shitalkumar Gandhi @ 2026-05-20 5:07 UTC (permalink / raw)
To: Miquel Raynal, Alexander Aring, Stefan Schmidt
Cc: Simon Horman, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-wpan, netdev, linux-kernel,
stable, Shitalkumar Gandhi
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 2588 bytes --]
ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange
a kmalloc'd buffer pointer through a struct kfifo, but pass a literal
'4' as the byte count to kfifo_in()/kfifo_out().
This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the
low 4 bytes of the 8-byte pointer are written into the FIFO. The reader
then reads back 4 bytes into an 8-byte local pointer variable, leaving
the upper 4 bytes uninitialized stack data. The first dereference of
the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel
address and generally results in an oops.
Use sizeof(fifo_buffer) so the byte count matches pointer width on every
architecture.
The driver has no architecture restriction in Kconfig, so any 64-bit
build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has
been latent since the driver was added in 2017 because it is most
commonly deployed on 32-bit MCUs.
Found via a custom Coccinelle semantic patch hunting for short-byte
kfifo I/O on byte-mode kfifos used to shuttle pointers.
Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Cc: stable@vger.kernel.org
Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
Reviewed-by: Simon Horman <horms@kernel.org>
---
Changes in v2:
- Use intermediate variable for kfifo_out() return value (Miquèl)
- Add Cc: stable@vger.kernel.org (Miquèl)
- Add Reviewed-by from Simon Horman (v1)
Link to v1: https://lore.kernel.org/linux-wpan/20260513153412.1284549-1-shitalkumar.gandhi@cambiumnetworks.com/
drivers/net/ieee802154/ca8210.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 753215ebc67c..828cee8a6101 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -597,7 +597,7 @@ static int ca8210_test_int_driver_write(
fifo_buffer = kmemdup(buf, len, GFP_KERNEL);
if (!fifo_buffer)
return -ENOMEM;
- kfifo_in(&test->up_fifo, &fifo_buffer, 4);
+ kfifo_in(&test->up_fifo, &fifo_buffer, sizeof(fifo_buffer));
wake_up_interruptible(&priv->test.readq);
return 0;
@@ -2540,8 +2540,10 @@ static ssize_t ca8210_test_int_user_read(
!kfifo_is_empty(&priv->test.up_fifo)
);
}
+ unsigned int copied;
- if (kfifo_out(&priv->test.up_fifo, &fifo_buffer, 4) != 4) {
+ copied = kfifo_out(&priv->test.up_fifo, &fifo_buffer, sizeof(fifo_buffer));
+ if (copied != sizeof(fifo_buffer)) {
dev_err(
&priv->spi->dev,
"test_interface: Wrong number of elements popped from upstream fifo\n"
--
2.25.1
^ permalink raw reply related
* Re: [PATCH wpan] ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit
From: Miquel Raynal @ 2026-05-18 11:56 UTC (permalink / raw)
To: Shitalkumar Gandhi
Cc: Alexander Aring, Stefan Schmidt, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-wpan, netdev,
linux-kernel, stable, Shitalkumar Gandhi
In-Reply-To: <20260513153412.1284549-1-shitalkumar.gandhi@cambiumnetworks.com>
Hi Shitalkumar,
Thanks for the patch!
[...]
> Found via a custom Coccinelle semantic patch hunting for short-byte
> kfifo I/O on byte-mode kfifos used to shuttle pointers.
>
> Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device
> driver")
I don't remember what the net rules are exactly, but this definitely
should be backported:
Cc: stable@vger.kernel.org
[...]
> - if (kfifo_out(&priv->test.up_fifo, &fifo_buffer, 4) != 4) {
> + if (kfifo_out(&priv->test.up_fifo, &fifo_buffer, sizeof(fifo_buffer))
> + != sizeof(fifo_buffer)) {
This line becomes unreadable. Can you please use an intermediate
variable? Something like:
ret = kfifo_out(...);
if (ret != sizeof(...)) {
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH wpan] ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit
From: Simon Horman @ 2026-05-18 10:39 UTC (permalink / raw)
To: Shitalkumar Gandhi
Cc: Alexander Aring, Stefan Schmidt, Miquel Raynal, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-wpan, netdev, linux-kernel, stable, Shitalkumar Gandhi
In-Reply-To: <20260513153412.1284549-1-shitalkumar.gandhi@cambiumnetworks.com>
On Wed, May 13, 2026 at 09:04:12PM +0530, Shitalkumar Gandhi wrote:
> ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange
> a kmalloc'd buffer pointer through a struct kfifo, but pass a literal
> '4' as the byte count to kfifo_in()/kfifo_out().
>
> This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the
> low 4 bytes of the 8-byte pointer are written into the FIFO. The reader
> then reads back 4 bytes into an 8-byte local pointer variable, leaving
> the upper 4 bytes uninitialized stack data. The first dereference of
> the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel
> address and generally results in an oops.
>
> Use sizeof(fifo_buffer) so the byte count matches pointer width on every
> architecture.
>
> The driver has no architecture restriction in Kconfig, so any 64-bit
> build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has
> been latent since the driver was added in 2017 because it is most
> commonly deployed on 32-bit MCUs.
>
> Found via a custom Coccinelle semantic patch hunting for short-byte
> kfifo I/O on byte-mode kfifos used to shuttle pointers.
>
> Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
> Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
Reviewed-by: Simon Horman <horms@kernel.org>
There is an AI-generated review of this patch available on sashiko.dev
However, I believe the issues flagged there can be considered in
the context of possible follow-up. And should not block progress of
this patch.
^ permalink raw reply
* [PATCH wpan] ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit
From: Shitalkumar Gandhi @ 2026-05-13 15:34 UTC (permalink / raw)
To: Alexander Aring, Stefan Schmidt, Miquel Raynal
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-wpan, netdev, linux-kernel, stable,
Shitalkumar Gandhi
ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange
a kmalloc'd buffer pointer through a struct kfifo, but pass a literal
'4' as the byte count to kfifo_in()/kfifo_out().
This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the
low 4 bytes of the 8-byte pointer are written into the FIFO. The reader
then reads back 4 bytes into an 8-byte local pointer variable, leaving
the upper 4 bytes uninitialized stack data. The first dereference of
the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel
address and generally results in an oops.
Use sizeof(fifo_buffer) so the byte count matches pointer width on every
architecture.
The driver has no architecture restriction in Kconfig, so any 64-bit
build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has
been latent since the driver was added in 2017 because it is most
commonly deployed on 32-bit MCUs.
Found via a custom Coccinelle semantic patch hunting for short-byte
kfifo I/O on byte-mode kfifos used to shuttle pointers.
Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
---
drivers/net/ieee802154/ca8210.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 753215ebc67c..154af346c936 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -597,7 +597,7 @@ static int ca8210_test_int_driver_write(
fifo_buffer = kmemdup(buf, len, GFP_KERNEL);
if (!fifo_buffer)
return -ENOMEM;
- kfifo_in(&test->up_fifo, &fifo_buffer, 4);
+ kfifo_in(&test->up_fifo, &fifo_buffer, sizeof(fifo_buffer));
wake_up_interruptible(&priv->test.readq);
return 0;
@@ -2541,7 +2541,8 @@ static ssize_t ca8210_test_int_user_read(
);
}
- if (kfifo_out(&priv->test.up_fifo, &fifo_buffer, 4) != 4) {
+ if (kfifo_out(&priv->test.up_fifo, &fifo_buffer, sizeof(fifo_buffer))
+ != sizeof(fifo_buffer)) {
dev_err(
&priv->spi->dev,
"test_interface: Wrong number of elements popped from upstream fifo\n"
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] net: iphc: fix offset errors in multicast context compression
From: Simon Horman @ 2026-05-08 13:21 UTC (permalink / raw)
To: Quan Sun; +Cc: linux-wpan, netdev, alex.aring, davem, edumazet, andrew
In-Reply-To: <20260505163146.432309-1-2022090917019@std.uestc.edu.cn>
On Wed, May 06, 2026 at 12:31:46AM +0800, Quan Sun wrote:
> The function lowpan_iphc_mcast_ctx_addr_compress() contains two offset
> errors that break context-based multicast address compression
> (LOWPAN_IPHC_DAM_00).
>
> When compressing the multicast address, the compressed format expects
> exactly 6 bytes:
> - Bytes 0-1: Flags, scope, and reserved bits (from s6_addr[1..2])
> - Bytes 2-5: The 4-byte Group ID (from s6_addr[12..15])
>
> Currently, the memcpy() operations use incorrect offsets:
> 1. The destination offset for the Group ID is &data[1] instead of
> &data[2]. This overwrites the previously copied scope byte.
> 2. The source offset for the Group ID is &ipaddr->s6_addr[11] instead
> of &ipaddr->s6_addr[12].
>
> This mismatch results in a corrupted compressed address being
> transmitted. Consequently, the receiving side fails to reconstruct the
> original IPv6 address via lowpan_uncompress_multicast_ctx_daddr() since
> it expects the Group ID to start at data[2].
>
> Fix the logic by correcting both the destination and source offsets
> so that the 6-byte compressed representation is assembled correctly.
Thanks,
This matches my understanding of:
RFC 6382 Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
-> Section 3.2.4. Stateful Multicast Address Compression
https://www.rfc-editor.org/rfc/rfc6282#section-3.2.4
And it's reference to
RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses
-> Section 4. Multicast Address Format
https://www.rfc-editor.org/rfc/rfc3306#section-4
RFC 6382 is referred to by
RFC 6775 Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)
- https://www.rfc-editor.org/rfc/rfc6775.html
Which is in turn referred to by
RFC 8138 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
Routing Header
-> Section 4.3. Compressing Addresses
https://www.rfc-editor.org/rfc/rfc8138.html#section-4.3
> Signed-off-by: Quan Sun <2022090917019@std.uestc.edu.cn>
As a fix this should have a fixes tag.
I think this one is appropriate.
Fixes: 5609c185f24d ("6lowpan: iphc: add support for stateful compression")
I don't think you need to repost because of this, but for future reference,
fixes for Networking code present in the net tree should be targeted at
that tree. This includes making sure the patch applies to that tree
(I assume this one does) and including net, as opposed to net-next,
in the patch subject like this:
Subject: [PATCH net] ...
Also, as a fix this probably waranted being CCed to stable.
For more information on Networking development process please see
https://docs.kernel.org/process/maintainer-netdev.html
The last two points not withstanding, this looks good to me.
Reviewed-by: Simon Horman <horms@kernel.org>
...
^ permalink raw reply
* [PATCH] net: iphc: fix offset errors in multicast context compression
From: Quan Sun @ 2026-05-05 16:31 UTC (permalink / raw)
To: linux-wpan, netdev; +Cc: alex.aring, davem, edumazet, andrew, Quan Sun
The function lowpan_iphc_mcast_ctx_addr_compress() contains two offset
errors that break context-based multicast address compression
(LOWPAN_IPHC_DAM_00).
When compressing the multicast address, the compressed format expects
exactly 6 bytes:
- Bytes 0-1: Flags, scope, and reserved bits (from s6_addr[1..2])
- Bytes 2-5: The 4-byte Group ID (from s6_addr[12..15])
Currently, the memcpy() operations use incorrect offsets:
1. The destination offset for the Group ID is &data[1] instead of
&data[2]. This overwrites the previously copied scope byte.
2. The source offset for the Group ID is &ipaddr->s6_addr[11] instead
of &ipaddr->s6_addr[12].
This mismatch results in a corrupted compressed address being
transmitted. Consequently, the receiving side fails to reconstruct the
original IPv6 address via lowpan_uncompress_multicast_ctx_daddr() since
it expects the Group ID to start at data[2].
Fix the logic by correcting both the destination and source offsets
so that the 6-byte compressed representation is assembled correctly.
Signed-off-by: Quan Sun <2022090917019@std.uestc.edu.cn>
---
net/6lowpan/iphc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index e116d308a8df6..29ae68ca3ec15 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -1091,7 +1091,7 @@ static u8 lowpan_iphc_mcast_ctx_addr_compress(u8 **hc_ptr,
/* flags/scope, reserved (RIID) */
memcpy(data, &ipaddr->s6_addr[1], 2);
/* group ID */
- memcpy(&data[1], &ipaddr->s6_addr[11], 4);
+ memcpy(&data[2], &ipaddr->s6_addr[12], 4);
lowpan_push_hc_data(hc_ptr, data, 6);
return LOWPAN_IPHC_DAM_00;
base-commit: 95084f1883a760e0d4290698346759d58e2b944a
--
2.43.0
^ permalink raw reply related
* Re: Vulnerability Report: Logical Error in 6LoWPAN Multicast Context Address Compression
From: Andrew Lunn @ 2026-05-05 13:01 UTC (permalink / raw)
To: Quan Sun; +Cc: linux-wpan, netdev, alex.aring, davem, edumazet
In-Reply-To: <15e69058-da2e-4a4d-8bda-ad89da0ae6f7@std.uestc.edu.cn>
On Tue, May 05, 2026 at 05:18:34PM +0800, Quan Sun wrote:
> ## 1. Summary
> A logical vulnerability exists in the 6LoWPAN IPHC (IP Header Compression)
> subsystem of the Linux kernel, specifically within the
> `lowpan_iphc_mcast_ctx_addr_compress` function in `net/6lowpan/iphc.c`.
>
> The function uses incorrect memory offsets during the `memcpy` operations
> intended to compress an IPv6 multicast address. This mismatch in offsets
> results in an incorrectly formed compressed address being transmitted over
> the network, which is incompatible with the corresponding decompression
> logic. Consequently, context-based multicast address compression in 6LoWPAN
> is broken and fails to operate as defined by the protocol.
>
> ## 2. Vulnerability Details
>
> According to 6LoWPAN address compression standards (and aligning with the
> decompression function `lowpan_uncompress_multicast_ctx_daddr`), a
> context-based compressed multicast address should be represented by exactly
> 6 bytes:
> * **Bytes 0-1:** Derived from `s6_addr[1]` and `s6_addr[2]` (Flags, Scope,
> and Reserved bits).
> * **Bytes 2-5:** Derived from `s6_addr[12]` to `s6_addr[15]` (The 4-byte
> Group ID).
>
> However, in the compression function `lowpan_iphc_mcast_ctx_addr_compress`,
> the offsets provided to the `memcpy` calls are flawed:
>
> ```c
> static u8 lowpan_iphc_mcast_ctx_addr_compress(u8 **hc_ptr,
> const struct lowpan_iphc_ctx *ctx,
> const struct in6_addr *ipaddr)
> {
> u8 data[6];
>
> /* flags/scope, reserved (RIID) */
> memcpy(data, &ipaddr->s6_addr[1], 2);
> /* group ID */
> memcpy(&data[1], &ipaddr->s6_addr[11], 4);
> lowpan_push_hc_data(hc_ptr, data, 6);
>
> return LOWPAN_IPHC_DAM_00;
> }
> ```
>
> ### Analysis of the Error:
> 1. **Incorrect Destination Offset:** The second `memcpy` writes to
> `&data[1]` instead of `&data[2]`. This overwrites the byte previously copied
> from `s6_addr[2]` into `data[1]`.
> 2. **Incorrect Source Offset:** The source address is specified as
> `&ipaddr->s6_addr[11]` instead of `&ipaddr->s6_addr[12]`. This means it
> begins reading from the last byte of the network prefix rather than the
> start of the 4-byte Group ID.
>
> Because the compression formatting does not match the expected structure
> required by the decompression function, multicast packets utilizing
> context-based compression will be corrupted upon transmission.
>
> ## 3. Impact
> This vulnerability breaks the Context-Based Multicast Address Compression
> feature (`LOWPAN_IPHC_DAM_00` when `M` and `DAC` bits are set) in 6LoWPAN
> networks. Nodes receiving these packets will incorrectly decompress the
> destination multicast address, leading to dropped packets and communication
> failures within the multicast group.
>
> ## 4. Suggested Fix
> The fix requires adjusting both the destination and source offsets in the
> second `memcpy` call to correctly place the 4-byte Group ID into the
> compressed `data` buffer.
>
> ### Proposed Patch:
>
> ```diff
> --- a/net/6lowpan/iphc.c
> +++ b/net/6lowpan/iphc.c
> @@ -1084,9 +1084,9 @@ static u8 lowpan_iphc_mcast_ctx_addr_compress(u8
> **hc_ptr,
> u8 data[6];
>
> /* flags/scope, reserved (RIID) */
> memcpy(data, &ipaddr->s6_addr[1], 2);
> /* group ID */
> - memcpy(&data[1], &ipaddr->s6_addr[11], 4);
> + memcpy(&data[2], &ipaddr->s6_addr[12], 4);
> lowpan_push_hc_data(hc_ptr, data, 6);
>
> return LOWPAN_IPHC_DAM_00;
> }
Since you have a fix, why not just submit a proper patch in the usual
way?
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
https://docs.kernel.org/process/submitting-patches.html
Andrew
---
pw-bot: cr
^ permalink raw reply
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox