Linux kernel Intel IOMMU: out-of-bounds memset in dmar_latency_disable() corrupts adjacent memory

UnscoredCVE-2026-68324Kernel, userspace & hypervisorcurated

Impact

The DMAR latency statistics teardown path clears sizeof(*lstat) * DMAR_LATENCY_NUM bytes starting at &lstat[type] instead of a single entry, so any type greater than zero writes zeroes past the end of the allocated array. On a GPU node the Intel IOMMU is the boundary that keeps a passed-through accelerator's DMA inside its assigned domain, so memory corruption in that driver's state is worth taking seriously even when the trigger is administrative. Reachable state is limited: the latency measurement facility is a debugfs-gated diagnostic, not something a tenant workload touches. Expected outcome is kernel memory corruption leading to instability rather than a demonstrated privilege boundary crossing.

Who can reach it

Local, privileged. Requires the ability to toggle the Intel IOMMU latency debugfs interface, which normally means root on the host with debugfs mounted. No tenant-facing path is described in the record.

What to do

Take the stable kernel fix from one of the linked git.kernel.org commits, or the equivalent backport from your distribution. Applying it means booting a new kernel, so each GPU host has to be cordoned, drained of running jobs and rebooted. No fixed release version is stated in the record. If the maintenance window is expensive, note that leaving the IOMMU latency debugfs facility unused avoids the code path entirely.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-68324 https://git.kernel.org/stable/c/0e28ca1c3204b51068579defc904a0dfba5e5c57 https://git.kernel.org/stable/c/3078d82e7fe9048a2b90a992e71af7cd7ef881fa

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.