Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - wifibrcmfmac修复了重新计划 brcmf_btcoex_info 工作时的释放后使用如果 flag timer_on 为 false则 brcmf_btcoex_detach() 仅会关闭 btcoex 定时器。但是作为 timer 处理程序运行的 brcmf_btcoex_timerfunc() 将 timer_on 设置为 false。这样会造成严重的争用条件1.如果在执行 brcmf_btcoex_timerfunc() 时调用 brcmf_btcoex_detach()则可能发现 timer_on 为 false并跳过 timer_shutdown_sync() 的调用。 2.然后brcmf_btcoex_timerfunc() 可能会在执行 cancel_work_sync() 之后重新计划 brcmf_btcoex_info 工作线程从而导致释放后使用缺陷。
    释放后使用缺陷在两种不同的情况下会发生具体取决于相对于其工作线程执行的 brcmf_btcoex_info struct 释放时间。场景 1：在计划工作线程之前已释放 brcmf_btcoex_info 在计划工作线程之前已释放。在释放目标内存之后调用 schedule_work(&bt_local->work) 时可能发生争用条件。
    事件序列的详细信息如下brcmf_btcoex_detach | CPU1 | brcmf_btcoex_timerfunc | bt_local->timer_on = false if (cfg->btcoex->timer_on) | if (cfg->btcoex->timer_on) ... cancel_work_sync(); | ... kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE 场景 2在计划工作线程之后释放 brcmf_btcoex_info 在计划工作线程之后、其执行之前或执行期间释放。在这种情况下brcmf_btcoex_handler() 内的语句如 container_of 宏和 brcmf_btcoex_info 对象的后续取消引用将造成释放后使用访问。以下时间线说明了此情况brcmf_btcoex_detach | CPU1 | brcmf_btcoex_timerfunc | bt_local->timer_on = false if (cfg->btcoex->timer_on) | if (cfg->btcoex->timer_on) ... cancel_work_sync(); | ... schedule_work(); // 重新安排 | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // 工作线程 /* | btci = container_of(....); | // 使用上述 kfree() 可以 | ... 也可以在任何时候发生 | btci-> // 在线程执行期间使用| */若要解决争用条件请终止条件检查并直接调用 timer_shutdown_sync()。它可以可靠地停用 定时器而无论其当前状态如何。
    停止后timer_on 状态将设置为 false。 (CVE-2025-39863)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2025-39863

high Nessus 插件 ID 265463

版本 1.15