CVE-2026-90427 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
iommu/tegra241-cmdqv: Don't fall back to a freed smmu after devm_krealloc()
__tegra241_cmdqv_probe() uses devm_krealloc() to grow @smmu into the larger tegra241_cmdqv, which frees the original @smmu once it relocates. A failure after that returned NULL, and the caller then dereferenced the freed @smmu on its fallback path.
Return an int and take @smmu by reference instead, then update *smmu to the reallocated pointer after devm_krealloc() succeeds, so the caller and its fallback path both use the live @smmu rather than the freed original.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the Linux kernel's Tegra241 IOMMU driver represents a classic use-after-free condition arising from improper memory management during device probe operations. Specifically, within the __tegra241_cmdqv_probe function, the code attempts to resize an existing structure by using devm_krealloc to expand the original smmu pointer into a larger tegra241_cmdqv structure. The core technical flaw lies in how this reallocation is handled when it fails or completes; if devm_krealloc succeeds, it frees the original memory block and returns a new pointer to the relocated data. However, prior to the fix, if an error occurred after this point, the code would return NULL while still holding a reference to the now-freed original smmu object in its fallback path. This leads to a critical scenario where subsequent operations attempt to dereference or access memory that has already been released back to the system allocator, resulting in undefined behavior, potential kernel panics, or arbitrary code execution if an attacker can influence the state of the freed memory through heap spraying techniques.
From a technical perspective, this issue is categorized under CWE-416, which describes Use After Free vulnerabilities. The root cause is not merely the allocation strategy but the lack of atomicity in updating the pointer reference before error handling paths are executed. By returning an integer status code and passing the smmu pointer by reference, the corrected implementation ensures that the caller always operates on a valid memory address. If reallocation succeeds, *smmu is updated to point to the new, larger block immediately. This design guarantees that both successful execution paths and error handling routines interact with live, allocated memory rather than dangling pointers. This approach aligns with robust defensive programming practices recommended in secure coding standards for systems software, emphasizing the importance of maintaining pointer validity throughout the lifecycle of dynamic allocations within kernel space.
The operational impact of this vulnerability is significant due to its location within the IOMMU subsystem, which manages hardware access to system memory and plays a crucial role in isolating devices from each other and from the host operating system. An attacker with local access who can trigger device probe failures or manipulate driver initialization sequences could exploit this flaw to crash the kernel, leading to denial of service conditions. More severely, if the freed memory is reallocated for sensitive data structures before being accessed again, it may allow an unprivileged user to read or write arbitrary kernel memory, effectively bypassing isolation boundaries and gaining elevated privileges. This compromises the integrity and confidentiality guarantees provided by the IOMMU hardware features such as DMA remapping and interrupt remapping.
Mitigation strategies primarily involve applying the upstream Linux kernel patch that corrects the pointer handling logic in iommu/tegra241-cmdqv.c. System administrators should ensure their systems are updated to a version of the kernel where this fix is included, particularly for devices utilizing NVIDIA Tegra 241 SoCs with IOMMU capabilities. For environments unable to patch immediately, restricting physical access and monitoring for unusual system crashes or log entries related to device probe failures can help detect exploitation attempts. Additionally, enabling Kernel Hardening features such as SLAB_FREELIST_HARDENED and KASAN (Kernel Address Sanitizer) in development builds can aid in detecting similar memory safety issues early in the software lifecycle. From a broader security architecture standpoint, this incident underscores the importance of rigorous code review for driver-level memory management patterns to prevent low-level exploitation vectors that could undermine system stability and security controls defined by frameworks like MITRE ATT&CK technique T1059 Command and Scripting Interpreter or T1498 Network Denial of Service when exploited in conjunction with other vulnerabilities.