CVE-2026-63958

What it actually does

This is an improper input validation flaw in the Linux kernel USB Type-C UCSI driver. A connector number delivered in a UCSI Connector Change Indicator notification is trusted before being checked against the number of connectors reported during initialization. If firmware or an attached UCSI controller reports connector number 0 or a connector number greater than the initialized connector count, the kernel can index past the end of the ucsi->connector[] array and call schedule_work() on unintended memory. The most likely outcomes are kernel memory corruption, system instability, or denial of service; depending on memory layout and exploitability on a specific platform, privilege escalation or controlled kernel execution may be theoretically possible but is not currently evidenced by public exploitation.

Why it matters to the business

Affected systems can become unstable or crash if they receive malformed UCSI notifications from buggy, compromised, or malicious USB-C controller firmware or related embedded-controller paths. The operational risk is highest for laptops, embedded systems, appliances, kiosks, and servers that expose USB-C/Type-C functionality through UCSI-capable firmware or I2C-attached controllers. Public exploit maturity is currently reported as none, EPSS is low at 0.00206, and the issue is not in the CISA KEV catalog, so this should be treated as a kernel hardening and stability update rather than an active mass-exploitation emergency.

How an attack unfolds

An attacker would need a path to influence the UCSI Platform Policy Manager or a UCSI transport/controller, such as compromised embedded-controller firmware, malicious peripheral/controller behavior on affected transports, supply-chain modification, or another prior compromise that can cause malformed UCSI notifications. The attacker causes the PPM or UCSI controller to emit a connector-change notification containing an invalid 7-bit connector number. The vulnerable kernel driver accepts that value and uses it to index the connector array without validating it against the actual connector count. The driver then schedules work using memory outside the valid connector array. In practical terms, this can crash the kernel or corrupt memory; reliable code execution would require platform-specific heap/layout control and is not known to be publicly available.

How to fix it

Apply a Linux kernel update that includes the fix for validating connector numbers in ucsi_connector_change(), specifically rejecting connector number 0 and connector numbers greater than cap.num_connectors before dereferencing the connector array. If a distribution kernel is used, install the vendor-provided kernel security update rather than attempting to cherry-pick upstream code. Reboot into the fixed kernel after installation. Where immediate patching is not possible, reduce exposure by disabling unused USB-C/UCSI functionality in firmware settings where feasible, restricting physical access to USB-C ports, preventing untrusted firmware or embedded-controller updates, and monitoring for kernel instability related to UCSI or Type-C subsystems.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix by checking the installed kernel package changelog/advisory for the UCSI connector-number validation patch and verifying the system has rebooted into that kernel. On source-built kernels, confirm the UCSI connector change path rejects connector numbers equal to 0 or greater than the reported connector count before accessing ucsi->connector[]. Validate exposure by checking whether the system loads UCSI/Type-C drivers such as ucsi_acpi, typec_ucsi, ucsi_ccg, ucsi_stm32g0, or related platform transports. Review dmesg and journal logs after patching for absence of recurring UCSI, Type-C, workqueue, kernel oops, general protection fault, KASAN, or panic messages during USB-C connect/disconnect events.

Typical attack path

1. Gain the ability to influence UCSI notifications through compromised firmware, a malicious UCSI-capable controller, a vulnerable embedded-controller update path, or another privileged/hardware-adjacent foothold.
2. Trigger or emulate a UCSI Connector Change Indicator notification.
3. Set the connector number field to 0 or to a value greater than the number of connectors reported by the PPM at initialization.
4. Cause the Linux kernel UCSI driver to index outside the ucsi->connector[] array.
5. Leverage the resulting invalid schedule_work() operation to crash the host or attempt platform-specific kernel memory corruption exploitation.

How to detect it

Look for signs of prior exploitation or triggering in kernel and system logs rather than network logs, because exploitation is firmware/controller or hardware-adjacent and is not expected to leave conventional remote-access indicators. Review journalctl, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, pstore, kdump/vmcore data, and endpoint telemetry for UCSI, USB Type-C, workqueue, kernel oops, KASAN, general protection fault, NULL pointer dereference, slab out-of-bounds, or panic events. Pay particular attention to events occurring around USB-C cable insertion/removal, dock connection, power-delivery negotiation, firmware updates, suspend/resume, or embedded-controller anomalies. If crash dumps are available, inspect call traces for ucsi_connector_change, typec_ucsi, ucsi_acpi, ucsi_ccg, ucsi_stm32g0, glink UCSI paths, or schedule_work near the fault. Because there are no public exploitation reports or stable IOCs, detection should focus on behavioral evidence of malformed UCSI notifications and kernel memory faults rather than fixed attacker artifacts.

• ucsi_connector_change
• typec_ucsi
• ucsi_acpi
• ucsi_ccg
• ucsi_stm32g0
• UCSI
• usb: typec: ucsi
• schedule_work
• kernel BUG
• kernel panic
• Oops:
• general protection fault
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• BUG: unable to handle kernel paging request
• workqueue
• /var/log/kern.log
• /var/log/messages
• /sys/fs/pstore
• /proc/vmcore

What your security team should do

• Prioritize patching Linux endpoints and appliances with USB-C/UCSI support, especially laptops, embedded devices, kiosks, and systems exposed to untrusted peripherals or firmware-update paths.
• Roll out vendor kernel updates and ensure systems are rebooted into the fixed kernel; kernel package installation alone is not sufficient.
• Inventory systems loading UCSI-related modules such as typec_ucsi, ucsi_acpi, ucsi_ccg, ucsi_stm32g0, or platform-specific UCSI transports.
• For systems that cannot be patched quickly, restrict physical access to USB-C ports and disable unused USB-C/Type-C controller functionality where operationally acceptable.
• Treat unexpected kernel crashes, workqueue faults, or UCSI/Type-C errors following USB-C activity as suspicious and preserve logs for investigation.
• Monitor vendor advisories for distribution-specific fixed kernel versions because no exact fixed package versions were provided in the input.
• Do not assign emergency internet-exploitation priority solely based on this issue: it is not KEV-listed, has low EPSS, and has no reported public exploit maturity, but it still warrants normal kernel security patch SLAs.