CVE-2024-35805

What it actually does

A loop in dm_exception_table_exit that frees snapshot exceptions lacks a cond_resched call, allowing a long-running operation with many exceptions to monopolize the CPU and cause a lockup.

Why it matters to the business

Systems using device-mapper snapshots may become unresponsive or hang during snapshot teardown, disrupting storage operations and requiring manual intervention or reboot.

How an attack unfolds

An attacker with local access creates or manipulates a snapshot containing a large number of exceptions, then triggers exit of the snapshot table; the kernel loop runs without yielding and locks up the system. No named threat actors are associated with exploitation of this issue.

How to fix it

Update the Linux kernel to a version containing commit e7d4cff57c3c43fdd72342c78d4138f509c7416e or later; for cilium-envoy-1.15 (Chainguard) upgrade to 1.15.15-r0 or newer.

How to confirm the fix worked

Confirm the running kernel contains the cond_resched addition in dm_exception_table_exit; test snapshot creation and deletion with high exception counts to verify absence of lockup.

Typical attack path

1. Obtain local user or process access on a Linux system using device-mapper snapshots
2. Create or expand a snapshot to accumulate a large number of exceptions
3. Trigger dm_exception_table_exit by deleting or deactivating the snapshot
4. Observe system lockup due to non-preemptible loop

How to detect it

Look in kernel logs for messages around snapshot teardown or device-mapper activity preceding a system hang; no specific post-exploitation artifacts are known.

What your security team should do

• Prioritize kernel updates on systems that use device-mapper snapshots
• Review snapshot usage patterns and limit exception counts where possible
• Monitor for kernel updates in stable trees and apply within normal change windows