CVE-2026-80945

What it actually does

The Linux kernel IAA (Intel In-Memory Analytics Accelerator) crypto decompress path leaves the destination buffer mapped DMA_FROM_DEVICE when a hardware analytics error forces a software fallback. The CPU then writes decompressed data into that still-mapped buffer; with SWIOTLB active, the later dma_unmap_sg() copies a stale bounce buffer over the result. This is kernel memory/data corruption of the decompress destination: integrity of the output is destroyed, and leftover bounce-buffer contents can be disclosed into the result. Confidentiality and integrity of decompressed data are affected; availability is not.

Why it matters to the business

Systems that offload decompression to Intel IAA on Linux can silently return wrong or leaked data after a hardware decompress error, which can poison analytics, storage, backup, and crypto-offload pipelines and undermine trust in decompressed content. Impact is concentrated on Intel platforms (and VMs) where the IAA crypto driver and SWIOTLB are in use. There is no CISA KEV listing, no ransomware association, exploit maturity is none, and EPSS is low and flat (~0.52% over 30 days), so mass exploitation is unlikely; the 9.1 network-scored kernel memory-corruption rating and ~20-day-old publication still justify prompt patching of IAA-enabled hosts.

How an attack unfolds

An attacker who can submit decompress work to the IAA crypto driver—locally via the kernel crypto API, or indirectly if a network-facing service offloads decompression to IAA—triggers a hardware analytics error on decompress. The driver retries in software while the destination remains DMA-mapped. On SWIOTLB systems the subsequent unmap overwrites the CPU-written result with stale bounce-buffer data, yielding corrupted or leaked contents in the decompressed output. Abuse is integrity tampering of decompressed payloads and/or disclosure of residual DMA bounce-buffer memory. No public exploit, named threat actors, or in-the-wild campaigns are known; practical reach depends on IAA hardware, SWIOTLB, and a path that can induce the hardware-error fallback.

How to fix it

Install a Linux kernel that includes the IAA crypto fix unmapping the destination before the software decompress fallback (async path unmaps inline; sync path returns -EAGAIN so iaa_comp_adecompress() runs the fallback after unmap). Use the distro or vendor kernel that backported “crypto: iaa - unmap dst before software fallback on decompress”; specific package versions were not supplied with this record. If you cannot patch immediately, disable IAA crypto offload (unload/blacklist the IAA crypto module or stop routing compression to IAA) so decompress does not hit the broken DMA-unmap order. Do not rely on SWIOTLB configuration changes alone as a complete fix.

How to confirm the fix worked

Confirm the running kernel changelog or distro advisory includes the IAA unmap-before-fallback decompress fix. Verify whether the IAA crypto driver is loaded and whether SWIOTLB is active. After patching, on a test system with IAA, force a hardware decompress error/fallback and confirm the destination matches a pure-software decompress and is not clobbered after DMA unmap. Check kernel config for IAA crypto support (e.g. CRYPTO_DEV_IAA_CRYPTO) and that production hosts no longer run an unfixed IAA decompress path.

Typical attack path

1. Locate Linux hosts using the IAA crypto decompress offload with SWIOTLB (Intel IAA/idxd platforms and many virtualized DMA configurations).
2. Obtain a way to submit IAA decompress requests (local crypto/compression API use, or a service that offloads decompression to IAA).
3. Cause a hardware analytics error on decompress so the software fallback path runs while the destination buffer is still mapped DMA_FROM_DEVICE.
4. Allow dma_unmap_sg() under SWIOTLB to copy the stale bounce buffer over the CPU-written fallback result.
5. Use the corrupted or leaked decompressed output to break data integrity or recover residual bounce-buffer contents.

How to detect it

This defect is silent data corruption, not a reliable crash or malware drop, so confirming prior exploitation is difficult. Review kernel logs (dmesg, journald) for IAA/idxd/crypto hardware analytics or decompress errors and software-fallback retries around the time of suspected bad output; correlate with SWIOTLB activity. Compare decompressed artifacts against known-good hashes or a software-only decompress of the same input. Hunt unexplained integrity failures in data that flowed through kernel IAA decompression after the publication date. No public exploit signatures, file artifacts, or named-actor TTPs are associated with this issue; absence of those logs does not prove the path was unused.

What your security team should do

• Inventory Linux systems with Intel IAA/idxd crypto or compression offload and SWIOTLB and treat those as the patch scope.
• Deploy a kernel containing the IAA destination-unmap-before-software-fallback fix as the primary control.
• If patching is delayed, disable IAA crypto/compression offload so the vulnerable fallback path cannot run.
• Watch for IAA/idxd/crypto hardware decompress errors and unexplained integrity failures of data that passed through kernel IAA decompression.
• There is no KEV deadline or known ransomware use; still prioritize IAA-enabled production decompress paths because this is kernel memory corruption with a high CVSS rating.