Linux Kernel CVE-2025-40155

Requires an Intel VT-d IOMMU-capable system running an affected kernel, with the IOMMU/debugfs interface mounted and readable, and at least one device whose legacy-mode context entry has a Translation Type (TT) other than 00b or 01b so that SSPTPTR is uninitialized/zero. Exploitation is a local read of the intel_iommu domain translation debugfs file (e.g. via cat), so it is limited by: local access only (no network vector), the need for permissions to read kernel debugfs (normally root), Intel VT-d hardware, and the specific TT condition - it does not affect default configurations lacking VT-d or with debugfs restricted/disabled.

This is a low-priority issue in practice despite the 7.3 CVSS. The vector is local only (AV:L) and, although the published vector states PR:L, triggering it requires reading kernel debugfs IOMMU nodes, which are normally restricted to root - so the realistic privilege requirement is higher than PR:L implies (verify against your debugfs mount permissions). EPSS is 0.03% (9th percentile) and there is no KEV listing and no known POC, consistent with a bug that must be reached by an already-privileged local operator on Intel VT-d hardware. The dominant impact is a kernel crash (A:H); the CVSS also claims C:H, but the actual confidentiality exposure is bounded to whatever stale memory the bogus page-table walk happens to read before faulting, so C:H likely overstates real-world data disclosure. Signals are internally consistent (low EPSS, no KEV, no POC, local vector) and all point to minor, targeted-only risk rather than a widespread threat.

On an Intel VT-d host running an unpatched kernel, a local user with access to the IOMMU debugfs node (typically root) runs cat on the domain translation dump for a device whose context entry uses a legacy TT value other than 00b/01b. The kernel walks the uninitialized SSPTPTR as a page table and dereferences a non-canonical address, triggering a general-protection fault that panics or destabilizes the system. No public POC is known, and exploitation is limited to a local, debugfs-capable actor.