CVE-2025-39863
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-19

Last updated on: 2026-03-25

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() β€” such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-19
Last Modified
2026-03-25
Generated
2026-05-07
AI Q&A
2025-09-19
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 7 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 3.10 (inc) to 6.6.105 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.46 (exc)
linux linux_kernel From 6.13 (inc) to 6.16.6 (exc)
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
linux linux_kernel 6.17
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-416 The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a use-after-free bug in the Linux kernel's brcmfmac wifi driver related to Bluetooth coexistence (btcoex) timer handling. A race condition occurs because the timer shutdown logic only runs if a flag (timer_on) is false, but the timer handler sets this flag to false while rescheduling work. This can cause the work to be scheduled after the associated memory has been freed, leading to use-after-free errors in two scenarios: either the memory is freed before the worker is scheduled, or it is freed after scheduling but before or during the worker's execution. The fix involves always calling timer_shutdown_sync() to reliably deactivate the timer and prevent these race conditions.


How can this vulnerability impact me? :

This vulnerability can lead to use-after-free conditions in the kernel, which may cause system instability, crashes, or potentially allow an attacker to execute arbitrary code with kernel privileges. Such issues can compromise system security and reliability, especially on systems using the affected wifi driver.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where the brcmf_btcoex driver has been fixed to call timer_shutdown_sync() directly without conditional checks. This change resolves the race condition causing the use-after-free bug. Until then, avoid using affected brcmfmac Bluetooth coexistence features or disable the brcmf_btcoex driver if possible.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart