In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: fix use-after-free in rtw89coretxkickoffandwait()
There is a bug observed when rtw89coretxkickoffandwait() tries to access already freed skbdata:
BUG: KFENCE: use-after-free write in rtw89coretxkickoffandwait drivers/net/wireless/realtek/rtw89/core.c:1110
CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: eventsunbound cfg80211wiphywork [cfg80211]
Use-after-free write at 0x0000000020309d9d (in kfence-#251): rtw89coretxkickoffandwait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89corescancomplete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89hwscancompletecb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89chanctxproceedcb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89chanctxproceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89hwscancomplete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89macc2hscanofldrsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89fwc2hwork drivers/net/wireless/realtek/rtw89/fw.c:6758 processonework kernel/workqueue.c:3241 workerthread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 retfromfork arch/x86/kernel/process.c:154 retfromforkasm arch/x86/entry/entry64.S:258
kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuffheadcache
allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago): allocskb net/core/skbuff.c:659 netdevallocskb net/core/skbuff.c:734 ieee80211nullfuncget net/mac80211/tx.c:5844 rtw89coresendnullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89corescancomplete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89hwscancompletecb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89chanctxproceedcb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89chanctxproceed drivers/net/wireless/realtek/rtw89/chan.c:3194 rtw89hwscancomplete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89macc2hscanofldrsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89fwc2hwork drivers/net/wireless/realtek/rtw89/fw.c:6758 processonework kernel/workqueue.c:3241 workerthread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 retfromfork arch/x86/kernel/process.c:154 retfromforkasm arch/x86/entry/entry64.S:258
freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago): ieee80211txstatusskb net/mac80211/status.c:1117 rtw89pcireleasetxwdskb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89pcireleasetxskbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89pcireleasetx drivers/net/wireless/realtek/rtw89/pci.c:676 rtw89pcinapipoll drivers/net/wireless/realtek/rtw89/pci.c:4238 napipoll net/core/dev.c:7495 netrxaction net/core/dev.c:7557 net/core/dev.c:7684 handlesoftirqs kernel/softirq.c:580 dosoftirq.part.0 kernel/softirq.c:480 localbhenableip kernel/softirq.c:407 rtw89pciinterruptthreadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irqthreadfn kernel/irq/manage.c:1133 irqthread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 retfromfork arch/x86/kernel/process.c:154 retfromforkasm arch/x86/entry/entry64.S:258
It is a consequence of a race between the waiting and the signaling side of the completion:
Waiting thread Completing thread
rtw89coretxkickoffandwait() rcuassignpointer(skbdata->wait, wait) / start waiting / waitforcompletiontimeout() rtw89pcitxstatus() rtw89coretxwaitcomplete() rcureadlock() / signals completion and ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: fix potential zero beacon interval in beacon tracking
During fuzz testing, it was discovered that bssconf->beaconint might be zero, which could result in a division by zero error in subsequent calculations. Set a default value of 100 TU if the interval is zero to ensure stability.