CVE-2026-64329 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove
The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(), which on a connector-change event calls ucsi_connector_change() and schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees uc->ucsi (kfree) before free_irq() is called, so a handler invocation already in flight may access the freed object after ucsi_destroy().
CPU 0 (remove) | CPU 1 (threaded IRQ) ucsi_destroy(uc->ucsi) | ccg_irq_handler() kfree(ucsi) // FREE | ucsi_notify_common(uc->ucsi) // USE
Move free_irq() before ucsi_destroy() in the remove path. It is kept after ucsi_unregister(): ucsi_unregister() cancels connector work whose handler issues GET_CONNECTOR_STATUS through ucsi_send_command_common(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled.
The probe error path already orders free_irq() before ucsi_destroy().
This bug was found by static analysis.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
This vulnerability represents a critical use-after-free condition in the Linux kernel's USB Type-C subsystem, specifically within the CCG (Cypress Chip Generation) driver component. The flaw occurs during device removal when the threaded interrupt handler attempts to access memory that has already been freed, creating a potential security risk and system instability. The issue affects the ucsi (USB Type-C Connector System Interface) framework which manages USB Type-C connector states and notifications. When a device is removed, the kernel's cleanup sequence improperly orders operations, leading to a race condition between the interrupt handler execution and memory deallocation. This particular vulnerability falls under CWE-416, which classifies use-after-free conditions as a fundamental memory safety issue that can lead to arbitrary code execution or system crashes.
The technical implementation flaw stems from improper ordering of cleanup operations within the device removal path of the ucsi_ccg_remove() function. During normal operation, the ccg_irq_handler() processes interrupt events and calls ucsi_notify_common() which subsequently invokes ucsi_connector_change() and schedules connector work for asynchronous processing. However, when the device is removed, the ucsi_destroy() function frees the uc->ucsi structure using kfree() before free_irq() is called to disable the interrupt handling mechanism. This sequence creates a window where an already scheduled interrupt handler execution can access the freed memory location, potentially leading to kernel memory corruption or privilege escalation attacks.
The operational impact of this vulnerability extends beyond simple system instability to encompass potential security compromise. Attackers could theoretically exploit this race condition to execute arbitrary code within kernel space by manipulating USB Type-C connector events during device removal. The vulnerability affects systems using USB Type-C hardware with CCG chipsets, particularly those implementing the ucsi subsystem for connector management. Given that USB Type-C ports are ubiquitous in modern computing devices, including laptops, desktops, and mobile devices, this flaw could potentially impact a wide range of systems running affected Linux kernel versions. The use-after-free condition also creates opportunities for denial-of-service attacks where system stability is compromised through repeated triggering of the race condition.
The mitigation strategy requires reordering the cleanup operations within the device removal path to ensure that interrupt handling is disabled before memory deallocation occurs. This approach aligns with established kernel development practices and security standards such as those recommended by the Linux Kernel Security Team. The fix implements a proper sequence where free_irq() is called before ucsi_destroy(), preventing the scenario where an interrupt handler might access freed memory. This solution maintains compatibility with existing code patterns while addressing the root cause identified through static analysis, which is consistent with modern security practices that emphasize automated vulnerability detection tools in kernel development. The solution also preserves proper synchronization semantics by maintaining the correct ordering of ucsi_unregister() operations that handle pending work items and ensure completion signaling occurs before interrupt disablement.
This vulnerability demonstrates the importance of careful resource management in kernel-level code and the potential consequences of race conditions in concurrent systems. The fix exemplifies best practices for interrupt handling and memory management within the Linux kernel, ensuring proper cleanup sequences that prevent use-after-free conditions while maintaining system functionality. The static analysis approach used to identify this flaw represents a proactive security measure that complements traditional testing methods in kernel development, aligning with ATT&CK framework concepts related to privilege escalation and resource exploitation through kernel vulnerabilities.