Cloudanix VulnDB

CVE-2026-93198

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux storage caching could let specially crafted disk data freeze part of the system until the machine is restarted.

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

What it actually does

Allows a denial-of-service via an infinite loop in the dm-pcache writeback worker when a crafted cache image provides a non-terminating dirty_tail chain decoded from on-media fields protected only by crc32c.

Why it matters to the business

Can cause system hangs, high CPU usage, or resource exhaustion in Linux environments using dm-pcache for persistent caching, leading to storage subsystem downtime.

How an attack unfolds

An attacker prepares a malicious dm-pcache image whose dirty_tail field points to a non-terminating chain of ksets; when the device-mapper table is loaded the writeback worker follows the chain indefinitely and re-arms itself with zero delay.

How to fix it

Upgrade the Linux kernel to a version containing the dm-pcache dirty_tail chain validation performed at table load with the same hop cap used by cache_replay().

How to confirm the fix worked

Confirm the running kernel performs a bounded walk of the dirty_tail chain at load and rejects tables that exceed the hop limit with -EIO; test with crafted images in an isolated environment.

Typical attack path

  1. Craft a dm-pcache image with a dirty_tail chain that never reaches an end marker within the hop limit
  2. Place the image on a cache device and load the dm-pcache target
  3. Allow the cache_writeback_fn worker to run
  4. Observe the worker re-arming forever without progress

How to detect it

Inspect kernel logs for repeated dm-pcache writeback activity without completion; watch for cache_writeback_fn running continuously with no I/O progress; correlate with table-load events for dm-pcache devices.

What your security team should do

  • Apply the kernel fix that adds dirty_tail validation at load time
  • Restrict loading of dm-pcache devices to trusted images only
  • Monitor kernel logs and writeback worker CPU usage for signs of stalled progress

The record

In the Linux kernel, the following vulnerability has been resolved: dm-pcache: validate the persisted dirty_tail chain at load The writeback worker follows the persisted dirty_tail chain, which is decoded from the cache device independently of the key_tail chain that cache_replay() walks and bounds. A crafted image, whose on-media fields are authenticated only by a crc32c with a fixed seed, can aim dirty_tail at a chain of last ksets that never terminates, so cache_writeback_fn() re-arms itself with no delay forever. Walk the dirty_tail chain once at load with the same hop cap cache_replay() uses and fail the table load with -EIO if it does not reach an end within n_segs hops.

Affected packages

Ecosystem Package Introduced Fixed