Description

In the Linux kernel, the following vulnerability has been resolved: phy: fsl-imx8mq-usb: fix typec switch leak on probe error path If probe fails after imx95_usb_phy_get_tca() succeeds, the typec switch leaks because the only cleanup path was in .remove(), which never runs on probe failure. Use devm_add_action_or_reset() so the switch is cleaned up on both probe failure and driver removal. The imx95_usb_phy_put_tca() is no longer needed, it will be removed in .remove() too.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-09-24T16:17:17.857Z",
  "pubdate": "2026-09-24T16:17:17.857Z",
  "executiveSummary": "This vulnerability is a resource management defect within the fsl-imx8mq-usb PHY driver in the Linux kernel.\nThe flaw manifests as a memory/handle leak during the driver probe phase when initialization fails after acquiring a Type-C switch handle via imx95_usb_phy_get_tca().\nBecause the cleanup logic for the Type-C switch was implemented solely within the .remove() callback, an error during probe prevents the resource from being released, leading to a kernel-level resource leak.\nWhile this is primarily a stability issue leading to resource exhaustion, it could potentially be leveraged in a denial-of-service (DoS) scenario if an attacker can repeatedly trigger failed driver probes.\nThe vulnerability affects systems utilizing the imx8mq/imx95 USB PHY infrastructure. Exploitation typically requires local access to trigger hardware probe sequences or device binding/unbinding operations.",
  "technicalDetails": "The root cause of this vulnerability is an imbalance in resource lifecycle management within the fsl-imx8mq-usb driver. During the driver probe process, the kernel invokes imx95_usb_phy_get_tca() to acquire a handle for the Type-C switch. If any subsequent operation in the probe sequence fails, the function exits early without releasing this handle.\nPreviously, the release mechanism was exclusively gated by the driver's .remove() function. In the Linux kernel driver model, if probe() returns an error, the .remove() callback is never invoked for that specific device instance. Consequently, the Type-C switch handle remains leaked in kernel memory until the next system reboot.\nThe attack flow for triggering this leak involves interacting with the Linux sysfs interface to trigger driver re-probing or by manipulating device tree properties to force a failure state during the device binding process. By repeatedly failing the probe after the Type-C switch allocation, an attacker may exhaust limited system resources associated with the PHY controller.\nThe resolution involves replacing manual cleanup with the devm_add_action_or_reset() framework. By registering a managed cleanup action immediately after the successful execution of imx95_usb_phy_get_tca(), the kernel ensures that the resource is automatically released if the probe fails, thereby centralizing resource management. This refactoring also renders the explicit imx95_usb_phy_put_tca() call within the remove() function unnecessary, as the devres framework manages the lifecycle automatically regardless of how the driver teardown occurs.\nThis defect is classified as a failure to release a resource, impacting the internal state of the kernel's device management subsystem. While this does not provide direct code execution, persistent leaks in critical kernel subsystems can lead to kernel instability or system hangs, particularly in embedded environments where device hotplugging or complex power management transitions are frequent."
}