CVE-2026-98305
High · 7.8CVSS
7.8
EPSS
0.1%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A timing problem in certain network hardware drivers can cause computers to crash or become unstable when the driver starts or stops.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition during DSA switch setup and teardown allows a stats polling work item to access ports after they have been freed or after WORK_STOPPED is set, due to non-atomic flag checks and delayed work re-arming.
Why it matters to the business
Systems using affected network hardware may experience crashes, memory corruption, or instability during driver initialization, shutdown, or error recovery, leading to unplanned downtime and potential data loss.
How an attack unfolds
An attacker with local access triggers repeated module load/unload or probe failures on the mxl862xx DSA driver; the stats poll work item fires after ports are freed or shutdown has run, walking invalid memory and causing a kernel panic or corruption.
How to fix it
Update to a Linux kernel containing the fix that arms the stats poll only after successful setup and uses disable_delayed_work_sync() in teardown and shutdown paths. Rebuild and reboot affected systems with the patched kernel.
How to confirm the fix worked
Confirm the presence of the patch that moves poll arming after dsa_register_switch success and adds disable_delayed_work_sync calls; verify no stats poll work items access freed ports by code inspection or by exercising probe error paths and shutdown sequences without crashes.
Typical attack path
- Obtain local access to a system with the vulnerable mxl862xx DSA driver loaded.
- Trigger repeated device probe failures or driver teardown sequences.
- Race the stats poll work item against port list freeing or WORK_STOPPED flag setting.
- Trigger use-after-free or invalid memory access leading to denial of service.
How to detect it
Review kernel logs for oops, warnings, or use-after-free reports involving mxl862xx_get_stats64 or dsa_port structures during module load, probe failure, or shutdown; inspect for unexpected work queue activity around driver teardown.
What your security team should do
- Prioritize kernel updates on all systems exposing the mxl862xx DSA driver.
- Test driver load/unload and error paths in staging environments before production rollout.
- Monitor kernel logs for oops or warnings during network device registration and removal.
The record
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mxl862xx: disable the stats poll on teardown mxl862xx_setup() arms the stats poll before mxl862xx_setup_mdio(), and nothing stops it until dsa_register_switch() has returned an error to mxl862xx_probe(). DSA frees the dsa_port list before it returns, so a poll that fires once .setup or a later step of dsa_tree_setup() has failed walks freed ports. On shutdown the user ports stay registered, and the WORK_STOPPED flag test in mxl862xx_get_stats64() is not atomic with the cancel in mxl862xx_shutdown(), so a re-arm that read the flag before it was set queues the poll after cancel_delayed_work_sync() has returned. Arm the poll once .setup has succeeded and stop it from a .teardown op, which DSA calls on unregister and after a failed registration, in both cases before it frees the ports. Use disable_delayed_work_sync() there and in shutdown(): it drains a running poll as the cancel did and turns every later attempt to queue the work into a no-op, so the re-arm cannot bring the poll back. remove() and the probe error path only set WORK_STOPPED, which crc_err_work tests before it walks the ports.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|