CVE-2026-64329

What it actually does

This is a Linux kernel use-after-free in the USB Type-C UCSI CCG driver remove path. During device removal, the driver previously freed the UCSI object with ucsi_destroy() before disabling the interrupt with free_irq(). If the threaded IRQ handler was already running, a connector-change interrupt could cause ccg_irq_handler() to call ucsi_notify_common() using the freed UCSI pointer. The likely technical outcomes are kernel memory corruption, kernel crash, or undefined behavior in systems using the affected UCSI CCG USB Type-C controller path. Practical exploitation for privilege escalation is not established, and current exploit maturity is listed as none.

Why it matters to the business

Systems with affected Linux kernels and relevant USB Type-C UCSI CCG hardware may experience instability, crashes, or denial of service when the driver is removed while a connector-change interrupt is processed. Because this flaw is not in CISA KEV, is not known to be used in ransomware, has very low EPSS, and currently has no known exploit maturity, broad emergency response is not indicated; however, kernel flaws should still be remediated through normal patch cycles, especially on laptops, workstations, embedded Linux devices, and servers that expose or depend on USB-C/Type-C functionality.

How an attack unfolds

An attacker would need a way to influence the vulnerable driver lifecycle and the timing of USB Type-C connector-change interrupts. In a plausible scenario, the attacker causes or waits for removal, unbinding, shutdown, or hot-removal of the UCSI CCG driver while simultaneously triggering connector state changes. If the interrupt handler is active after the UCSI structure has been freed, the handler dereferences freed kernel memory. The most realistic result is a kernel oops, panic, or system crash. Reliable code execution would require precise kernel heap shaping and race timing and is not currently evidenced by public exploitation or KEV listing.

How to fix it

Apply the Linux kernel fix that moves free_irq() before ucsi_destroy() in the UCSI CCG driver remove path while keeping it after ucsi_unregister(). Because no product-specific fixed versions were provided, use vendor kernel advisories and distribution security updates to identify the first fixed kernel for each platform. For source-based kernels, ensure the relevant patch is present in drivers/usb/typec/ucsi/ucsi_ccg.c. Where immediate patching is not possible, reduce exposure by avoiding unnecessary driver unload/reload operations, limiting local administrative access that can unbind kernel drivers, and restricting physical access to USB-C ports on sensitive systems where feasible.

How to confirm the fix worked

Confirm the running kernel package or custom kernel source includes the fix in the UCSI CCG remove path: free_irq() must occur before ucsi_destroy() for the removed device state. Validate through vendor advisories, kernel changelog review, or source inspection of drivers/usb/typec/ucsi/ucsi_ccg.c. On live systems, identify whether the relevant driver is present or loaded using standard module and kernel inventory tools, and confirm the system has rebooted into the fixed kernel after patching. For engineering validation, run the driver under KASAN or other kernel memory sanitizers while exercising USB-C connector changes and driver removal paths; a fixed build should not report use-after-free involving ccg_irq_handler(), ucsi_notify_common(), or ucsi_connector_change().

Typical attack path

1. Identify a Linux system running an affected kernel with the USB Type-C UCSI CCG driver in use.
2. Obtain local or physical influence over USB Type-C connector events or driver bind/unbind/removal behavior.
3. Trigger a connector-change event while the driver remove path is freeing UCSI state.
4. Win the race where ccg_irq_handler() runs after ucsi_destroy() has freed the UCSI object but before the IRQ is freed.
5. Cause kernel memory corruption, most likely resulting in a kernel oops, panic, or denial of service.

How to detect it

There are no unique network indicators for this issue because exploitation would occur locally in kernel driver code. To assess possible prior exploitation or triggering, review kernel logs, crash dumps, pstore/ramoops records, systemd-journal entries, hypervisor console logs, and endpoint telemetry for kernel oops, panic, KASAN, or use-after-free reports involving the UCSI CCG USB Type-C driver. Focus on events around USB-C plug/unplug activity, driver unbind/removal, suspend/resume, shutdown, docking changes, or kernel module operations. Look for stack traces containing ccg_irq_handler(), ucsi_notify_common(), ucsi_connector_change(), ucsi_destroy(), or drivers/usb/typec/ucsi/ucsi_ccg.c. Because symptoms may resemble instability rather than a clear compromise, correlate crashes with local user activity, physical access, module unloads, sysfs driver unbind operations, and repeated USB-C connector-change events.

• KASAN: use-after-free
• BUG: KASAN
• use-after-free in ucsi_notify_common
• use-after-free in ccg_irq_handler
• ccg_irq_handler
• ucsi_notify_common
• ucsi_connector_change
• ucsi_destroy
• ucsi_ccg
• drivers/usb/typec/ucsi/ucsi_ccg.c
• Unable to handle kernel paging request
• kernel BUG at drivers/usb/typec/ucsi
• general protection fault
• Oops:
• Kernel panic - not syncing
• /sys/bus/i2c/drivers/ucsi_ccg/unbind
• /sys/bus/platform/drivers/ucsi_ccg/unbind

What your security team should do

• Track Linux distribution and appliance-vendor advisories for this kernel fix and schedule patching through the standard kernel maintenance process.
• Prioritize patching for systems that use USB-C/Type-C hardware, embedded Linux images, laptops, kiosks, developer workstations, and devices where users can physically interact with ports.
• Confirm patched kernels are actually booted after update; kernel package installation alone is insufficient.
• Restrict unnecessary local administrative capabilities that allow driver unbinding, module removal, or low-level device manipulation.
• Monitor kernel logs for crashes or sanitizer reports referencing UCSI, ucsi_ccg, ccg_irq_handler(), ucsi_notify_common(), or use-after-free conditions.
• Do not treat this as an internet-exposed remote code execution issue unless a specific downstream vendor advisory states otherwise; current public risk is low and no exploitation is known.