Look up another CVE · open CVE-2026-90052 in the interactive tracker
CVE-2026-90052
dm-integrity: fix buffer overflow with keyed discard
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/md. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90052 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 | not affected | 7.2.11-1 | Nothing to do. forky never shipped the vulnerable code. |
| Debian unstablesid | not affected | 7.2.11-1 | Nothing to do. sid never shipped the vulnerable code. |
The vulnerability
What the bug is
Since commit 68c5c42567bc ("dm-integrity: replace forgeable discard filler with a keyed sector marker"), integrity_metadata computes a checksum for every discarded block into the "checksums" buffer. integrity_sector_checksum always writes the whole digest. So if the tag size is smaller than the digest size, the checksum of the last block that fits into the buffer is written past the end of it. For example, with hmac(sha256) and tag size 16, a 4MiB discard writes 16 bytes past the kmalloc'ed page. Fix this by subtracting extra_space from the buffer size when computing max_blocks, like we do for writes.
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.
drivers/md/dm-integrity.c
- What this is
- DEVICE-MAPPER (LVM)MAINTAINERS section matched on drivers/md/dm* · dm-devel@lists.linux.dev · Maintained
- Kernel module
- dm_integrity
Check it on the machine
grep -wE 'CONFIG_DM_INTEGRITY|CONFIG_MD' /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.
lsmod | grep -w dm_integrityPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switches
- CONFIG_DM_INTEGRITY, CONFIG_MD
- Reads as
- all on means the file is compiled; any one off means it is not.
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.19%, higher than 7.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/md
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.18.52 | 6.18.52 | 9988c1c9e0d1 |
| 7.2.6 | 7.2.6 | dd08a645195f |
| 7.3 | 7.3 | 59e6f919d77d |
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 overflow is triggered by a REQ_OP_DISCARD bio entering dm_integrity_map() → dm_integrity_map_continue() → integrity_metadata(). That bio is built by blk_ioctl_discard()/blkdev_issue_discard() from ioctl(BLKDISCARD) or by a filesystem discard; the discard LBA range is a local block operation, not a field parsed from a remote protocol message.
- AC:LAttack complexity, low
- With allow_discards_keyed and tag_size < internal_hash_digestsize, a discard of max_blocks (PAGE_SIZE/tag_size) blocks makes integrity_discard_fill_tags() call integrity_discard_checksum() so crypto_shash_final()/crypto_ahash_digest() store the full digest at checksums+i*tag_size, deterministically writing extra_space bytes past the kmalloc(PAGE_SIZE) buffer. No race is required.
- PR:LPrivileges required, low
- Loading the integrity table needs ctl_ioctl()'s capable(CAP_SYS_ADMIN), but that is only the deployment of allow_discards_keyed. blk_ioctl_discard() has no capable() check, only a write-open fd, and an unprivileged user can generate REQ_OP_DISCARD via fallocate/unlink on a discard-enabled filesystem (f2fs default_options() sets DISCARD when the mapped device advertises it).
- UI:NUser interaction, none
- The attacker issues BLKDISCARD or hole-punches/unlinks their own file on the already-mapped volume; integrity_metadata() then runs on that bio. No separate victim must mount attacker-supplied media or open a file.
- S:UScope, unchanged
- integrity_discard_fill_tags() overruns a kmalloc checksums buffer in the host kernel's dm-integrity I/O path. That is in-kernel heap corruption under the same OS authority, not a VM, IOMMU, or sandbox escape.
- C:HConfidentiality impact, high
- integrity_sector_checksum_shash()/ahash write a full HMAC digest (32 bytes for hmac(sha256)) into a tag_size-strided buffer, overflowing extra_space bytes (16 with a 16-byte tag) into the next kmalloc-4k/page. That heap overflow can corrupt adjacent objects and be turned into a kernel read primitive.
- I:HIntegrity impact, high
- The same out-of-bounds write from crypto_shash_final() past the PAGE_SIZE checksums allocation in the keyed-discard loop corrupts adjacent kernel heap/page contents, giving an exploitable write primitive for control-flow hijack rather than a tag-only on-disk change.
- A:HAvailability impact, high
- Overwriting the extra_space bytes after the kmalloc(PAGE_SIZE) checksums buffer in integrity_discard_fill_tags() corrupts the following kernel page or slab object, which can oops/panic immediately or when the smashed object is later used.