On Fri, 2025-07-18 at 07:50 -0700, Eric Biggers wrote:

quoted

BUG: unable to handle page fault for address: ffff8880bfffd000

[...]

quoted

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

[...]

quoted

 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