Look up another CVE · open CVE-2026-53062 in the interactive tracker
CVE-2026-53062
dm cache policy smq: fix missing locks in invalidating cache blocks
Published 2026-06-24 (4 months ago) by the Linux kernel CNA. Subsystem drivers/md. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-53062 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 | fixedDLA-4665-1 · 2026-07-03 · text | 6.1.176-1 | Update the kernel and reboot. DLA-4665-1 shipped the fix on 2026-07-03, in 6.1.176-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.94-1 | Update the kernel and reboot. Fixed in 6.12.94-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
In passthrough mode, the policy invalidate_mapping operation is called simultaneously from multiple workers, thus it should be protected by a lock. Otherwise, we might end up with data races on the allocated blocks counter, or even use-after-free issues with internal data structures when doing concurrent writes. Note that the existing FIXME in smq_invalidate_mapping() doesn't affect passthrough mode since migration tasks don't exist there, but would need attention if supporting fast device shrinking via suspend/resume without target reloading. Reproduce steps: 1. Create a cache device consisting of 1024 cache entries dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 262144 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Populate the cache, and record the number of cached blocks fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --size=64m --direct=1 nr_cached=$(dmsetup status cache | awk '{split($7, a, "/"); print a[1]}') 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 262144 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the passthrough cache. By setting multiple jobs with I/O size equal to the cache block size, cache blocks are invalidated concurrently from different workers. fio --filename=/dev/mapper/cache --name=test --rw=randwrite --bs=64k \ --direct=1 --numjobs=2 --randrepeat=0 --size=64m 5. Check if demoted matches cached block count. These numbers should match but may differ due to the data race. nr_demoted=$(dmsetup status cache | awk '{print $12}') echo "$nr_cached, $nr_demoted"
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-cache-policy-smq.c
- What this is
- DEVICE-MAPPER (LVM)MAINTAINERS section matched on drivers/md/dm* · dm-devel@lists.linux.dev · Maintained
- Kernel module
- dm_cache_smq
Check it on the machine
grep -wE 'CONFIG_DM_CACHE_SMQ|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_cache_smqPrints 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_CACHE_SMQ, 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-06-24 (4 months 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.10%, higher than 0.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- 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 |
|---|---|---|
| 4.12 | 5.10.258 | 4991b5a08751 |
| 4.12 | 5.15.209 | 1b2bec4a7dcf |
| 4.12 | 6.1.175 | 9a5fdfb9e57e |
| 4.12 | 6.6.141 | ac5ee9944389 |
| 4.12 | 6.12.91 | 93627a29d4b6 |
| 4.12 | 6.18.33 | c348ae47d8e6 |
| 4.12 | 7.0.10 | 2b62d0611c9a |
| 4.12 | 7.1 | 2d1f7b65f5de |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4671-1 | 2026-07-05 | bullseye 6.1.176-1~deb11u1 | tracker |
| DLA-4665-1 | 2026-07-03 | bookworm 6.1.176-1 | tracker |
| DLA-4664-1 | 2026-07-03 | bullseye 5.10.259-1 | tracker |
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 vulnerable path is reached through local block I/O to an existing dm-cache mapped device, such as writes from a mounted filesystem or direct writes to the block device. It is not reachable through a network packet path.
- AC:LAttack complexity, low
- Once the dm-cache target is in passthrough mode with clean cached mappings, the attacker can trigger the race by issuing concurrent writes and controls both racing sides. No uncontrollable timing condition beyond ordinary concurrent I/O is required.
- PR:LPrivileges required, low
- Creating or reloading the dm-cache target requires CAP_SYS_ADMIN, but in a reasonable deployed scenario an unprivileged local user with write access to a filesystem backed by the existing target can submit the writes that reach the vulnerable code. Device-mapper control ioctls are not reachable through unprivileged user namespaces.
- UI:NUser interaction, none
- The attacker only needs to issue local writes; no separate victim action is required.
- S:UScope, unchanged
- The corruption occurs inside the same kernel and block-device security authority. This is not a VM escape, IOMMU bypass, or cross-scope boundary violation.
- C:HConfidentiality impact, high
- The missing locking can produce use-after-free style reuse and corruption of SMQ internal mapping structures. Following the higher-severity rule for kernel memory corruption, this is treated as capable of enabling high-impact information disclosure.
- I:HIntegrity impact, high
- The race can corrupt cache policy queues/hash tables and freed/reused mapping entries, affecting kernel control/data structures and potentially cache block mapping integrity. This is memory corruption/use-after-free class behavior, so high integrity impact is defensible.
- A:HAvailability impact, high
- The race can trigger double-free/allocation checks, corrupted queues/hash state, NULL-deref-adjacent failures in the same passthrough write path, or kernel oops/panic. Repeated concurrent writes can therefore cause high availability impact.