Look up another CVE · open CVE-2026-80959 in the interactive tracker
CVE-2026-80959
dm-pcache: bound the persisted tail-position offset
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-80959 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_pos_decode() takes the persisted key_tail and dirty_tail seg_off from the cache device and addresses within the segment with it. A seg_off at or past the segment data_size, controllable by whoever supplies the device (CAP_SYS_ADMIN), reads past the segment data. Reject a decoded seg_off that is not below the segment data_size.
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 | ffd9a214a94f |
| 6.18 | 7.2.4 | 8bf7a06ca3c1 |
| 6.18 | 7.3 | d1898576090a |
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 unbounded tail offset is consumed only when a local caller loads a dm-pcache table (ctl_ioctl → table_load → dm_pcache_ctr → pcache_cache_start → cache_tail_init → cache_pos_decode) from a supplied DAX cache device; no network, Bluetooth, or USB receive path parses this metadata.
- AC:LAttack complexity, low
- The attacker fully controls the cache device and can forge key_tail/dirty_tail pos_onmedia with a valid CRC (public PCACHE_CRC_SEED), so cache_pos_decode() deterministically accepts an out-of-range seg_off; no race or uninfluenced victim state is required.
- PR:LPrivileges required, low
- dm-ioctl.c gates table load with capable(CAP_SYS_ADMIN); kernel-CNA scoring treats that delegated capability (privileged containers, LVM/storage helpers) as Low rather than exclusive init-namespace root, and the attacker supplies the cache/backing devices on the pcache table.
- UI:NUser interaction, none
- The attacker performs every step itself: craft the persisted tail positions on a DAX cache device and issue DM_TABLE_LOAD for a pcache target; no other user must mount media, open files, or otherwise interact.
- S:UScope, unchanged
- The out-of-bounds pmem/kernel access and resulting oops stay inside the host kernel device-mapper/pcache mapping; this is not a VM escape, IOMMU bypass, or other cross-authority boundary.
- C:HConfidentiality impact, high
- cache_replay(), writeback and GC copy ksets via copy_mc_to_kernel from cache_pos_addr() (segment.data plus the attacker-controlled u32 seg_off) for up to PCACHE_KSET_ONMEDIA_SIZE_MAX bytes, an unbounded over-read past segment data into later pmem or adjacent kernel VA, not a few-byte leak.
- I:HIntegrity impact, high
- A seg_off at data_size makes append_last_kset() memcpy_flushcache a kset into the next 16MiB segment's control metadata; a larger seg_off underflows u32 cache_seg_remain() so later key-head writes become arbitrary-offset stores through the DAX mapping, an out-of-bounds write primitive.
- A:HAvailability impact, high
- cache_pos_advance() hits BUG_ON(cache_seg_remain(pos) < len) when a tail sits at data_size, and a huge seg_off makes copy_mc_to_kernel/memcpy_flushcache walk off the DAX mapping into unmapped kernel VA, oopsing or panicking the host.