KernelScan.io

HIGH

iommu/vt-d DevPasid NullDeref

CVE-2026-53281

CVSS 8.8 / 10.0 NVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

KernelScan AI5.5MEDIUM

01

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid NULL pointer dereference or refcount corruption Commit 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") fixed a NULL pointer dereference in an unlikely situation partly. If dev_pasid is not found in the dev_pasids list, it remains NULL. However, the teardown operations are executed unconditionally, this lead to a NULL pointer dereference or refcount corruption. If the domain was never attached to this IOMMU, info will be NULL, which would cause an immediate dereference when checking --info->refcnt. Even if info is not NULL, decrementing the refcount without having removed a valid PASID might unbalance the count. This could lead to premature dropping of the refcount to 0, potentially causing a use-after-free for the remaining active devices sharing the domain. Fix it by returning early if dev_pasid is NULL, before executing the teardown operations. Issue found by AI review and suggested by Kevin Tian. https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com

02

Engine v0.3.0

Risk summary

A privileged process managing IOMMU PASID assignments can trigger a NULL pointer dereference or refcount underflow in the Intel VT-d driver when domain_remove_dev_pasid fails to find a dev_pasid entry. The refcount underflow can cause premature freeing of a shared domain structure, potentially leading to a use-after-free that leaks kernel heap information and corrupts memory for other active devices. Exploitation requires CAP_SYS_ADMIN or equivalent privilege to manage IOMMU domains.

Affecteddrivers/iommu/intel/iommu.c (Intel VT-d IOMMU)

Vulnerability analysis

The root cause is in domain_remove_dev_pasid() in drivers/iommu/intel/iommu.c. When the dev_pasid entry is not found in the dev_pasids list (dev_pasid remains NULL), the code previously continued to execute teardown operations unconditionally. This caused two problems: (1) if the domain was never attached to the IOMMU, info would be NULL, causing an immediate NULL dereference when decrementing info->refcnt inside domain_detach_iommu(); (2) even if info was non-NULL, decrementing the refcount without a valid PASID removal unbalances the count, potentially dropping it to zero prematurely and causing a use-after-free for other devices sharing the domain. The fix adds an early return with WARN_ON_ONCE when dev_pasid is NULL, before any teardown operations are executed. This prevents both the NULL dereference and the refcount corruption. The attack surface requires a privileged actor (CAP_SYS_ADMIN) to configure IOMMU PASID assignments in an inconsistent state, making this a local privileged issue with availability, confidentiality, and integrity impacts.

03

BranchFixed inPatch commit
6.126.139022cb9ac0c2
6.136.14cdfe3c9f2c9e
6.186.18.3379ea2feb917b
7.07.0.10
mainline7.1