[Bug 295928] panic: race condition in kernel in linuxkpi 802.11
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 295928] panic: race condition in kernel in linuxkpi 802.11"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 295928] panic: race condition in kernel in linuxkpi 802.11"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 295928] panic: race condition in kernel in linuxkpi 802.11"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 08 Jun 2026 07:18:08 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295928
Bug ID: 295928
Summary: panic: race condition in kernel in linuxkpi 802.11
Product: Base System
Version: 15.1-STABLE
Hardware: amd64
OS: Any
Status: New
Keywords: crash
Severity: Affects Many People
Priority: ---
Component: wireless
Assignee: wireless@FreeBSD.org
Reporter: jan.edhorak@seznam.cz
Flags: maintainer-feedback+, mfc-stable15?, mfc-stable14?
Created attachment 271605
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=271605&action=edit
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()
--
You are receiving this mail because:
You are the assignee for the bug.