CVE-2026-31729

What it actually does

The flaw is an improper input validation issue in the Linux kernel USB Type-C Connector System Software Interface (UCSI) handling path. A connector number extracted from the Command Completion Indicator is a 7-bit value, but the kernel used it to index an array sized only for the actual number of connectors reported by the device. A malicious, compromised, or faulty UCSI-capable device or controller can provide an out-of-range connector number, causing an out-of-bounds kernel array access in the connector-change handling path. Depending on memory layout and exploitability on a given kernel build, this can result in kernel crash, denial of service, information exposure, or potentially local privilege escalation through kernel memory corruption.

Why it matters to the business

Successful exploitation can affect endpoint, workstation, server, or appliance stability and security by allowing a local attacker or malicious attached hardware to crash the system or potentially gain elevated privileges. The risk is most relevant for systems with accessible USB-C/Type-C, Thunderbolt, docking, or UCSI-managed ports, especially laptops, workstations, kiosks, shared devices, and physically exposed systems. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no public exploit maturity reported, and has a low EPSS score, but the CVSS impact is high because exploitation occurs in kernel context.

How an attack unfolds

An attacker needs local proximity or local influence over UCSI hardware behavior. In a likely scenario, the attacker connects or controls a malicious USB-C, Type-C, docking, Thunderbolt, or UCSI-interacting device that causes the system firmware or UCSI controller to emit a Command Completion Indicator containing a bogus connector number. The kernel receives the notification and parses the connector value. On vulnerable kernels, the value is trusted and passed into connector-change handling, where it is used as an index into a smaller connector array. The resulting out-of-bounds access can corrupt or disclose kernel memory or trigger a kernel fault. A reliability-focused attacker may use this to crash the host; a more capable attacker may attempt to shape memory and turn the bug into privilege escalation.

How to fix it

Apply the Linux kernel update from the operating system or appliance vendor that includes the UCSI connector-number bounds check in ucsi_notify_common(). No exact package fixed versions were provided in the input, so use the latest vendor-supported kernel for the affected distribution or product line and verify that the vendor advisory references this fix. Where immediate patching is not possible, reduce exposure by restricting physical access to USB-C/Type-C/Thunderbolt ports, disabling unused external ports in firmware/BIOS/UEFI or platform management tools where supported, enforcing trusted peripheral policies, and avoiding untrusted docks, chargers, cables, and USB-C devices. As a temporary operational mitigation on systems where Type-C functionality is not required, consider disabling or blacklisting relevant UCSI drivers such as ucsi_acpi only after testing, because this may affect USB-C, charging, docking, display, and power-delivery behavior.

How to confirm the fix worked

Confirm remediation by checking that the running kernel package is at or above the vendor-fixed release and that the system has been rebooted into the updated kernel. Review the vendor changelog or source package for the UCSI fix that validates connector numbers before calling connector-change handling. On source-based or custom kernels, confirm the UCSI notification path rejects connector numbers greater than the configured connector count before indexing the connector array. Validate exposure by inventorying Linux systems with UCSI/USB Type-C support, checking loaded modules such as ucsi_acpi, typec_ucsi, and related Type-C drivers, and confirming whether external USB-C/Thunderbolt ports are physically accessible. After patching, perform a controlled regression test of USB-C charging, docking, display, and hot-plug behavior to ensure functionality remains intact.

Typical attack path

1. Identify a Linux system with accessible USB-C/Type-C/UCSI-managed ports and a vulnerable kernel.
2. Obtain local access or control a malicious/malfunctioning Type-C, Thunderbolt, docking, or UCSI-interacting device.
3. Cause the device/controller to report a connector number outside the range allocated by the kernel for that system.
4. Trigger a UCSI notification so the kernel processes the malformed Command Completion Indicator.
5. Abuse the resulting out-of-bounds kernel array access to crash the system or attempt kernel memory corruption.
6. If reliable exploitation is achieved, escalate privileges or tamper with kernel state.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs, persistent journal logs, crash dumps, and endpoint telemetry for crashes or warnings in the UCSI and USB Type-C subsystem, especially around USB-C, dock, charger, display, or Thunderbolt connection events. Useful sources include journalctl -k output, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore/ramoops records, kdump/vmcore artifacts, ABRT/apport crash reports, and EDR telemetry for kernel panic or reboot events. Look for kernel oops, general protection faults, KASAN reports, slab out-of-bounds warnings, or panic traces referencing ucsi_notify_common, ucsi_connector_change, typec_ucsi, ucsi_acpi, or UCSI CCI processing. Because exploitation may leave no durable file artifact if it only causes memory corruption or a crash, correlate suspicious logs with physical access records, unexpected peripheral insertions, dock changes, USB/Thunderbolt authorization events, and unexplained reboots. There are no known public campaign-specific indicators or named threat actors for this issue in the provided intelligence.

• ucsi_notify_common
• ucsi_connector_change
• typec_ucsi
• ucsi_acpi
• UCSI_CCI_CONNECTOR
• UCSI
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• KASAN: out-of-bounds
• UBSAN: array-index-out-of-bounds
• /sys/class/typec
• /sys/kernel/debug/usb/ucsi
• /var/crash
• /sys/fs/pstore
• pstore:
• ramoops:

What your security team should do

• Prioritize patching laptops, workstations, kiosks, shared systems, physically exposed Linux devices, and any servers or appliances with accessible USB-C/Type-C/Thunderbolt ports.
• Inventory affected Linux kernel deployments and identify systems with UCSI support or loaded Type-C/UCSI kernel modules.
• Apply vendor kernel updates and reboot; do not rely on package installation alone if the old kernel remains running.
• Where patching is delayed, restrict physical access to external ports and prohibit untrusted USB-C docks, chargers, cables, and peripherals.
• Monitor for kernel crashes, oops reports, and UCSI/Type-C errors around device attach or detach events.
• Review endpoint and asset-management controls for removable-device policy enforcement, especially on high-risk endpoints.
• Treat unexplained kernel crashes following USB-C, dock, or Thunderbolt activity as potentially security-relevant until investigated.