Look up another CVE · open CVE-2026-80962 in the interactive tracker
CVE-2026-80962
dm-pcache: validate geometry fields from on-disk cache_info
Published 2026-09-11 (37 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-80962 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
cache_segs_init() iterates cache_info->n_segs times indexing cache->segments[], which is sized to the cache device geometry, and get_seg_id() takes each segment id from the on-media cache_info and the per-segment next_seg link. Both come from cache device metadata that is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls them: an oversized n_segs or an out-of-range id drives an out-of-bounds access of cache->segments[] and a wild CACHE_DEV_SEGMENT() pointer into the device mapping -- an out-of-bounds read and write from on-disk data. Reject an n_segs that exceeds the device segment count and a segment id that is out of range before either is used. Valid metadata is unaffected.
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-pcache/cache.c
- What this is
- DEVICE-MAPPER PCACHE TARGETMAINTAINERS section matched on drivers/md/dm-pcache/ · dm-devel@lists.linux.dev · Maintained
Check it on the machine
grep -wE 'CONFIG_DM_PCACHE|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.
Show whether Debian builds this, per release
Debian does not build this code in 2 releases. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidn
- ?
- not established - no Makefile entry for the affected file
- n
- not enabled on any flavour - this release does not build the code
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_DM_PCACHE, 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-11 (37 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
- 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 | 6.18.50 | ab5dcde6fa96 |
| 6.18 | 7.2.4 | 3e19172089ec |
| 6.18 | 7.3 | 32d1809da310 |
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 OOB access is reached only through a local device-mapper table load on /dev/mapper/control (ctl_ioctl → table_load → populate_table → dm_pcache_ctr → pcache_start → pcache_cache_start → cache_segs_init/get_seg_id). No network, Bluetooth, or USB path feeds on-disk cache_info geometry.
- AC:LAttack complexity, low
- The attacker fully controls on-media cache_info.n_segs, cache_info.seg_id and each segment next_seg, and can forge a passing CRC because PCACHE_CRC_SEED (0x3B15A) is public, so a crafted INIT_DONE image with oversized n_segs or out-of-range ids hits the OOB on every table load with no race.
- PR:LPrivileges required, low
- ctl_ioctl gates DM_TABLE_LOAD with capable(CAP_SYS_ADMIN). In the most severe reasonable deployment that capability is held by a container or storage-stack administrator with delegated mapper and DAX/pmem nodes rather than exclusive host root, which kernel-CNA scoring of device-mapper table-load bugs maps to Low.
- UI:NUser interaction, none
- The attacker crafts the DAX cache-device metadata and issues DM_TABLE_LOAD themselves; no separate victim must mount a filesystem, open a file, or otherwise interact.
- S:UScope, unchanged
- Out-of-bounds indexing of cache->segments[] and wild CACHE_DEV_SEGMENT() pointers corrupt kernel memory on the same host that loaded the table. This stays within one kernel security authority and is not a VM escape or IOMMU bypass.
- C:HConfidentiality impact, high
- An out-of-range seg_id makes CACHE_DEV_SEGMENT() point past the DAX mapping into kernel memory, and cache_seg_meta_load() copy_mc_to_kernel's that region; oversized n_segs also reads past the kvalloc'd segments[] array. That kernel memory-corruption read primitive is Confidentiality High.
- I:HIntegrity impact, high
- cache_seg_init() writes pcache_cache_segment fields past the kvalloc'd cache->segments[] when n_segs exceeds seg_num, and a wild CACHE_DEV_SEGMENT() is later written through memcpy_flushcache/memset. That out-of-bounds kernel write is Integrity High and exploitable for code execution.
- A:HAvailability impact, high
- Heap overflow of cache->segments[] or dereference of a mapping-relative pointer past the DAX device causes a kernel oops or panic at table load, fully denying availability.