CVE-2026-98192: wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown
In the Linux kernel, the following vulnerability has been resolved:
wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown
wcn36xxdxedeinit() tears down the TX ack timer with timerdelete(), which only dequeues the timer and does not wait for a callback that is already executing; the preceding freeirq() calls synchronize the interrupt handlers only. The callback, wcn36xxdxetxtimer(), can therefore be running past the teardown and use the wcn freed along with the ieee80211hw in wcn36xxremove(): it takes wcn->dxelock, reads wcn->txackskb and passes wcn->hw to ieee80211txstatusirqsafe().
Fix this by using timershutdownsync(), which waits for a running callback and also prevents the timer from being rearmed again. The timer is set up again by wcn36xxdxeinit() on the next start, so the start/stop cycle is unaffected.
This issue was found by an in-house static analysis tool.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.8-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.112 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.54 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.8 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In wcn36xx_dxe_deinit(), replace timer_delete() with timer_shutdown_sync() for the TX ack timer so teardown waits for any running callback and prevents the timer from being rearmed.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's wcn36xx Wi-Fi driver are relevant. The race occurs during driver teardown or device removal, when the TX acknowledgment timer callback may still be executing after associated driver state has been freed.
What condition is required for the use-after-free to occur?
The TX acknowledgment timer callback must already be running while wcn36xx teardown proceeds. The prior teardown used timer_delete(), which removes a queued timer but does not wait for an in-progress callback to finish.
What is the mitigation if an updated kernel cannot be deployed immediately?
The provided information identifies the exposure as occurring during wcn36xx driver teardown or removal. No specific temporary configuration workaround is provided.
How does the fix prevent the race?
The fix replaces timer_delete() with timer_shutdown_sync(). This waits for a running callback to complete and prevents the timer from being rearmed during teardown; the timer is initialized again on the next driver start.