Cloudanix VulnDB

CVE-2026-90430

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing bug in the Linux kernel's IOMMU driver for certain NVIDIA Tegra chips could let the system crash when an error happens during setup.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition during LVCMDQ allocation allows the error ISR to observe a partially initialized structure and dereference NULL arm_smmu_cmdq register pointers.

Why it matters to the business

Kernel panic or denial of service on systems using the affected Tegra IOMMU driver, especially after kexec or when latched errors exist.

How an attack unfolds

An attacker or environmental condition triggers a latched LVCMDQ error ISR in the narrow window between pointer publication and full cmdq initialization, causing the handler to pass a zeroed queue structure downstream.

How to fix it

Update to a kernel containing the fix that moves LVCMDQ publication after full initialization and adds the required acquire/release barriers.

How to confirm the fix worked

Confirm the corrected initialization order and smp_store_release/smp_load_acquire usage are present in tegra241_vintf_init_lvcmdq and the error ISR path.

Typical attack path

  1. Trigger or inherit a latched LVCMDQ error across kexec
  2. Force the driver to allocate a new LVCMDQ via tegra241_vintf_init_lvcmdq
  3. Ensure the error ISR fires before tegra241_vcmdq_alloc_smmu_cmdq completes
  4. Observe NULL pointer dereference in __arm_smmu_cmdq_skip_err

How to detect it

Inspect kernel logs for NULL pointer dereferences or oopses in the IOMMU error handler paths around LVCMDQ or tegra241_vintf0_handle_error; no persistent artifacts are produced.

What your security team should do

  • Prioritize kernel updates on Tegra-based IOMMU systems
  • Monitor for unexplained kernel oops or panics referencing arm_smmu_cmdq
  • Test kexec paths on affected hardware after patching

The record

In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully initialized tegra241_vintf_init_lvcmdq() stores the freshly allocated vcmdq pointer to the vintf->lvcmdqs[] array, before tegra241_vcmdq_alloc_smmu_cmdq() builds the vcmdq->cmdq. The error ISR dereferences that cmdq, so a latched LVCMDQ error (e.g. one inherited across a kexec) firing in this window would make tegra241_vintf0_handle_error() pass the still-zeroed arm_smmu_cmdq down to __arm_smmu_cmdq_skip_err(), dereferencing NULL queue register pointers. Drop the store from tegra241_vintf_init_lvcmdq() and publish the vcmdq at the end of the allocation instead, with an smp_store_release() that pairs with an smp_load_acquire() in the ISR, which can see a fully built LVCMDQ or NULL. The user-owned LVCMDQ allocation moves accordingly, publishing the vcmdq once tegra241_vcmdq_hw_init_user() succeeds, using a plain store since a user VINTF's lvcmdqs[] has no lockless reader -- the error ISR only walks the VINTF0 array.

Affected packages

Ecosystem Package Introduced Fixed