CVE-2024-57914 is a vulnerability identified in the Linux kernel's USB Type-C Port Controller Interface (TCPCI) driver, specifically in the interrupt handling logic for shared IRQ (interrupt request) scenarios. The vulnerability arises due to a NULL pointer dereference in the tcpci_irq() function when two Type-C ports share a single IRQ line. The root cause is a race condition between the registration of the second port's interrupt handler and the arrival of interrupts. If an interrupt for the second port occurs before its tcpci structure is fully initialized (tcpci_register_port() has completed), the interrupt handler attempts to dereference a NULL pointer, leading to a kernel NULL pointer dereference and consequent kernel panic or system crash. This is evidenced by kernel oops messages and memory abort information indicating an invalid memory access at address 0x10. The issue stems from the order of operations in the driver: tcpci_register_port() is called after devm_request_threaded_irq(), which can cause the interrupt handler to run before the tcpci pointer is set. The fix involves restoring the logic to call tcpci_register_port() earlier but also adjusting the ALERT_MASK register setting to occur after devm_request_threaded_irq() returns, ensuring the hardware interrupt alerts are correctly managed and no interrupts are missed. This vulnerability affects Linux kernel versions containing the commit 77e85107a7717ecb755cf77a2752a2aadd28c4e3 and likely other versions with similar driver code. It is a stability and availability issue rather than a direct confidentiality or integrity compromise, as it causes kernel crashes via NULL pointer dereference. No known exploits are reported in the wild, and no CVSS score has been assigned yet.

For European organizations, this vulnerability primarily impacts the availability and stability of Linux-based systems that utilize USB Type-C ports managed by the TCPCI driver, especially those where multiple Type-C ports share a single IRQ line. This includes embedded devices, industrial control systems, IoT devices, and general-purpose servers or workstations running affected Linux kernels. A successful exploitation leads to kernel crashes, causing system reboots or downtime, which can disrupt business operations, critical infrastructure, or service availability. While it does not directly expose data confidentiality or integrity, repeated crashes could lead to denial of service conditions. Organizations relying on Linux for critical infrastructure, manufacturing, or telecommunications could face operational interruptions. The impact is more pronounced in environments with high USB Type-C device usage or custom hardware configurations employing shared IRQs. Since the vulnerability is in the kernel, it affects all users of the vulnerable kernel versions, including cloud providers and enterprises using Linux distributions based on affected kernels. The lack of known exploits suggests limited immediate threat, but the potential for denial of service warrants timely remediation.

European organizations should promptly update their Linux kernels to versions that include the fix for CVE-2024-57914. Kernel updates should be sourced from trusted Linux distribution vendors or directly from the Linux kernel mainline if using custom builds. For embedded or IoT devices, firmware updates incorporating the patched kernel must be deployed. In environments where immediate patching is not feasible, organizations should monitor kernel logs for signs of NULL pointer dereference or kernel oops related to tcpci_irq and consider isolating affected hardware or disabling shared IRQ configurations if possible. Testing kernel updates in staging environments is recommended to ensure compatibility. Additionally, organizations should review their USB Type-C hardware configurations to avoid shared IRQ lines where feasible, reducing the attack surface. Implementing robust system monitoring and automated reboot mechanisms can help mitigate downtime caused by unexpected kernel crashes. Finally, maintaining an inventory of devices running vulnerable kernel versions will aid in prioritizing patch deployment.