Linux Kernel EUVD-2026-86228

Exploitation requires the fsl-imx8mq-usb PHY driver to reach probe, have imx95_usb_phy_get_tca() succeed, and then fail later in probe - so the affected system must be NXP i.MX8MQ/i.MX95 hardware with the Type-C switch (TCA) path active. It is local-only and depends on an attacker being able to induce repeated probe failures (e.g., via privileged device bind/unbind or hardware/device-tree manipulation), which is not an unauthenticated or default-remote condition; a single probe failure produces only a one-time leak of limited impact.

This is a low real-world-risk issue despite the inflated 7.4 CVSS score. The published vector CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H claims full confidentiality, integrity, and availability compromise, but the underlying defect is a reference/resource leak of a Type-C switch object on the driver probe error path in the fsl-imx8mq-usb PHY driver - cleanup previously existed only in .remove(), which never runs when probe fails. A leaked kernel object on a rare error path does not plausibly yield C:H/I:H/A:H; at most it is a minor, hard-to-trigger resource leak (availability), so the C:H/I:H/A:H rating appears to be an automated over-scoring of a Linux stable-tree fix. AV:L and AC:H are consistent with the fact that exploitation requires local control that repeatedly forces probe failure on affected NXP i.MX hardware. There is no EPSS score, no KEV listing, and no POC provided; combined with the requirement for a specific i.MX SoC and a probe failure condition, this is a code-hygiene/robustness fix rather than an exploitable security priority. Note the PR:N is questionable: driver probe is a boot/privileged operation, not something an unauthenticated remote actor drives - verify auth assumptions before trusting the network-implied portions of any derived scoring.

An attacker with local, privileged control over device binding or hardware/device-tree state on an NXP i.MX8MQ/i.MX95 board repeatedly triggers the USB PHY driver to probe and fail after imx95_usb_phy_get_tca() succeeds, leaking a Type-C switch reference each time. Over many iterations this could slowly exhaust kernel resources, but no chosen-content disclosure or code execution results. No public exploit code is identified at time of analysis.