Cloudanix VulnDB

CVE-2026-99036

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing issue in the Linux kernel's storage device handling could let a highly privileged user accidentally read already-freed memory, though everyday management tools avoid the problem.

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

What it actually does

Race condition in Linux kernel device-mapper do_resume path allows dm_table_get_mode to dereference a new_map pointer after a concurrent ioctl has swapped the table, resulting in a read of freed memory.

Why it matters to the business

Kernel memory corruption or crashes possible on systems performing direct low-level device-mapper ioctls under root; normal management tools and LVM/cryptsetup usage are unaffected, limiting operational risk.

How an attack unfolds

A local root user issues concurrent DM ioctls on the same device to win the race between dm_swap_table and the subsequent dm_table_get_mode call, reading freed table memory.

How to fix it

Apply the upstream kernel patch that reads the table mode before dm_swap_table; rebuild and reboot with the fixed kernel. No configuration changes are required for common device-mapper consumers.

How to confirm the fix worked

Confirm the patch is present by inspecting the do_resume function in drivers/md/dm-ioctl.c for the reordered mode read; run syzkaller or similar concurrency tests against the DM device to verify the race is closed.

Typical attack path

  1. Obtain root privileges on the target system
  2. Open the same DM device from multiple processes
  3. Issue overlapping resume and table-swap ioctls to trigger the window
  4. Read from the now-freed table memory

How to detect it

Review kernel logs for use-after-free warnings or crashes in dm_ioctl paths; correlate with audit logs showing multiple concurrent DM ioctls from the same UID on a single device.

What your security team should do

  • Prioritize patching kernel packages on any system exposing raw DM ioctls to untrusted root users
  • Audit custom scripts or tools that perform concurrent DM operations
  • Monitor kernel changelog for backports to distribution kernels
  • No immediate action needed for standard LVM or cryptsetup deployments

The record

In the Linux kernel, the following vulnerability has been resolved: dm: fix reading free memory in do_resume When do_resume calls dm_table_get_mode(new_map), the call is done without holding any locks (it only holds a reference to the md). It may be possible that another concurrent ioctl on the same device will swap table after dm_swap_table and before dm_table_get_mode. In this case, dm_table_get_mode(new_map) reads freed memory. This race condition was triggered by syzbot. This commit fixes the race by reading mode of the new table before dm_swap_table. Note that new_map is also passed to dm_ima_need_measure, but this function doesn't attempt to dereference it, so this call should be safe. Note that this is not a security bug because only root can trigger it and the commonly used tools such as lvm or cryptsetup do not call the ioctls concurrently, so that they can't trigger it acceidentally.

Affected packages

Ecosystem Package Introduced Fixed