GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux crypto iaa: DMA buffer not unmapped before software fallback corrupts decompressed data

UnscoredCVE-2026-80945Kernel, userspace & hypervisorcurated

Impact

On a hardware analytics error the IAA driver retries decompression in software while req->dst is still mapped DMA_FROM_DEVICE. With SWIOTLB active, the later dma_unmap_sg() copies the stale bounce buffer over the freshly written destination, so the caller silently receives corrupted output. Where IAA backs zswap or another in-kernel compression consumer, that is silent data corruption of pages in flight rather than an attacker-controlled primitive. Nodes affected are those with Intel IAA enabled and SWIOTLB in use; GPU hosts often run with an IOMMU/bounce-buffer configuration that makes the path reachable.

Who can reach it

Local, and not directly attacker-driven: the corruption requires a hardware analytics error on an IAA descriptor plus SWIOTLB bouncing. Any workload whose pages go through an IAA-backed compression path can be the victim; no authentication boundary is crossed.

What to do

Apply the stable kernel update containing the fix and reboot the node. As an interim mitigation on nodes where corruption risk is unacceptable, disable the IAA crypto driver (and any zswap backend using it) so compression falls back to software, which does not require a reboot on all setups but does require draining the workloads using it.

References

Related entries

All Kernel, userspace & hypervisor entries

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.