In the Linux kernel, the following vulnerability has been resolved:
iommufd: Fix iopt_access_list_id overwrite bug
Syzkaller reported the following WARN_ON:
WARNING: CPU: 1 PID: 4738 at drivers/iommu/iommufd/io_pagetable.c:1360
Call Trace:
iommufd_access_change_ioas+0x2fe/0x4e0
iommufd_access_destroy_object+0x50/0xb0
iommufd_object_remove+0x2a3/0x490
iommufd_object_destroy_user
iommufd_access_destroy+0x71/0xb0
iommufd_test_staccess_release+0x89/0xd0
__fput+0x272/0xb50
__fput_sync+0x4b/0x60
__do_sys_close
__se_sys_close
__x64_sys_close+0x8b/0x110
do_syscall_x64
The mismatch between the access pointer in the list and the passed-in
pointer is resulting from an overwrite of access->iopt_access_list_id, in
iopt_add_access(). Called from iommufd_access_change_ioas() when
xa_alloc() succeeds but iopt_calculate_iova_alignment() fails.
Add a new_id in iopt_add_access() and only update iopt_access_list_id when
returning successfully.
Security readout for executives and security teams
Plain-English summary
A Linux kernel iommufd bookkeeping bug can leave an access object with the wrong list identifier after an error. A locally authenticated, low-privileged user may be able to trigger the vulnerable path without user interaction. The supplied rating indicates potentially serious confidentiality, integrity, and availability impact, although the sources only document a kernel warning and inconsistent state, not a demonstrated compromise.
Executive priority
Treat as a high-priority kernel maintenance issue on systems granting local access to untrusted users, especially virtualization or device-assignment hosts. Patch through normal emergency or accelerated change controls after confirming vendor applicability. Internet-facing status alone does not establish exposure because the stated attack vector is local.
Technical view
In iopt_add_access(), xa_alloc() can succeed before iopt_calculate_iova_alignment() fails, prematurely overwriting access->iopt_access_list_id. Later destruction encounters a mismatch between the stored list pointer and supplied access pointer, producing a WARN_ON. The fix stores the allocated identifier in new_id and updates iopt_access_list_id only after successful completion. The record associates this issue with CWE-476.
Likely exposure
Exposure is limited to Linux systems containing the affected iommufd code and permitting a local low-privileged user to reach it. The bundle names kernel 6.6, 6.6.21, 6.7.9, and 6.8, but does not preserve clear range boundaries. Confirm exact affected and fixed builds through distribution or kernel vendor guidance.
Exploitation context
The CVSS vector describes local access, low complexity, low privileges, and no user interaction. CISA KEV status is false, and the supplied sources provide no evidence of active exploitation or a public exploit. Syzkaller discovered the condition through automated kernel testing. Real-world exploitability and practical security impact are not established in this bundle.
Researcher notes
The failure sequence is specific: xa_alloc() succeeds, alignment calculation fails, and the access identifier has already changed. Cleanup later detects inconsistent list membership. The corrective pattern is transactional assignment of new_id only on success. The bundle does not establish memory corruption, privilege escalation, data disclosure, denial of service, or exploit reliability beyond the CVSS impact assessment.
Mitigation direction
Update to a vendor-supported kernel containing the referenced upstream or stable fix.
Check distribution advisories for backported fixes because package versions may not match upstream kernel versions.
Prioritize multi-user, shared-hosting, and other systems where untrusted users receive local access.
Restrict unnecessary local access while awaiting an approved kernel update.
Validation and detection
Inventory running kernel versions and identify systems using or exposing iommufd functionality.
Map each distribution kernel package to its vendor advisory and backport status.
Verify the deployed kernel contains the applicable referenced fix commit or vendor equivalent.
After updating, confirm systems boot normally and relevant virtualization or device-assignment workflows pass regression testing.
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.
cwe · low confidence lookup
CWE-476: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
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.
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.