Cloudanix VulnDB

CVE-2026-98196

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in certain Linux Wi-Fi drivers could let a freed memory area be used again, risking crashes or instability on wireless networks.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in brcmsmac timer handling where brcms_free_timer() frees the timer structure via kfree after a non-blocking cancel_delayed_work() while the _brcms_timer callback may still be executing and dereferencing the structure through container_of().

Why it matters to the business

Wireless networking on affected Linux systems can trigger kernel instability or crashes during routine timer operations, causing loss of Wi-Fi connectivity and requiring reboots that disrupt operations.

How an attack unfolds

An attacker with local access or the ability to influence Wi-Fi driver activity triggers repeated timer allocation and free paths in brcmsmac; by racing the delayed work callback against brcms_free_timer(), the freed structure is accessed after release, leading to a kernel use-after-free that can be leveraged for denial of service or memory corruption.

How to fix it

Apply the upstream fix that adds cancel_delayed_work_sync() after brcms_del_timer() in brcms_free_timer(); upgrade to a Linux kernel containing the resolution once released.

How to confirm the fix worked

Inspect the brcmsmac timer code for the presence of cancel_delayed_work_sync() following brcms_del_timer(); verify kernel builds or running version include the corrected brcms_free_timer() implementation.

Typical attack path

  1. Obtain local execution or Wi-Fi control on target system
  2. Induce repeated brcmsmac timer creation and deletion sequences
  3. Race the work callback against the non-synchronous cancel path
  4. Access the freed timer object inside _brcms_timer via container_of()
  5. Trigger kernel panic or memory corruption for impact

How to detect it

Review kernel logs for oops or panic messages referencing brcms_free_timer, _brcms_timer, or container_of on brcmsmac devices; correlate with wireless interface activity around the time of the crash.

  • brcms_free_timer
  • _brcms_timer
  • brcms_del_timer
  • cancel_delayed_work

What your security team should do

  • Monitor kernel updates for the brcmsmac UAF fix and schedule deployment
  • Restrict local access and Wi-Fi driver exposure on high-value systems until patched
  • Enable kernel hardening features such as KASAN or hardened allocators where available

The record

In the Linux kernel, the following vulnerability has been resolved: wifi: brcmsmac: fix UAF in brcms_free_timer() brcms_free_timer() calls brcms_del_timer() which uses the non-synchronous cancel_delayed_work() to cancel the timer's underlying delayed work. If the work callback (_brcms_timer) is already running, cancel_delayed_work() returns false without waiting, and brcms_free_timer() proceeds to kfree(t) while the callback still accesses t through container_of(). Add an explicit cancel_delayed_work_sync() after brcms_del_timer() to guarantee that any in-flight callback has completed before the timer structure is freed.

Affected packages

Ecosystem Package Introduced Fixed