[syzbot] [crypto?] BUG: unable to handle kernel paging request in ieee80211_wep_encrypt

[syzbot] [crypto?] BUG: unable to handle kernel paging request in ieee80211_wep_encrypt

[syzbot]

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

Re: [syzbot] [wireless] BUG: unable to handle kernel paging request in ieee80211_wep_encrypt

[Eric Biggers]

[+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

Re: [syzbot] [wireless] BUG: unable to handle kernel paging request in ieee80211_wep_encrypt

[Johannes Berg]

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

Re: [syzbot] [wireless] BUG: unable to handle kernel paging request in ieee80211_wep_encrypt

[Johannes Berg]

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