CVE-2026-98761: usb: typec: tcpm: recover after failure to start the frs ams
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: tcpm: recover after failure to start the frs ams
Reset the port if the tcpm fails to start the FASTROLESWAP AMS by initiating error recovery on it.
This helps in cases where some cables (incorrectly) signal an FRS to an FRS capable port during disconnection. The TCPC autonomously starts sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is left on when the FASTROLESWAP AMS fails to start (as tcpmsinktxok is 0 as CC is open due to the cable disconnect). This is because the code sets the state to INVALIDSTATE without resetting the port state.
Log snippet before changes: [ 101.401960] AMS FASTROLESWAP start [ 101.401971] Sink TX No Go [ 101.401982] sourcing vbus [ 101.401987] VBUS on [ 101.402159] VBUS on [ 109.257809] CC1: 0 -> 0, CC2: 5 -> 0 [state SNKREADY, polarity 1, disconnected] [ 111.267442] VBUS on
After changes: [ 70.541211] AMS FASTROLESWAP start [ 70.541220] Sink TX No Go [ 70.541228] state change SNKREADY -> ERRORRECOVERY [rev3 NONEAMS] [ 70.541362] VBUS on [ 70.541365] sourcing vbus [ 70.541367] VBUS on [ 70.541374] state change ERRORRECOVERY -> PORTRESET [rev3 NONEAMS] [ 70.541410] disable vbus discharge ret:0 [ 70.543028] Setting usbcomm capable false [ 70.544009] Setting voltage/current limit 0 mV 0 mA [ 70.544034] polarity 0 [ 70.544239] Requesting mux state 0, usb-role 0, orientation 0 [ 70.555550] cc:=0 [ 70.555595] pending state change PORTRESET -> PORTRESETWAITOFF @ 100 ms [rev3 NONEAMS] [ 70.555697] VBUS off [ 70.555702] VBUS VSAFE0V [ 70.555762] CC1: 5 -> 0, CC2: 0 -> 0 [state PORTRESET, polarity 0, disconnected] [ 70.587794] VBUS off [ 70.587799] VBUS VSAFE0V [ 70.655672] state change PORTRESET -> PORTRESETWAITOFF [delayed 100 ms] [ 70.655682] state change PORTRESETWAITOFF -> SNKUNATTACHED [rev3 NONEAMS] [ 70.655686] Start toggling [ 70.656274] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected]
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Compensating control
Reset the USB Type-C port by initiating error recovery when the TCPM fails to start the FAST_ROLE_SWAP AMS, preventing VBUS from remaining sourced after the failure.
Event History
Frequently Asked Questions
Which systems are exposed to this condition?
Systems using the Linux kernel TCPM Type-C implementation with an FRS-capable port are affected when a cable incorrectly signals Fast Role Swap during disconnection. The described failure occurs when CC is open after disconnect and TCPM cannot start the FAST_ROLE_SWAP AMS.
What is the practical impact if the failure occurs?
The TCPC can autonomously begin sourcing VBUS after detecting the FRS signal, but the port state is left invalid when the AMS fails to start. As a result, VBUS sourcing can remain enabled after the cable has disconnected.
How can administrators identify the condition in logs?
Affected behavior may show "AMS FAST_ROLE_SWAP start", followed by "Sink TX No Go" and VBUS sourcing messages, then a disconnected state while VBUS remains on. The corrected behavior transitions from SNK_READY to ERROR_RECOVERY and then performs a port reset.
What does the fix change?
The fix initiates error recovery and resets the port when TCPM fails to start the FAST_ROLE_SWAP AMS. This clears the port state instead of leaving it in INVALID_STATE with VBUS sourcing enabled.