In the Linux kernel, the following vulnerability has been resolved:
iommufd: Prevent ALIGN() overflow
When allocating IOVA the candidate range gets aligned to the target
alignment. If the range is close to ULONG_MAX then the ALIGN() can
wrap resulting in a corrupted iova.
Open code the ALIGN() using get_add_overflow() to prevent this.
This simplifies the checks as we don't need to check for length earlier
either.
Consolidate the two copies of this code under a single helper.
This bug would allow userspace to create a mapping that overlaps with some
other mapping or a reserved range.
Security readout for executives and security teams
Plain-English summary
A flaw in the Linux kernel’s I/O memory mapping subsystem can corrupt address allocation calculations. A locally authenticated, low-privilege user could potentially create a mapping that overlaps another mapping or protected range, threatening confidentiality, integrity, and availability. The issue matters most on systems exposing iommufd functionality to untrusted local users or workloads.
Executive priority
Prioritize remediation on shared Linux hosts, virtualization infrastructure, and systems running untrusted workloads. Internet exposure alone is not the primary condition because the documented attack vector is local. Complete an inventory and vendor-status check promptly; accelerate patching where low-privilege users can access iommufd.
Technical view
During IOVA allocation, aligning a candidate range near ULONG_MAX can overflow and wrap. The resulting corrupted IOVA may overlap an existing mapping or reserved range. The kernel fix replaces unsafe ALIGN() handling with overflow-aware arithmetic and consolidates duplicated validation logic.
Likely exposure
The supplied data identifies Linux kernel versions 6.2, 6.6.103, 6.12.43, 6.15.11, 6.16.2, and 6.17 as affected. Practical exposure depends on whether an untrusted local user or workload can access the vulnerable iommufd path. Distribution-specific status is not provided.
Exploitation context
The CVSS vector describes local, low-complexity exploitation requiring low privileges and no user interaction, with potential cross-scope impact. The supplied record is not in KEV and provides no evidence of active exploitation or a public exploit. Treat exploit prevalence as unknown rather than confirmed.
Researcher notes
The core invariant failure is integer wrap during alignment of an IOVA candidate near ULONG_MAX. That may bypass range expectations and permit overlap with mapped or reserved address space. The bundle supplies multiple stable-kernel commits but does not map each commit to a specific release or provide reproduction details.
Mitigation direction
Apply a vendor-supported kernel update containing the referenced overflow fix.
Check the Linux distribution’s advisory for exact affected and fixed package versions.
Prioritize multi-user, virtualization, and workload-hosting systems exposing iommufd to untrusted users.
Restrict untrusted local access to affected systems until updates are validated.
Validation and detection
Record each system’s running kernel and distribution package version.
Compare versions with current distribution guidance for CVE-2025-38688.
Determine whether untrusted local users or workloads can reach iommufd interfaces.
Confirm the installed kernel incorporates an applicable referenced stable fix.
Reboot into the updated kernel and verify the running version.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-38688 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
6Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.