CVE-2026-89877 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
media: saa7164: fix cleanup on resource allocation failure
saa7164_dev_setup() adds the device to the global saa7164_devlist before requesting the PCI BAR memory regions.
If get_resources() fails, saa7164_dev_setup() decrements the device count and returns an error, but leaves the device on saa7164_devlist. The probe error path then frees the device, leaving a dangling entry on the global list.
Reuse the existing MMIO mapping error path to remove the device from saa7164_devlist and decrement the device count before returning.
Also release BAR0 if it was successfully requested but the BAR2 request fails.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the Linux kernel media subsystem, specifically within the saa7164 driver, represents a critical resource management flaw that can lead to use-after-free conditions and potential system instability or privilege escalation. The core of this issue lies in the initialization sequence of the saa7164_dev_setup function, which is responsible for setting up hardware resources during device probing. In the flawed implementation, the driver adds the newly allocated device structure to a global linked list named saa7164_devlist before attempting to request and map PCI Base Address Registers (BARs), specifically BAR0 and BAR2 memory regions. This ordering creates a race condition window where if subsequent resource allocation calls fail, such as those within get_resources(), the driver attempts to clean up by decrementing the device count and returning an error code. However, it fails to remove the device pointer from the global list before freeing the associated memory structures via standard probe error paths.
This oversight results in a dangling pointer remaining on the saa7164_devlist. Since the underlying memory for the device structure has been freed by the kernel's resource management routines, any subsequent operation that iterates over this global list to access active devices will encounter invalid memory references. This is classified under CWE-416, Use After Free, as the system retains a reference to an object after its lifetime has ended. The operational impact of such a vulnerability can be severe; depending on how and when another kernel component accesses the saa7164_devlist, it could lead to kernel panics due to null pointer dereferences or segmentation faults if the freed memory was reallocated for other purposes. In more sophisticated attack scenarios, an attacker with local access might exploit this inconsistency to achieve arbitrary code execution by manipulating the contents of the freed memory region before it is reused, thereby controlling the behavior of subsequent list iterations.
The remediation strategy involves correcting the cleanup logic within saa7164_dev_setup to ensure that all side effects are properly reversed upon failure. Specifically, if resource allocation fails after the device has been added to the global list, the driver must explicitly remove the device from saa7164_devlist and decrement the associated counter before returning an error code. This aligns with best practices for defensive programming in kernel space, ensuring that state consistency is maintained regardless of success or failure paths. Additionally, the fix addresses a secondary issue where BAR0 might be successfully requested but BAR2 fails; in such cases, BAR0 must also be released to prevent resource leaks and maintain hardware state integrity. This comprehensive cleanup ensures that no dangling references persist and that all allocated resources are properly returned to the system when initialization does not complete successfully.
From a broader security perspective, this vulnerability highlights the importance of strict adherence to atomicity in driver development, where partial successes must be fully rolled back to prevent inconsistent states. The ATT&CK framework categorizes such vulnerabilities under techniques related to privilege escalation or defense evasion if exploited by malicious actors seeking to disrupt system availability or gain unauthorized access through kernel memory corruption. Mitigation strategies include applying the provided patch immediately upon release and ensuring that driver code undergoes rigorous static analysis focusing on resource lifecycle management. Developers should also consider implementing robust error handling patterns where cleanup routines are centralized and guaranteed to execute regardless of which specific allocation step fails, thereby eliminating the possibility of leaving stale pointers in global data structures used by other kernel subsystems.