CVE-2026-80945

The Linux kernel's Intel Analytics Accelerator (IAA) crypto decompression driver mishandles the retry path taken when the IAA hardware reports an analytics error: it invokes the software fallback while the destination buffer (req->dst) is still mapped for DMA (DMA_FROM_DEVICE). If SWIOTLB bounce buffers are active, the later dma_unmap_sg() copies the stale bounce buffer over the output the CPU just wrote, silently corrupting the decompressed result — and per the CVSS 3.1 vector (network, no privileges, C:H/I:H), processing attacker-supplied compressed data can yield corrupted results and disclosure of stale bounce-buffer contents. Exposure is limited to Intel Xeon servers with IAA (4th-gen Sapphire Rapids and newer) where the iaa_crypto driver is actively used for decompression and SWIOTLB is enabled (e.g., encrypted-memory or restricted-DMA configurations). The fix unmaps the destination before the fallback runs: the async path unmaps inline, and the sync path signals -EAGAIN so iaa_comp_adecompress() reruns the fallback after unmapping. No public proof of concept or in-the-wild exploitation is known, and the flaw is not in the CISA KEV catalog.

What to do: Install a kernel containing the upstream fix (commit 'crypto: iaa - unmap dst before software fallback on decompress') once your distribution ships it, and treat any decompressed data produced by IAA on unpatched hosts as potentially corrupted. Check exposure with 'lsmod | grep iaa_crypto' and whether IAA devices under /sys/bus/dsa are bound and used for compression workloads, combined with whether SWIOTLB is forced (e.g., TDX/SEV or restricted-DMA setups). If unpatched and IAA decompression is in use, unload or blacklist the iaa_crypto module to fall back to software decompression until a fixed kernel is deployed.