Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-06T09:18:21.660Z",
  "pubdate": "2026-10-06T09:18:21.660Z",
  "executiveSummary": "This vulnerability involves a race condition and potential use-after-free (UAF) flaw within the mxl862xx DSA driver in the Linux kernel.\nThe issue stems from improper synchronization of the statistics polling mechanism during the device setup and teardown phases.\nIf dsa_tree_setup() fails or during driver teardown, the statistics poll work can remain active or be re-armed after relevant data structures have been freed, leading to kernel memory corruption or system instability.\nAn attacker capable of triggering driver probe failures or manipulating device lifecycle events could potentially leverage this race condition to cause a kernel panic (Denial of Service).\nThe vulnerability affects systems utilizing the mxl862xx DSA switch chip and requires local access to trigger the driver initialization or removal sequences.",
  "technicalDetails": "The vulnerability originates in mxl862xx_setup(), which incorrectly arms the statistics polling mechanism before the completion of the MDIO bus setup and the subsequent dsa_register_switch() call. Because the polling mechanism is not safely gated, failure paths within dsa_tree_setup() leave the work queue active while the underlying dsa_port list structures are deallocated by the DSA core.\nThe primary root cause is an atomicity failure between the WORK_STOPPED flag and the polling re-arm logic. In mxl862xx_get_stats64(), the flag check is performed non-atomically relative to the cancellation performed in mxl862xx_shutdown(). This allows for a race condition where the work is re-queued after cancel_delayed_work_sync() has already returned, effectively reviving the polling thread after the driver has initiated shutdown sequences.\nExploitation occurs when the driver lifecycle transitions from a failed state or a shutdown command. In the failure path of mxl862xx_probe(), if dsa_register_switch() returns an error, the DSA subsystem releases internal structures. If the poll function (crc_err_work) triggers after this deallocation, it attempts to iterate over the freed dsa_port list, resulting in a use-after-free scenario. The lack of robust serialization between the work-cancellation and the state-flag management allows the work to persist even after the driver resources are intended to be quiescent.\nThe impact includes kernel memory corruption and potential arbitrary code execution paths, though the primary observed result is a kernel panic due to invalid memory access. The attack flow requires an actor to repeatedly trigger the initialization/teardown sequence of the mxl862xx hardware, potentially via modular driver loading/unloading or hardware hot-plug events, to widen the race condition window. The vulnerability is local and requires administrative or privileged access to influence kernel module behavior, specifically targeting the interaction between the network subsystem and the DSA switch driver logic."
}