Cloudanix VulnDB

CVE-2025-38066

None

CVSS

—

EPSS

0.2%

Published

Jun 18, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A problem in the Linux kernel's disk caching mechanism can crash the entire system if a cache device fails to start and an attempt is made to start it again.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
High
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A flaw in the dm-cache target allows a partially initialized policy object to remain after an initial resume failure caused by mapping errors; subsequent resume attempts reload mappings into the incomplete object and trigger a BUG_ON in smq_load_mapping.

Why it matters to the business

Systems using dm-cache on Linux kernels can experience unexpected kernel crashes and reboots when cache devices encounter resume failures, resulting in service disruption and potential data unavailability; the issue affects widely deployed kernels across distributions.

How an attack unfolds

An attacker with local access crafts or corrupts cache metadata to cause a resume failure, then issues a second resume operation against the same device; the retry path hits the incomplete policy object and crashes the kernel via BUG_ON.

How to fix it

Upgrade to a kernel containing commit c614584c2a66b538f469089ac089457a34590c14 or apply the fixed package kernel-linus 4.1.15-2.mga5; disable dm-cache devices that previously failed resume until patched.

How to confirm the fix worked

Confirm the running kernel contains commit c614584c2a66b538f469089ac089457a34590c14 or later; attempt a controlled resume failure scenario in a test environment and verify no BUG_ON occurs on retry.

Typical attack path

  1. Create cache metadata with 512+ blocks containing mappings in the first array block
  2. Corrupt the second array block of the mapping array to induce a mapping error
  3. Load and attempt to resume the cache device, causing the initial resume to fail
  4. Issue a second resume on the same device to trigger BUG_ON in the policy loader

How to detect it

Search kernel logs and dmesg for oops messages referencing drivers/md/dm-cache-policy-smq.c:752 and the function smq_load_mapping; correlate with dmsetup resume operations on cache devices around the same timestamp.

  • kernel BUG at drivers/md/dm-cache-policy-smq.c:752
  • smq_load_mapping+0x3e5/0x570
  • Oops: invalid opcode: 0000
  • dmsetup resume cache

What your security team should do

  • Prioritize kernel upgrades on all systems exposing dm-cache devices
  • Audit dmsetup and udev configurations for cache targets and remove any devices that previously failed resume
  • Enable kernel panic-on-oops logging and monitoring for smq_load_mapping crashes
  • Restrict unprivileged access to dmsetup and device-mapper ioctls until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: dm cache: prevent BUG_ON by blocking retries on failed device resumes A cache device failing to resume due to mapping errors should not be retried, as the failure leaves a partially initialized policy object. Repeating the resume operation risks triggering BUG_ON when reloading cache mappings into the incomplete policy object. Reproduce steps: 1. create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata. cat <<EOF >> cmeta.xml <superblock uuid="" block_size="128" nr_cache_blocks="512" \ policy="smq" hint_width="4"> <mappings> <mapping cache_block="0" origin_block="0" dirty="false"/> </mappings> </superblock> EOF dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta 2. wipe the second array block of the mapping array to simulate data degradations. mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. try bringing up the cache device. The resume is expected to fail due to the broken array block. dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dmsetup create cache --notable dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup resume cache 4. try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings. dmsetup resume cache Kernel logs: (snip) ------------[ cut here ]------------ kernel BUG at drivers/md/dm-cache-policy-smq.c:752! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570 Fix by disallowing resume operations for devices that failed the initial attempt.

Affected packages

Ecosystem Package Introduced Fixed
Debian:11 linux 0 No fix
Debian:12 linux 0 No fix
Debian:13 linux 0 6.12.32-1
Debian:14 linux 0 6.12.32-1
Linux Kernel 0 5.4.294
Linux Kernel 4.2.0 5.4.294

Related vulnerabilities