CVE-2026-98761
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A software problem in handling certain USB cable removals can leave power unexpectedly active on the port, which may interfere with normal device connections until the system is restarted or updated.
- Exploitation
- Other
- Attacker needs
- Other
- Complexity
- Theoretical
- Impact
- Other
- Component
- OS kernel
- Class
- Other
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Failure to start the FAST_ROLE_SWAP AMS leaves VBUS sourcing active without port reset because the state machine transitions to INVALID_STATE instead of initiating error recovery.
Why it matters to the business
USB Type-C ports on affected Linux systems may exhibit unexpected power delivery behavior after certain cable disconnections, potentially disrupting peripheral operation and requiring manual intervention or reboots in production environments.
How an attack unfolds
An attacker or faulty cable signals an FRS event during disconnection to an FRS-capable port; the TCPC begins sourcing VBUS but the subsequent AMS failure (due to open CC) leaves power enabled because no port reset occurs.
How to fix it
Update the Linux kernel TCPM driver to the version containing the error-recovery reset on AMS start failure; apply the fix that changes state to ERROR_RECOVERY and performs PORT_RESET on FAST_ROLE_SWAP failure.
How to confirm the fix worked
Confirm kernel logs show the sequence state change SNK_READY to ERROR_RECOVERY followed by PORT_RESET and VBUS off after an FRS attempt; verify the patch is present by inspecting tcpm.c for the error-recovery path.
Typical attack path
- Attach a cable that incorrectly asserts an FRS signal on disconnect
- Trigger the FAST_ROLE_SWAP AMS start in the TCPM state machine
- Observe Sink TX No Go condition leaving CC open
- Leave VBUS sourcing active without ERROR_RECOVERY transition
How to detect it
Review kernel logs for repeated AMS FAST_ROLE_SWAP start followed by Sink TX No Go and sustained VBUS on messages without subsequent ERROR_RECOVERY or PORT_RESET transitions; correlate with dmesg timestamps around cable disconnect events.
What your security team should do
- Prioritize kernel updates on systems exposing USB Type-C ports within the next maintenance window
- Monitor vendor advisories for backported fixes in LTS kernels
- Test USB-C peripheral behavior after applying the update in staging environments
The record
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 FAST_ROLE_SWAP 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 FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok is 0 as CC is open due to the cable disconnect). This is because the code sets the state to INVALID_STATE without resetting the port state. Log snippet before changes: [ 101.401960] AMS FAST_ROLE_SWAP 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 SNK_READY, polarity 1, disconnected] [ 111.267442] VBUS on After changes: [ 70.541211] AMS FAST_ROLE_SWAP start [ 70.541220] Sink TX No Go [ 70.541228] state change SNK_READY -> ERROR_RECOVERY [rev3 NONE_AMS] [ 70.541362] VBUS on [ 70.541365] sourcing vbus [ 70.541367] VBUS on [ 70.541374] state change ERROR_RECOVERY -> PORT_RESET [rev3 NONE_AMS] [ 70.541410] disable vbus discharge ret:0 [ 70.543028] Setting usb_comm 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 PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev3 NONE_AMS] [ 70.555697] VBUS off [ 70.555702] VBUS VSAFE0V [ 70.555762] CC1: 5 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0, disconnected] [ 70.587794] VBUS off [ 70.587799] VBUS VSAFE0V [ 70.655672] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [ 70.655682] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [rev3 NONE_AMS] [ 70.655686] Start toggling [ 70.656274] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected]
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|