Look up another CVE · open CVE-2026-90069 in the interactive tracker
CVE-2026-90069
crypto: acomp - allocate async request context when cloning
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem crypto. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90069 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
ACOMP_REQUEST_ON_STACK() reserves only enough storage for the synchronous fallback. When an async implementation is selected, callers clone that stack request before retrying, but acomp_request_clone() currently copies only the stack-sized object. The clone therefore has no storage for the async provider request context, and providers such as QAT write past the allocation through acomp_request_ctx(). KASAN does report a slab OOB write. Allocate a zeroed clone large enough for the runtime acomp request size, copy only the bytes present in the source object, and preserve the existing fallback-on-allocation-failure behavior. Use the runtime reqsize because an implementation may adjust it during tfm initialization.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
crypto/acompress.c
- What this is
- CRYPTO APIMAINTAINERS section matched on crypto/ · linux-crypto@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_CRYPTO_ACOMP2 /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_CRYPTO_ACOMP2
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 6.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- crypto
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.16 | 6.18.52 | d48197cbd5d3 |
| 6.16 | 7.2.6 | 889fa17a0af0 |
| 6.16 | 7.3 | ee440d4fc0d2 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The undersized clone is produced only by ACOMP_REQUEST_CLONE in ubifs_compress_common()/ubifs_decompress_common(), reached from local VFS writeback (write/fsync → ubifs_writepage → do_writepage → ubifs_jnl_write_data → ubifs_compress_folio) or read (ubifs_read_folio → read_block → ubifs_decompress_folio). IPComp uses acomp_request_alloc_extra() and never clones, so no protocol message carries this bug.
- AC:LAttack complexity, low
- When UBIFS's compressor tfm is async, crypto_acomp_compress()/crypto_acomp_decompress() return -EAGAIN for every ACOMP_REQUEST_ON_STACK request, and the following ACOMP_REQUEST_CLONE plus QAT qat_comp_alg_compress_decompress() write through acomp_request_ctx() always overflows the kmemdup; there is no race or uninfluenced layout to win.
- PR:LPrivileges required, low
- An unprivileged user with write permission on a UBIFS inode that inherited UBIFS_COMPR_FL triggers the clone by writing ≥ UBIFS_MIN_COMPR_LEN bytes and fsync(); ubifs_fs_type has no FS_USERNS_MOUNT, but an already-mounted volume needs no capability beyond ordinary file write access.
- UI:NUser interaction, none
- The attacker creates and writes their own file on the mounted UBIFS volume and forces writeback with fsync() into ubifs_jnl_write_data(); no other user must mount an image or open a file.
- S:UScope, unchanged
- qat_comp_alg_compress_decompress() writes struct qat_compression_req through acomp_request_ctx() into kernel slab adjacent to the clone; the corruption stays in kernel memory and does not cross a VM, IOMMU, or guest/host boundary.
- C:HConfidentiality impact, high
- The entire qat_compression_req (firmware request, DMA buffer pointers, qat_compression_ctx * and acomp_req *) is stored past the kmemdup of sizeof(struct acomp_req), so qat_comp_generic_callback() later reads those fields from neighboring slab objects, giving an arbitrary kernel read after heap grooming.
- I:HIntegrity impact, high
- qat_comp_alg_compress_decompress() performs a slab out-of-bounds write of sizeof(struct qat_compression_req) via acomp_request_ctx() on the clone, overwriting adjacent heap objects including function pointers and providing a control-flow hijack and arbitrary-write primitive.
- A:HAvailability impact, high
- KASAN reports a slab out-of-bounds write through acomp_request_ctx() on the undersized clone, and overflowing qat_compression_req into the next slab object oopses or panics on the QAT callback or allocator integrity check.