[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+d1008c...@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 syzk...@googlegroups.com.

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

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

If you want 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

[Eric Biggers]

[+linux-wireless and Johannes for ieee80211_wep_encrypt]

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

[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

[Johannes Berg]

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

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.