CVE-2025-39863: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work

In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmfmac: fix use-after-free when rescheduling brcmfbtcoexinfo work

The brcmfbtcoexdetach() only shuts down the btcoex timer, if the flag timeron is false. However, the brcmfbtcoextimerfunc(), which runs as timer handler, sets timeron to false. This creates critical race conditions:

1.If brcmfbtcoexdetach() is called while brcmfbtcoextimerfunc() is executing, it may observe timeron as false and skip the call to timershutdownsync().

2.The brcmfbtcoextimerfunc() may then reschedule the brcmfbtcoexinfo worker after the cancelworksync() 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 brcmfbtcoexinfo struct is freed relative to the execution of its worker thread.

Scenario 1: Freed before the worker is scheduled

The brcmfbtcoexinfo is deallocated before the worker is scheduled. A race condition can occur when schedulework(&btlocal->work) is called after the target memory has been freed. The sequence of events is detailed below:

CPU0 | CPU1 brcmfbtcoexdetach | brcmfbtcoextimerfunc | btlocal->timeron = false; if (cfg->btcoex->timeron) | ... | cancelworksync(); | ... | kfree(cfg->btcoex); // FREE | | schedulework(&btlocal->work); // USE

Scenario 2: Freed after the worker is scheduled

The brcmfbtcoexinfo is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmfbtcoexhandler() — such as the containerof macro and subsequent dereferences of the brcmfbtcoexinfo object will cause a use-after-free access. The following timeline illustrates this scenario:

CPU0 | CPU1 brcmfbtcoexdetach | brcmfbtcoextimerfunc | btlocal->timeron = false; if (cfg->btcoex->timeron) | ... | cancelworksync(); | ... | schedulework(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmfbtcoexhandler() // Worker / | btci = containerof(....); // 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 timershutdownsync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timeron state is then set to false.