CVE-2026-89977 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
accel/ethosu: check MMIO mapping errors in probe
devm_platform_ioremap_resource() returns an error pointer when the register resource cannot be mapped. ethosu_probe() stores it and continues until initialization dereferences it through MMIO accessors.
Return the mapping error before initializing the device.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel driver for Arm Ethos-U accelerators contains a critical flaw in its probe function where memory-mapped I/O resource mappings are not validated prior to use. The devm_platform_ioremap_resource() API is responsible for acquiring and mapping physical register resources into the virtual address space of the kernel. When this operation fails, typically due to hardware configuration issues or invalid device tree entries, it returns an error pointer rather than a valid memory address. In the affected implementation, the ethosu_probe function stores this potentially erroneous return value without checking its validity. This oversight allows the driver initialization sequence to proceed under the false assumption that the hardware registers are accessible at the mapped virtual address.
The operational impact of this vulnerability manifests when the driver attempts to interact with the accelerator hardware through MMIO accessors. Since the stored pointer is an error code disguised as a memory address, any subsequent read or write operation targeting these registers results in accessing invalid kernel memory space. This leads to immediate kernel panic or system crash because the CPU attempts to execute instructions on non-existent physical addresses. In some configurations, this could potentially lead to undefined behavior if the error pointer value coincidentally maps to accessible but unrelated memory regions, though a fault is the most common outcome. The vulnerability effectively renders the Ethos-U accelerator unusable and destabilizes the entire operating system upon driver load attempts for misconfigured or faulty hardware instances.
From a security perspective, this flaw represents an improper input validation issue where external configuration data derived from device tree nodes is not rigorously checked before being used as a control flow determinant. The lack of error handling allows a malformed or maliciously crafted device tree to trigger a denial-of-service condition against the local system. This aligns with CWE-252, which covers unchecked return values, and specifically relates to improper resource initialization that leads to crashes. In terms of adversary behavior, this vulnerability could be exploited in scenarios where an attacker has control over the boot configuration or device tree parameters, allowing them to crash the host system during startup or driver loading phases. This maps to ATT&CK technique T1529, System Shutdown/Reboot, as it enables a local user with access to modify firmware configurations to disrupt service availability.
To mitigate this vulnerability, developers must implement strict validation of all resource mapping operations before proceeding with device initialization. The ethosu_probe function should immediately check the return value of devm_platform_ioremap_resource() using standard kernel macros such as IS_ERR or PTR_ERR. If an error is detected, the probe routine must abort and return the corresponding negative error code to the driver core, preventing any further interaction with invalid memory addresses. This ensures that hardware misconfigurations result in a clean failure of the driver load rather than a catastrophic system crash. Maintaining robust error handling practices during resource acquisition is essential for kernel stability and security, particularly when dealing with hardware-specific drivers that interact directly with physical device registers.