wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.15.210, 6.1.167, 6.6.105, 6.12.46, 6.16.6
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
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.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From 61730d4dfffc2cc9d3a49fad87633008105c18ba · fixed in c75600e69e66a751cc046cd9c407b942f298d852; From 61730d4dfffc2cc9d3a49fad87633008105c18ba · fixed in ae58f70bde0433f27ef4b388ab50634736607bf6; From 61730d4dfffc2cc9d3a49fad87633008105c18ba · fixed in f1150153c4e5940fe49ab51136343c5b4fe49d63; From 61730d4dfffc2cc9d3a49fad87633008105c18ba · fixed in 3e789f8475f6c857c88de5c5bf4b24b11a477dd7; From 61730d4dfffc2cc9d3a49fad87633008105c18ba · fixed in 2f6fbc8e04ca1d1d5c560be694199f847229c625; From 61730d4dfffc2cc9d3a49fad87633008105c18ba · fixed in 9cb83d4be0b9b697eae93d321e0da999f9cdfcfc
- Linux Linux
3.10
- KernelLinux
From 3.10.0 · fixed in 5.15.210; From 5.16.0 · fixed in 6.1.167; From 6.2.0 · fixed in 6.6.105; From 6.7.0 · fixed in 6.12.46; From 6.13.0 · fixed in 6.16.6