Skip to main content
Vulnerability Database/CVE-2026-80818

CVE-2026-80818: Linux Kernel IOMMU Use-After-Free Vulnerability

CVE-2026-80818 is a use-after-free flaw in the Linux kernel IOMMU Tegra241 CMDQV driver that can cause kernel crashes during teardown. This post explains its technical details, affected versions, and mitigation steps.

Published:

CVE-2026-80818 Overview

CVE-2026-80818 is a use-after-free vulnerability in the Linux kernel's iommu/tegra241-cmdqv driver. The flaw occurs during device teardown, when arm_smmu_impl_remove() runs after smmu->cmdq.q.base has already been freed. The tegra241_cmdqv_remove_vintf() path issues a CMD_SYNC command against the freed queue memory, triggering a kernel oops.

The issue affects the ARM SMMU-v3 implementation used with NVIDIA Tegra241 platforms. It manifests during failed probe unwind (for example when the VCMDQ fails to enable) and during driver unbind. The kernel maintainers resolved the flaw by dropping the VINTF deinit from the remove path and quiescing VINTFs earlier via a new device_disable() implementation op.

Critical Impact

A use-after-free during IOMMU driver teardown can cause kernel memory corruption, denial of service, and potentially local privilege escalation on affected NVIDIA Tegra241 systems.

Affected Products

  • Linux kernel versions containing the tegra241-cmdqv driver with the pre-fix arm_smmu_impl_remove() devres registration ordering
  • ARM SMMU-v3 driver on NVIDIA Tegra241 (Grace) platforms
  • Systems using the iommufd viommu destroy path with Tegra241 CMDQV

Discovery Timeline

  • 2026-09-04 - CVE-2026-80818 published to NVD
  • 2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80818

Vulnerability Analysis

The vulnerability is a use-after-free [CWE-416] in the ARM SMMU-v3 driver teardown sequence on NVIDIA Tegra241 platforms. During arm_smmu_impl_probe(), the driver registers arm_smmu_impl_remove() as a device-managed (devres) action. That registration happens before arm_smmu_init_queues() allocates the command queue backing buffer at smmu->cmdq.q.base.

When the devres unwind runs, either after a failed probe or during an unbind, the command queue memory is released first. The registered arm_smmu_impl_remove() action then invokes tegra241_cmdqv_remove_vintf(), which calls into tegra241_vintf_hw_deinit() and tegra241_vcmdq_hw_deinit(). The VINTF deinit path issues a CMD_SYNC through arm_smmu_cmdq_issue_cmdlist(), writing into the already-freed queue base and producing a kernel oops.

Maintainers reproduced the flaw with a QEMU hack that forces the VCMDQ enable to fail, causing impl reset failure with error -110 and triggering the devres unwind into the freed memory access.

Root Cause

The root cause is action ordering in the devres unwind stack. Because the remove callback was registered before the queue was allocated, devres frees the queue first and then runs a callback that still touches the queue. The Tegra241 CMDQV remove path did not account for the possibility that the underlying SMMU command queue could already be released.

Attack Vector

Exploitation requires local access to a system with the affected driver loaded and the ability to trigger an SMMU-v3 driver unbind, a failed probe, or an iommufd viommu destroy. A local attacker with sufficient privileges to unbind the driver, or a fault condition during boot that fails the impl reset, can trigger the use-after-free. The freed memory access can produce a denial-of-service oops and, depending on allocator reuse timing, kernel memory corruption.

No public exploit is available and the flaw is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS probability is 0.168%.

The vulnerability mechanism is detailed in the upstream commits. See the kernel commit d2ab08437e91 and related fixes for the source-level changes.

Detection Methods for CVE-2026-80818

Indicators of Compromise

  • Kernel log messages of the form tegra241_cmdqv: VINTF0: VCMDQ0/LVCMDQ0: failed to enable, STATUS=0x00000000 followed by failed to reset impl.
  • Kernel oops with call trace containing arm_smmu_cmdq_issue_cmdlist, tegra241_vcmdq_hw_deinit, tegra241_vintf_hw_deinit, and tegra241_cmdqv_remove_vintf.
  • arm-smmu-v3 probe failures with error -110 (ETIMEDOUT) accompanied by devres unwind traces.

Detection Strategies

  • Monitor dmesg and journalctl -k for arm-smmu-v3 probe failures and Tegra241 CMDQV VCMDQ enable errors on NVIDIA Grace and Tegra241 hardware.
  • Alert on kernel oops entries referencing devm_action_release combined with arm_smmu_impl_remove on affected platforms.
  • Track driver bind and unbind events on /sys/bus/platform/drivers/arm-smmu-v3 to correlate teardown activity with kernel faults.

Monitoring Recommendations

  • Forward kernel logs from Tegra241-based hosts to a centralized logging pipeline and build detections on the specific tegra241_cmdqv and arm-smmu-v3 error signatures.
  • Baseline expected IOMMU driver bind and unbind events; investigate any unexpected iommufd viommu destroy operations.
  • Correlate kernel crash telemetry with the running kernel version to identify hosts still on unpatched builds.

How to Mitigate CVE-2026-80818

Immediate Actions Required

  • Apply the upstream Linux kernel patches for the iommu/tegra241-cmdqv driver on all affected NVIDIA Tegra241 systems.
  • Inventory hosts running ARM SMMU-v3 with the Tegra241 CMDQV driver and prioritize kernel updates on those systems.
  • Restrict local privileges required to unbind platform drivers via /sys/bus/platform/drivers/ to trusted administrative users only.

Patch Information

The fix drops the VINTF deinit from tegra241_cmdqv_remove_vintf() so the devres unwind no longer touches the freed queue. VINTFs are quiesced earlier through a new device_disable() implementation op invoked from arm_smmu_disable_action() while the CMDQ is still live. The iommufd viommu destroy path is also updated to quiesce before teardown. Fixes are available in the following commits:

Workarounds

  • Avoid manual unbind operations on the arm-smmu-v3 driver on affected Tegra241 systems until the patched kernel is deployed.
  • Do not trigger iommufd viommu destroy flows on unpatched hosts.
  • Where feasible, disable interfaces that expose driver unbind capabilities to unprivileged users and audit access to sysfs platform driver controls.

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.