CVE-2024-35977 in Linux
Summary
by MITRE • 05/20/2024
In the Linux kernel, the following vulnerability has been resolved:
platform/chrome: cros_ec_uart: properly fix race condition
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: ... ? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) {
struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH! return 0;
return serdev->ops->receive_buf(serdev, data, count); }
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 05/20/2024
The vulnerability described in CVE-2024-35977 represents a critical race condition within the Linux kernel's chrome platform driver, specifically affecting the cros_ec_uart subsystem. This issue manifests as a NULL pointer dereference that can lead to system crashes and potential denial of service conditions. The problem occurs in the cros_ec_uart_probe() function where the sequence of operations creates a window of vulnerability between device initialization and operation setup. The kernel's serial device framework, known as serdev, manages communication between serial devices and their controllers, and this particular flaw exploits a timing issue in how these components are initialized. The vulnerability impacts Chrome OS systems that rely on the Chrome EC (Embedded Controller) UART interface for communication with various system components.
The technical flaw stems from improper ordering of initialization calls within the device probe function. When cros_ec_uart_probe() executes, it first invokes devm_serdev_device_open() which sets the SERPORT_ACTIVE flag and potentially triggers asynchronous operations. Only after this initial call does the function proceed to establish the device operations via serdev_device_set_client_ops(). This sequence creates a temporal gap where the serdev controller might attempt to process incoming data before the device operations structure is properly populated. The crash occurs in the serdev_controller_receive_buf() function when it attempts to access serdev->ops->receive_buf without first validating that the operations structure exists, leading to the NULL pointer dereference that terminates the kernel execution. This race condition is particularly dangerous because it can be triggered during normal system operation when the device is being initialized, making it a latent vulnerability that may not manifest until specific timing conditions are met.
The operational impact of this vulnerability extends beyond simple system crashes, as it can compromise the stability and reliability of Chrome OS devices. Systems relying on the Chrome EC for critical functions such as power management, thermal monitoring, and device communication may experience unexpected shutdowns or failures during device initialization phases. The vulnerability affects devices running Linux kernel versions that include the problematic cros_ec_uart implementation, potentially impacting a wide range of Chromebooks and other Chrome OS devices. Attackers could potentially exploit this race condition to cause persistent system instability or in more sophisticated scenarios, leverage the crash to perform privilege escalation attacks, though the direct exploitation vector remains limited due to the nature of kernel-level race conditions. The issue demonstrates a fundamental flaw in how asynchronous device initialization is handled within the kernel's serial device framework, highlighting the complexity of managing concurrent access patterns in embedded system drivers.
Mitigation strategies for this vulnerability require immediate kernel updates that implement the corrected initialization sequence where all device operations are properly configured before any asynchronous device operations begin. System administrators should prioritize applying the latest kernel patches that address this specific race condition, as the fix ensures that serdev_device_set_client_ops() is called before devm_serdev_device_open() to eliminate the temporal window where the NULL pointer dereference can occur. Additionally, implementing proper kernel lockdown configurations and ensuring that only trusted firmware components are loaded can help reduce the attack surface. The fix aligns with security best practices outlined in the Common Weakness Enumeration (CWE) category CWE-362, which addresses race conditions in concurrent systems, and follows the ATT&CK framework's approach to kernel exploitation techniques by preventing the conditions that enable privilege escalation through kernel memory corruption. Organizations should also consider implementing monitoring solutions to detect unusual system behavior that might indicate the exploitation of such timing-based vulnerabilities, particularly in environments where Chrome OS devices are deployed.