Cloudanix VulnDB

CVE-2026-90424

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A coding mistake in the Linux kernel for certain NVIDIA hardware can waste small amounts of memory when the system fails to start the driver correctly.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Two error paths in tegra241_cmdqv_init_structures() and related functions leak a VINTF0 structure allocated with kzalloc_obj() because ownership decisions rely on a hyp_own flag that is not yet set; mutex_destroy() and ida_destroy() are also skipped or incorrectly invoked.

Why it matters to the business

On systems using the affected Tegra241 IOMMU hardware, repeated driver initialization failures can gradually exhaust kernel memory and other limited resources, causing instability or degraded performance over time.

How an attack unfolds

An attacker with the ability to trigger repeated probe or initialization failures for the tegra241-cmdqv driver (for example via crafted device or IOMMU configuration) can cause the kernel to leak VINTF0 objects without proper cleanup; the flaw is not known to be exploited in the wild and no threat actors are associated with it.

How to fix it

Update the Linux kernel to a version containing the fix that keys ownership decisions on vintf->idx instead of the uninitialized hyp_own flag; apply the patch that adds direct frees on the init_vintf failure path and adjusts remove_vintf logic.

How to confirm the fix worked

Confirm the presence of the corrected ownership check based on vintf->idx and the direct free of VINTF0 on the init_vintf failure path in the source; test driver probe failure scenarios and verify no leaks via kmemleak or similar tools.

Typical attack path

  1. Gain ability to induce IOMMU driver initialization failures
  2. Trigger tegra241_cmdqv_init_vintf() or VCMDQ preallocation error paths
  3. Observe gradual kernel memory or resource consumption without corresponding frees

How to detect it

Look in kernel logs for repeated tegra241_cmdqv probe or initialization failures; use kmemleak reports or slab accounting to identify leaked VINTF0 objects; no public exploitation artifacts are known.

What your security team should do

  • Apply the upstream fix for the VINTF0 leak as soon as a patched kernel is available
  • Monitor kernel memory usage on Tegra241-based systems during driver initialization
  • Prioritize systems that frequently reinitialize the IOMMU driver

The record

In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Fix VINTF0 leak on the init-failure path tegra241_cmdqv_init_structures() allocates VINTF0 with kzalloc_obj(), inits it, and preallocates its logical VCMDQs. Two of its error paths leak. When tegra241_cmdqv_init_vintf() fails it returns before VINTF0 reaches the cmdqv->vintfs[] array, so the devres unwind on probe failure cannot reach it; free it directly there. A later VCMDQ preallocation failure instead leaves VINTF0 published, and so this time the unwind does reach tegra241_cmdqv_remove_vintf(), which then frees it from vintf->hyp_own. But tegra241_vintf_hw_init() sets that flag only afterward, from a HW read-back, so the still-uninited VINTF0 reads as guest-owned and leaks, with mutex_destroy() and ida_destroy() run on fields it never set up. Decide ownership from vintf->idx instead, the index assigned when its id is allocated: idx 0 is the kernel-owned VINTF0, while idx >= 1 marks a guest VINTF. So the in-kernel free decision in tegra241_cmdqv_remove_vintf() and tegra241_vintf_free_lvcmdq() now keys on idx too, and hyp_own stays a pure HW-readback state.

Affected packages

Ecosystem Package Introduced Fixed