In the Linux kernel, the following vulnerability has been resolved:
crypto: iaa - unmap dst before software fallback on decompress
On a hardware analytics error, decompress retries through the software
fallback, which writes req->dst with the CPU while it is still mapped
DMA_FROM_DEVICE. With SWIOTLB active the later dma_unmap_sg() copies the
stale bounce buffer over req->dst, corrupting the result.
Unmap before the fallback runs. The async path unmaps inline; the sync
path signals the retry with -EAGAIN so iaa_comp_adecompress() runs the
fallback after unmapping.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
CVSS Score: 9.1
AV:N - iaa_crypto registers cra_name "deflate" at priority 300, so IPComp's crypto_alloc_acomp("deflate") selects deflate-iaa. Inbound packets reach iaa_comp_adecompress via xfrm_input → ipcomp_input → crypto_acomp_decompress, so a remote IPsec/IPComp peer can trigger the bug.
AC:L - The peer fully controls the compressed payload and can send non-IAA/invalid deflate that deterministically returns IAA_ANALYTICS_ERROR and takes the software fallback. SWIOTLB bounce, which makes dma_unmap_sg overwrite dest, is a normal IAA deployment (legacy/no-IOMMU or TDX), not an attacker-uncontrolled race.
PR:N - The IPComp receive path decompresses packets that match an installed SA with no local account or capability check. IAA workqueue and xfrm SA setup are deployment preconditions, not attacker privileges, matching other IPComp/IAA scores in this CNA.
UI:N - No victim action is required; attacker-sent IPComp packets automatically run hardware decompress, the analytics-error fallback, and the later dma_unmap_sg copy-back.
S:U - The stale bounce copy-back corrupts the request dest buffer inside this kernel (IPComp skb pages or zswap folios) and does not cross a VM, IOMMU, or other security-authority boundary.
C:H - On SWIOTLB unmap of a DMA_FROM_DEVICE dest, the bounce slot is copied over req->dst. Those slots retain leftover bytes from prior DMA (other zswap pages, packets, or devices), disclosing that data into the decompressed output at dest size (a page up to the IPComp scratch, tens of KB).
I:H - Software fallback first writes the correct plaintext, then dma_unmap_sg silently replaces it with bounce contents. The kernel then treats that leftover DMA data as the decompressed result, injecting it into the post-auth IPComp inner-packet path or into zswap-restored pages.
A:N - The fallback returns success and the defect is silent dest corruption; it does not oops, panic, hang, deadlock, or leak allocations, so there is no availability impact beyond the integrity loss.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
None |
AV:N - iaa_crypto registers cra_name "deflate" at priority 300, so IPComp's crypto_alloc_acomp("deflate") selects deflate-iaa. Inbound packets reach iaa_comp_adecompress via xfrm_input → ipcomp_input → crypto_acomp_decompress, so a remote IPsec/IPComp peer can trigger the bug.
AC:L - The peer fully controls the compressed payload and can send non-IAA/invalid deflate that deterministically returns IAA_ANALYTICS_ERROR and takes the software fallback. SWIOTLB bounce, which makes dma_unmap_sg overwrite dest, is a normal IAA deployment (legacy/no-IOMMU or TDX), not an attacker-uncontrolled race.
PR:N - The IPComp receive path decompresses packets that match an installed SA with no local account or capability check. IAA workqueue and xfrm SA setup are deployment preconditions, not attacker privileges, matching other IPComp/IAA scores in this CNA.
UI:N - No victim action is required; attacker-sent IPComp packets automatically run hardware decompress, the analytics-error fallback, and the later dma_unmap_sg copy-back.
S:U - The stale bounce copy-back corrupts the request dest buffer inside this kernel (IPComp skb pages or zswap folios) and does not cross a VM, IOMMU, or other security-authority boundary.
C:H - On SWIOTLB unmap of a DMA_FROM_DEVICE dest, the bounce slot is copied over req->dst. Those slots retain leftover bytes from prior DMA (other zswap pages, packets, or devices), disclosing that data into the decompressed output at dest size (a page up to the IPComp scratch, tens of KB).
I:H - Software fallback first writes the correct plaintext, then dma_unmap_sg silently replaces it with bounce contents. The kernel then treats that leftover DMA data as the decompressed result, injecting it into the post-auth IPComp inner-packet path or into zswap-restored pages.
A:N - The fallback returns success and the defect is silent dest corruption; it does not oops, panic, hang, deadlock, or leak allocations, so there is no availability impact beyond the integrity loss.
CVSS 3.1