UBUNTU-CVE-2026-99256: Medium severity ubuntu/linux vulnerability
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix issue with background work locking dm cache used a rwsemaphore for backgroundworklock. Write locks on rwsemaphores have strict owner semantics, but there was no guarantee that the process that locked backgroundworklock was the same process that unlocked it. This can be easily seen using a kernel compiled with CONFIGDEBUGRWSEMS. Given a dm cache device <cache>, run: 'dmsetup suspend <cache> && dmsetup resume <cache>'. This will trigger a kernel warning: DEBUGRWSEMSWARNON((rwsemowner(sem) != current) && !rwsemtestoflags(sem, RWSEMNONSPINNABLE)) triggered by cacheresume(). To fix this, switch from a rwsemaphore to a spinlock and a wait queue. dm cache already has a wait queue and associated counter, migrationwait and nrallocatedmigrations, that was getting woken up when background work was getting completed, but wasn't actually used by anything. This is replaced by the backgroundwork queue and counter.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Operational
For the dm cache device <cache>, run: `dmsetup suspend <cache> && dmsetup resume <cache>`.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the listed Ubuntu Linux kernel packages are in scope when they use the device-mapper cache (dm-cache) subsystem. The affected package families listed are linux, linux-fips, linux-aws, linux-azure, linux-gcp, linux-oracle, linux-aws-fips, and linux-azure-fips.
What action can trigger the problem?
Suspending and then resuming a dm-cache device can trigger the locking warning. The described reproduction uses dmsetup suspend <cache> followed by dmsetup resume <cache>.
How can administrators check for evidence of the issue?
A kernel built with CONFIG_DEBUG_RWSEMS can report a DEBUG_RWSEMS_WARN_ON warning during cache_resume() after a dm-cache device is suspended and resumed. The warning indicates that the rw_semaphore lock owner differs from the task performing the unlock.