* [syzbot] [crypto?] BUG: unable to handle kernel paging request in ieee80211_wep_encrypt @ 2025-07-17 10:15 syzbot 2025-07-18 14:50 ` [syzbot] [wireless] " Eric Biggers 0 siblings, 1 reply; 4+ messages in thread From: syzbot @ 2025-07-17 10:15 UTC (permalink / raw) To: ardb, bp, dave.hansen, ebiggers, hpa, linux-crypto, linux-kernel, mingo, netdev, syzkaller-bugs, tglx, x86 Hello, syzbot found the following issue on: HEAD commit: 5e28d5a3f774 net/sched: sch_qfq: Fix race condition on qfq.. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=146550f0580000 kernel config: https://syzkaller.appspot.com/x/.config?x=b309c907eaab29da dashboard link: https://syzkaller.appspot.com/bug?extid=d1008c24929007591b6b compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7 Unfortunately, I don't have any reproducer for this issue yet. Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/897daa1d604c/disk-5e28d5a3.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/0d5527eee75d/vmlinux-5e28d5a3.xz kernel image: https://storage.googleapis.com/syzbot-assets/31ee968efcd7/bzImage-5e28d5a3.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+d1008c24929007591b6b@syzkaller.appspotmail.com BUG: unable to handle page fault for address: ffff8880bfffd000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1a201067 P4D 1a201067 PUD 23ffff067 PMD 23fffe067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 8097 Comm: syz.1.594 Not tainted 6.16.0-rc5-syzkaller-00183-g5e28d5a3f774 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:crc32_lsb_pclmul_sse+0x8f/0x220 arch/x86/lib/crc32-pclmul.S:6 Code: 0f 3a 44 c7 11 66 0f ef ec 66 0f ef c5 f3 0f 6f 66 10 66 0f 6f e9 66 0f 3a 44 ef 00 66 0f 3a 44 cf 11 66 0f ef ec 66 0f ef cd <f3> 0f 6f 66 20 66 0f 6f ea 66 0f 3a 44 ef 00 66 0f 3a 44 d7 11 66 RSP: 0018:ffffc9001bcae6f8 EFLAGS: 00010296 RAX: e4cc01b02de40500 RBX: fffffffffffffffe RCX: ffffffff8be53dc0 RDX: ffffffff7301ca7e RSI: ffff8880bfffcfde RDI: 00000000ffffffff RBP: 00000000ffffffff R08: ffff88801cb09e07 R09: 1ffff110039613c0 R10: dffffc0000000000 R11: ffffed10039613c1 R12: fffffffffffffffe R13: ffff888033019a5e R14: ffff888033019a5e R15: ffff888067eeec80 FS: 00007f4779be36c0(0000) GS:ffff888125d1b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8880bfffd000 CR3: 00000000671a8000 CR4: 00000000003526f0 Call Trace: <TASK> crc32_le_arch+0x56/0xa0 arch/x86/lib/crc32.c:21 crc32_le include/linux/crc32.h:18 [inline] ieee80211_wep_encrypt_data net/mac80211/wep.c:114 [inline] ieee80211_wep_encrypt+0x228/0x410 net/mac80211/wep.c:158 wep_encrypt_skb net/mac80211/wep.c:277 [inline] ieee80211_crypto_wep_encrypt+0x1f6/0x320 net/mac80211/wep.c:300 invoke_tx_handlers_late+0x1145/0x1820 net/mac80211/tx.c:1846 ieee80211_tx_dequeue+0x3068/0x4340 net/mac80211/tx.c:3916 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x125/0x2a0 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1367 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1374 [inline] ieee80211_queue_skb+0x19e8/0x2180 net/mac80211/tx.c:1648 ieee80211_tx+0x297/0x420 net/mac80211/tx.c:1951 __ieee80211_tx_skb_tid_band+0x50f/0x680 net/mac80211/tx.c:6103 ieee80211_tx_skb_tid+0x266/0x420 net/mac80211/tx.c:6131 ieee80211_mgmt_tx+0x1c25/0x21d0 net/mac80211/offchannel.c:1023 rdev_mgmt_tx net/wireless/rdev-ops.h:762 [inline] cfg80211_mlme_mgmt_tx+0x7f2/0x1620 net/wireless/mlme.c:938 nl80211_tx_mgmt+0x9fd/0xd50 net/wireless/nl80211.c:12921 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x205/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x75c/0x8e0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x505/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2655 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4778d8e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4779be3038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f4778fb6080 RCX: 00007f4778d8e929 RDX: 0000000024008080 RSI: 0000200000000c00 RDI: 0000000000000005 RBP: 00007f4778e10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4778fb6080 R15: 00007ffff7e551c8 </TASK> Modules linked in: CR2: ffff8880bfffd000 ---[ end trace 0000000000000000 ]--- RIP: 0010:crc32_lsb_pclmul_sse+0x8f/0x220 arch/x86/lib/crc32-pclmul.S:6 Code: 0f 3a 44 c7 11 66 0f ef ec 66 0f ef c5 f3 0f 6f 66 10 66 0f 6f e9 66 0f 3a 44 ef 00 66 0f 3a 44 cf 11 66 0f ef ec 66 0f ef cd <f3> 0f 6f 66 20 66 0f 6f ea 66 0f 3a 44 ef 00 66 0f 3a 44 d7 11 66 RSP: 0018:ffffc9001bcae6f8 EFLAGS: 00010296 RAX: e4cc01b02de40500 RBX: fffffffffffffffe RCX: ffffffff8be53dc0 RDX: ffffffff7301ca7e RSI: ffff8880bfffcfde RDI: 00000000ffffffff RBP: 00000000ffffffff R08: ffff88801cb09e07 R09: 1ffff110039613c0 R10: dffffc0000000000 R11: ffffed10039613c1 R12: fffffffffffffffe R13: ffff888033019a5e R14: ffff888033019a5e R15: ffff888067eeec80 FS: 00007f4779be36c0(0000) GS:ffff888125d1b000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8880bfffd000 CR3: 00000000671a8000 CR4: 00000000003526f0 ---------------- Code disassembly (best guess), 1 bytes skipped: 0: 3a 44 c7 11 cmp 0x11(%rdi,%rax,8),%al 4: 66 0f ef ec pxor %xmm4,%xmm5 8: 66 0f ef c5 pxor %xmm5,%xmm0 c: f3 0f 6f 66 10 movdqu 0x10(%rsi),%xmm4 11: 66 0f 6f e9 movdqa %xmm1,%xmm5 15: 66 0f 3a 44 ef 00 pclmullqlqdq %xmm7,%xmm5 1b: 66 0f 3a 44 cf 11 pclmulhqhqdq %xmm7,%xmm1 21: 66 0f ef ec pxor %xmm4,%xmm5 25: 66 0f ef cd pxor %xmm5,%xmm1 * 29: f3 0f 6f 66 20 movdqu 0x20(%rsi),%xmm4 <-- trapping instruction 2e: 66 0f 6f ea movdqa %xmm2,%xmm5 32: 66 0f 3a 44 ef 00 pclmullqlqdq %xmm7,%xmm5 38: 66 0f 3a 44 d7 11 pclmulhqhqdq %xmm7,%xmm2 3e: 66 data16 --- 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 [flat|nested] 4+ messages in thread
* Re: [syzbot] [wireless] BUG: unable to handle kernel paging request in ieee80211_wep_encrypt 2025-07-17 10:15 [syzbot] [crypto?] BUG: unable to handle kernel paging request in ieee80211_wep_encrypt syzbot @ 2025-07-18 14:50 ` Eric Biggers 2025-07-18 15:57 ` Johannes Berg 0 siblings, 1 reply; 4+ messages in thread From: Eric Biggers @ 2025-07-18 14:50 UTC (permalink / raw) To: linux-wireless, Johannes Berg Cc: syzbot, ardb, bp, dave.hansen, hpa, linux-crypto, linux-kernel, mingo, netdev, syzkaller-bugs, tglx, x86 [+linux-wireless and Johannes for ieee80211_wep_encrypt] On Thu, Jul 17, 2025 at 03:15:37AM -0700, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: 5e28d5a3f774 net/sched: sch_qfq: Fix race condition on qfq.. > git tree: net > console output: https://syzkaller.appspot.com/x/log.txt?x=146550f0580000 > kernel config: https://syzkaller.appspot.com/x/.config?x=b309c907eaab29da > dashboard link: https://syzkaller.appspot.com/bug?extid=d1008c24929007591b6b > compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7 > > Unfortunately, I don't have any reproducer for this issue yet. > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/897daa1d604c/disk-5e28d5a3.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/0d5527eee75d/vmlinux-5e28d5a3.xz > kernel image: https://storage.googleapis.com/syzbot-assets/31ee968efcd7/bzImage-5e28d5a3.xz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+d1008c24929007591b6b@syzkaller.appspotmail.com > > BUG: unable to handle page fault for address: ffff8880bfffd000 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 1a201067 P4D 1a201067 PUD 23ffff067 PMD 23fffe067 PTE 0 > Oops: Oops: 0000 [#1] SMP KASAN PTI > CPU: 1 UID: 0 PID: 8097 Comm: syz.1.594 Not tainted 6.16.0-rc5-syzkaller-00183-g5e28d5a3f774 #0 PREEMPT(full) > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 > RIP: 0010:crc32_lsb_pclmul_sse+0x8f/0x220 arch/x86/lib/crc32-pclmul.S:6 > Code: 0f 3a 44 c7 11 66 0f ef ec 66 0f ef c5 f3 0f 6f 66 10 66 0f 6f e9 66 0f 3a 44 ef 00 66 0f 3a 44 cf 11 66 0f ef ec 66 0f ef cd <f3> 0f 6f 66 20 66 0f 6f ea 66 0f 3a 44 ef 00 66 0f 3a 44 d7 11 66 > RSP: 0018:ffffc9001bcae6f8 EFLAGS: 00010296 > RAX: e4cc01b02de40500 RBX: fffffffffffffffe RCX: ffffffff8be53dc0 > RDX: ffffffff7301ca7e RSI: ffff8880bfffcfde RDI: 00000000ffffffff > RBP: 00000000ffffffff R08: ffff88801cb09e07 R09: 1ffff110039613c0 > R10: dffffc0000000000 R11: ffffed10039613c1 R12: fffffffffffffffe > R13: ffff888033019a5e R14: ffff888033019a5e R15: ffff888067eeec80 > FS: 00007f4779be36c0(0000) GS:ffff888125d1b000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: ffff8880bfffd000 CR3: 00000000671a8000 CR4: 00000000003526f0 > Call Trace: > <TASK> > crc32_le_arch+0x56/0xa0 arch/x86/lib/crc32.c:21 > crc32_le include/linux/crc32.h:18 [inline] > ieee80211_wep_encrypt_data net/mac80211/wep.c:114 [inline] > ieee80211_wep_encrypt+0x228/0x410 net/mac80211/wep.c:158 > wep_encrypt_skb net/mac80211/wep.c:277 [inline] > ieee80211_crypto_wep_encrypt+0x1f6/0x320 net/mac80211/wep.c:300 > invoke_tx_handlers_late+0x1145/0x1820 net/mac80211/tx.c:1846 > ieee80211_tx_dequeue+0x3068/0x4340 net/mac80211/tx.c:3916 > wake_tx_push_queue net/mac80211/util.c:294 [inline] > ieee80211_handle_wake_tx_queue+0x125/0x2a0 net/mac80211/util.c:315 > drv_wake_tx_queue net/mac80211/driver-ops.h:1367 [inline] > schedule_and_wake_txq net/mac80211/driver-ops.h:1374 [inline] > ieee80211_queue_skb+0x19e8/0x2180 net/mac80211/tx.c:1648 > ieee80211_tx+0x297/0x420 net/mac80211/tx.c:1951 > __ieee80211_tx_skb_tid_band+0x50f/0x680 net/mac80211/tx.c:6103 > ieee80211_tx_skb_tid+0x266/0x420 net/mac80211/tx.c:6131 > ieee80211_mgmt_tx+0x1c25/0x21d0 net/mac80211/offchannel.c:1023 > rdev_mgmt_tx net/wireless/rdev-ops.h:762 [inline] > cfg80211_mlme_mgmt_tx+0x7f2/0x1620 net/wireless/mlme.c:938 > nl80211_tx_mgmt+0x9fd/0xd50 net/wireless/nl80211.c:12921 > genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 > genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] > genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 > netlink_rcv_skb+0x205/0x470 net/netlink/af_netlink.c:2552 > genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 > netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] > netlink_unicast+0x75c/0x8e0 net/netlink/af_netlink.c:1346 > netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 > sock_sendmsg_nosec net/socket.c:712 [inline] > __sock_sendmsg+0x219/0x270 net/socket.c:727 > ____sys_sendmsg+0x505/0x830 net/socket.c:2566 > ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 > __sys_sendmsg net/socket.c:2652 [inline] > __do_sys_sendmsg net/socket.c:2657 [inline] > __se_sys_sendmsg net/socket.c:2655 [inline] > __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2655 > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] > do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > RIP: 0033:0x7f4778d8e929 > Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007f4779be3038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e > RAX: ffffffffffffffda RBX: 00007f4778fb6080 RCX: 00007f4778d8e929 > RDX: 0000000024008080 RSI: 0000200000000c00 RDI: 0000000000000005 > RBP: 00007f4778e10b39 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 > R13: 0000000000000000 R14: 00007f4778fb6080 R15: 00007ffff7e551c8 > </TASK> > Modules linked in: > CR2: ffff8880bfffd000 > ---[ end trace 0000000000000000 ]--- > RIP: 0010:crc32_lsb_pclmul_sse+0x8f/0x220 arch/x86/lib/crc32-pclmul.S:6 > Code: 0f 3a 44 c7 11 66 0f ef ec 66 0f ef c5 f3 0f 6f 66 10 66 0f 6f e9 66 0f 3a 44 ef 00 66 0f 3a 44 cf 11 66 0f ef ec 66 0f ef cd <f3> 0f 6f 66 20 66 0f 6f ea 66 0f 3a 44 ef 00 66 0f 3a 44 d7 11 66 > RSP: 0018:ffffc9001bcae6f8 EFLAGS: 00010296 > RAX: e4cc01b02de40500 RBX: fffffffffffffffe RCX: ffffffff8be53dc0 > RDX: ffffffff7301ca7e RSI: ffff8880bfffcfde RDI: 00000000ffffffff > RBP: 00000000ffffffff R08: ffff88801cb09e07 R09: 1ffff110039613c0 > R10: dffffc0000000000 R11: ffffed10039613c1 R12: fffffffffffffffe > R13: ffff888033019a5e R14: ffff888033019a5e R15: ffff888067eeec80 > FS: 00007f4779be36c0(0000) GS:ffff888125d1b000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: ffff8880bfffd000 CR3: 00000000671a8000 CR4: 00000000003526f0 > ---------------- > Code disassembly (best guess), 1 bytes skipped: > 0: 3a 44 c7 11 cmp 0x11(%rdi,%rax,8),%al > 4: 66 0f ef ec pxor %xmm4,%xmm5 > 8: 66 0f ef c5 pxor %xmm5,%xmm0 > c: f3 0f 6f 66 10 movdqu 0x10(%rsi),%xmm4 > 11: 66 0f 6f e9 movdqa %xmm1,%xmm5 > 15: 66 0f 3a 44 ef 00 pclmullqlqdq %xmm7,%xmm5 > 1b: 66 0f 3a 44 cf 11 pclmulhqhqdq %xmm7,%xmm1 > 21: 66 0f ef ec pxor %xmm4,%xmm5 > 25: 66 0f ef cd pxor %xmm5,%xmm1 > * 29: f3 0f 6f 66 20 movdqu 0x20(%rsi),%xmm4 <-- trapping instruction > 2e: 66 0f 6f ea movdqa %xmm2,%xmm5 > 32: 66 0f 3a 44 ef 00 pclmullqlqdq %xmm7,%xmm5 > 38: 66 0f 3a 44 d7 11 pclmulhqhqdq %xmm7,%xmm2 > 3e: 66 data16 > > > --- > 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 syzbot assigned this to the "crypto" subsystem. However, the crash happened in crc32_le() which is not part of the crypto subsystem. Also, crc32_le() is well-tested (e.g. by crc_kunit), and the bug is unlikely to be there. Rather, the calling code in ieee80211_wep_encrypt_data() is passing an invalid data buffer to crc32_le(). So let's do: #syz set subsystems: wireless ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] [wireless] BUG: unable to handle kernel paging request in ieee80211_wep_encrypt 2025-07-18 14:50 ` [syzbot] [wireless] " Eric Biggers @ 2025-07-18 15:57 ` Johannes Berg 2025-07-18 18:03 ` Johannes Berg 0 siblings, 1 reply; 4+ messages in thread From: Johannes Berg @ 2025-07-18 15:57 UTC (permalink / raw) To: Eric Biggers, linux-wireless Cc: syzbot, ardb, bp, dave.hansen, hpa, linux-crypto, linux-kernel, mingo, netdev, syzkaller-bugs, tglx, x86 On Fri, 2025-07-18 at 07:50 -0700, Eric Biggers wrote: > > > > BUG: unable to handle page fault for address: ffff8880bfffd000 [...] > > Call Trace: > > <TASK> > > crc32_le_arch+0x56/0xa0 arch/x86/lib/crc32.c:21 > > crc32_le include/linux/crc32.h:18 [inline] > > ieee80211_wep_encrypt_data net/mac80211/wep.c:114 [inline] > > ieee80211_wep_encrypt+0x228/0x410 net/mac80211/wep.c:158 [...] > > nl80211_tx_mgmt+0x9fd/0xd50 net/wireless/nl80211.c:12921 > > syzbot assigned this to the "crypto" subsystem. However, the crash > happened in crc32_le() which is not part of the crypto subsystem. Also, > crc32_le() is well-tested (e.g. by crc_kunit), and the bug is unlikely > to be there. Rather, the calling code in ieee80211_wep_encrypt_data() > is passing an invalid data buffer to crc32_le(). So let's do: Agree, that makes sense, looks like we never check the frame length correctly. Since there's no reproducer (yet) I guess we won't be testing against it with syzbot though :) johannes ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [syzbot] [wireless] BUG: unable to handle kernel paging request in ieee80211_wep_encrypt 2025-07-18 15:57 ` Johannes Berg @ 2025-07-18 18:03 ` Johannes Berg 0 siblings, 0 replies; 4+ messages in thread From: Johannes Berg @ 2025-07-18 18:03 UTC (permalink / raw) To: Eric Biggers, linux-wireless Cc: syzbot, ardb, bp, dave.hansen, hpa, linux-crypto, linux-kernel, mingo, netdev, syzkaller-bugs, tglx, x86 On Fri, 2025-07-18 at 17:57 +0200, Johannes Berg wrote: > On Fri, 2025-07-18 at 07:50 -0700, Eric Biggers wrote: > > > > > > BUG: unable to handle page fault for address: ffff8880bfffd000 > [...] > > > Call Trace: > > > <TASK> > > > crc32_le_arch+0x56/0xa0 arch/x86/lib/crc32.c:21 > > > crc32_le include/linux/crc32.h:18 [inline] > > > ieee80211_wep_encrypt_data net/mac80211/wep.c:114 [inline] > > > ieee80211_wep_encrypt+0x228/0x410 net/mac80211/wep.c:158 > [...] > > > nl80211_tx_mgmt+0x9fd/0xd50 net/wireless/nl80211.c:12921 > > > > syzbot assigned this to the "crypto" subsystem. However, the crash > > happened in crc32_le() which is not part of the crypto subsystem. Also, > > crc32_le() is well-tested (e.g. by crc_kunit), and the bug is unlikely > > to be there. Rather, the calling code in ieee80211_wep_encrypt_data() > > is passing an invalid data buffer to crc32_le(). So let's do: > > Agree, that makes sense, looks like we never check the frame length > correctly. Since there's no reproducer (yet) I guess we won't be testing > against it with syzbot though :) Well, hmm. So we're in int ieee80211_wep_encrypt_data(struct arc4_ctx *ctx, u8 *rc4key, size_t klen, u8 *data, size_t data_len) { __le32 icv; icv = cpu_to_le32(~crc32_le(~0, data, data_len)); with presumably data/data_len being garbage. Via int ieee80211_wep_encrypt(struct ieee80211_local *local, struct sk_buff *skb, const u8 *key, int keylen, int keyidx) { u8 *iv; size_t len; u8 rc4key[3 + WLAN_KEY_LEN_WEP104]; if (WARN_ON(skb_tailroom(skb) < IEEE80211_WEP_ICV_LEN)) return -1; iv = ieee80211_wep_add_iv(local, skb, keylen, keyidx); if (!iv) return -1; len = skb->len - (iv + IEEE80211_WEP_IV_LEN - skb->data); which _looks_ OK at first, however, looking at static u8 *ieee80211_wep_add_iv(struct ieee80211_local *local, struct sk_buff *skb, int keylen, int keyidx) { struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data; struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb); unsigned int hdrlen; u8 *newhdr; hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_PROTECTED); if (WARN_ON(skb_headroom(skb) < IEEE80211_WEP_IV_LEN)) return NULL; hdrlen = ieee80211_hdrlen(hdr->frame_control); newhdr = skb_push(skb, IEEE80211_WEP_IV_LEN); memmove(newhdr, newhdr + IEEE80211_WEP_IV_LEN, hdrlen); /* the HW only needs room for the IV, but not the actual IV */ if (info->control.hw_key && (info->control.hw_key->flags & IEEE80211_KEY_FLAG_PUT_IV_SPACE)) return newhdr + hdrlen; ieee80211_wep_get_iv(local, keylen, keyidx, newhdr + hdrlen); return newhdr + hdrlen; } there's no check that the skb->len is actually >= hdrlen(), in which case we would return an 'iv' that's outside of [skb->data..+len]. Then the len = skb->len - (iv + IEEE80211_WEP_IV_LEN - skb->data); subtraction could underflow and result in this issue, I guess. But the stack dump is strange in that we appear to get here via nl80211_tx_mgmt() which only accepts management frames, but ieee80211_tx_h_select_key() at least for WEP will NULL out the key for !data frames, and then we can't get into the encrypt functions. Data frames are always built by the kernel itself, so shouldn't get into some kind of weird "header is shorter than the frame" situation. It's theoretically possible that this is a _different_ frame being dequeued than was just enqueued, but that seems like quite a stretch since we just immediately dequeue after the enqueue with the hwsim implementation ... and I'm not sure where that frame would come from anyway. So right now I have no idea what's going on here, nothing seems right. johannes ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-07-18 18:03 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-07-17 10:15 [syzbot] [crypto?] BUG: unable to handle kernel paging request in ieee80211_wep_encrypt syzbot 2025-07-18 14:50 ` [syzbot] [wireless] " Eric Biggers 2025-07-18 15:57 ` Johannes Berg 2025-07-18 18:03 ` Johannes Berg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox