Created attachment 271605 [details] kgdb backtrace kernel panic occurs occasionally during reassociation with AP or when resetting the wlan interface. Most likely it is a race condition, when deassociating with the AP a structure is zeroed and then another kernel thread calls transmit callback, and that accesses zeroed, and possibly freed memory, where is an intrusive linked list (using linux/list.h), and because the memory is zeroed, the list is corrupt, and then it tries to access data at address 0xfffffffffffffff8. Should be easy to reproduce, it occurs after either wpa_cli reassociate or service netif restart wlan0. Affects the rtw89 driver, and likely also rtw88 and maybe iwlwifi. uname -a FreeBSD ntbhorak2 15.1-STABLE FreeBSD 15.1-STABLE #4 stable/15-n283828-70f682385515-dirty: Wed Jun 3 12:42:26 CEST 2026 root@ntbhorak2:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 possible cause is function lkpi_lsta_remove in sys/compat/linuxkpi/common/src/linux_80211.c:826, the sta structure is probably destroyed without stopping tx and flushing queues, and the function rtw89_core_tx_write gets zeroed structure, and there, list_first_entry() is used, and if the pointers are zeroed, it returns an invalid pointer, which the function then tries to access, and there it breaks. the list_first_entry() is not used directly, but in macro rtw89_get_designated_link()
This is not a race condition in LinuxKPI; this is net80211 creating/using a new ni (sta) for a next packet without tearing down the previous sta properly or letting us setup the new one. iwlwifi seems to be able to deal with this at the current stage but rtw8x and mt76 go kaboom. I believe there's at least another two PRs open related to this (or maybe it's just in my head as I've seen it) and the release notes for 15.1 indicate problems with certain rtw8x chipsets. I can think of a possible work around in LinuxKPI 802.11 but after all the years I got tired of implementing workarounds and the real fix is to get net80211 right now but that does not happen over night.