Cloudanix VulnDB

CVE-2026-99256

None

CVSS

—

EPSS

0.2%

Published

Nov 3, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A locking error in Linux storage caching can cause system warnings or hiccups when administrators pause and restart cached devices.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
High
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The dm-cache target used an rw_semaphore for background_work_lock without ensuring the locking process matched the unlocking process, violating rw_semaphore owner semantics and triggering debug warnings or potential races during cache_resume after suspend operations.

Why it matters to the business

Linux systems relying on device-mapper caching may encounter kernel warnings, reduced stability, or operational disruptions during routine storage device management, increasing maintenance overhead in environments with heavy caching workloads.

How an attack unfolds

An attacker with local access or an administrator performs dmsetup suspend followed by dmsetup resume on a dm-cache device, exposing the owner mismatch in the rw_semaphore that was not designed to support cross-process unlock semantics.

How to fix it

Apply a kernel update that replaces the rw_semaphore background_work_lock implementation with a spinlock protected by a wait queue and migration counter.

How to confirm the fix worked

Confirm the updated kernel no longer emits DEBUG_RWSEMS warnings during dmsetup suspend/resume cycles on cache devices and that background work completion uses the new wait queue mechanism.

Typical attack path

  1. Locate a Linux system with dm-cache configured
  2. Execute dmsetup suspend on the cache device
  3. Execute dmsetup resume on the cache device
  4. Trigger kernel warning from rwsem_owner mismatch in cache_resume

How to detect it

Search kernel logs for DEBUG_RWSEMS_WARN_ON messages referencing rwsem_owner, cache_resume, or background_work_lock, and correlate with dmsetup suspend/resume activity on cache devices.

What your security team should do

  • Expedite kernel updates on all systems using dm-cache due to the recent publication
  • Audit logs for rwsem-related warnings in cache_resume paths
  • Validate storage management scripts and automation after patching

The record

In the Linux kernel, the following vulnerability has been resolved: dm cache: fix issue with background work locking dm cache used a rw_semaphore for background_work_lock. Write locks on rw_semaphores have strict owner semantics, but there was no guarantee that the process that locked background_work_lock was the same process that unlocked it. This can be easily seen using a kernel compiled with CONFIG_DEBUG_RWSEMS. Given a dm cache device <cache>, run: 'dmsetup suspend <cache> && dmsetup resume <cache>'. This will trigger a kernel warning: DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)) triggered by cache_resume(). To fix this, switch from a rw_semaphore to a spinlock and a wait queue. dm cache already has a wait queue and associated counter, migration_wait and nr_allocated_migrations, that was getting woken up when background work was getting completed, but wasn't actually used by anything. This is replaced by the background_work queue and counter.

Affected packages

Ecosystem Package Introduced Fixed