Correction and additional data from the original reporter.
CRASH COUNT AND SIGNATURE
-------------------------
The report says 8 crashes sharing RIP ieee80211_del_chanctx+0x161/0x170.
That over-counted. Re-examining /var/lib/systemd/pstore, it is 6 distinct
events: the 001/002 subdirectories, and the pairs of dumps one second
apart, are the same panic recorded twice.
More importantly, the crash site is NOT constant. Per event:
Aug 5 09:25:00 ieee80211_del_chanctx, drv_stop, i915_active_add_request
Aug 6 07:08:22 kernel BUG at mm/usercopy.c:102, usercopy_abort, ksize
Aug 7 05:07:46 free_large_kmalloc, ksize, ieee80211_del_chanctx
Aug 9 08:18:00 drv_stop, ieee80211_del_chanctx, ieee80211_reconfig
Aug 11 18:53:21 do_poll.constprop.0, ksize
Aug 12 08:54:21 kernel BUG at mm/slub.c:542, build_detached_freelist,
drv_stop, ieee80211_del_chanctx, ieee80211_reconfig
Only 4 of 6 name mac80211 at all. ksize+0xb4/0x160 appears in 3. The
allocator-side sites (build_detached_freelist, free_large_kmalloc,
usercopy_abort, ksize) and the unrelated consumers (do_poll, i915)
suggest the damage is to the slab rather than to the caller, with the
panic landing wherever the poisoned freelist is next touched. I believe
that makes this a use-after-free or double-free in channel-context
teardown rather than six separate faults, and it is why the backtrace
looked inconsistent. I should have led with that rather than with the
single most common frame.
TRIGGERING IT WITHOUT WAITING FOR A CHANNEL SWITCH
--------------------------------------------------
While disabling the card I ran:
modprobe -r iwldvm
and the host panicked immediately. The pstore record shows:
CPU: 7 UID: 0 PID: 1325140 Comm: modprobe Kdump: loaded
Tainted: G W I 7.0.0-29-generic #29-Ubuntu
[last unloaded: iwldvm]
The EFI records were truncated (most are 13-byte stubs), so there is no
full backtrace for this one. But module removal calls
ieee80211_unregister_hw(), which reaches ieee80211_del_chanctx through
ieee80211_teardown_sdata -> ieee80211_link_stop ->
__ieee80211_link_release_channel -> ieee80211_free_chanctx -- the same
path the CSA-triggered crashes take.
This is a single observation, not a demonstrated reproducer, and the
interface was rfkill-blocked and unassociated at the time. But if it
holds on other hardware it would be far cheaper to test than waiting for
an AP to announce a channel switch.
WHY THIS MIGHT MATTER BEYOND THIS CARD
--------------------------------------
The frames above (ieee80211_del_chanctx, ieee80211_free_chanctx,
ieee80211_link_stop, ieee80211_reconfig, drv_stop) are generic mac80211,
not iwlwifi. The Intel firmware error appears to be the trigger, not the
fault. If the teardown path can race this way generally, hardware still
in production could reach it by another route.
ENVIRONMENT
-----------
ThinkPad W520, Ubuntu 26.04, kernel 7.0.0-29-generic
Intel Centrino Ultimate-N 6300 [8086:4238] rev 3e, subsystem [8086:1111]
iwlwifi + iwldvm, firmware 9.221.4.1 build 25532 (iwlwifi-6000-4.ucode)
STATUS
------
I have blacklisted iwlwifi/iwldvm on this host and moved to a USB
adapter, so it will not generate further data. I am not asking for a
fix -- the hardware is old and I have worked around it. Filing the
correction in case the mac80211-side teardown is relevant to supported
devices. Happy to supply the raw pstore dumps if they are useful.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2163438
Title:
mac80211: repeated crashes in ieee80211_del_chanctx during hw-restart
teardown after a failed CSA (iwldvm / Centrino 6300 AGN)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2163438/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
