CVE-2025-38141

What it actually does

Use-after-free in dm_blk_report_zones when dm_get_live_table returns NULL or when md->zone_revalidate_map is accessed concurrently during blk_revalidate_disk_zones setup on suspended zoned DM devices, allowing a freed zone resource to be dereferenced.

Why it matters to the business

Systems using zoned device-mapper targets such as dm-crypt may experience kernel crashes, memory corruption, or local privilege escalation; the packages shipping the fix affect database operator deployments and require prompt kernel or package updates.

How an attack unfolds

An attacker with local access triggers concurrent calls to blk_revalidate_disk_zones and dm_blk_report_zones (for example via blkdev_report_zones_ioctl) on a suspended zoned DM device; if the revalidation fails, the freed resources are accessed by the reporting path, resulting in use-after-free.

How to fix it

Upgrade to a kernel containing commit f9c1bdf24615303d48a2d0fd629c88f3189563aa or later; for the listed operator packages update to version 25.2.1.0-r1 or newer; rebuild and reboot systems using affected DM configurations.

How to confirm the fix worked

Confirm the running kernel contains commit f9c1bdf24615303d48a2d0fd629c88f3189563aa; verify package versions match the fixed releases; test zoned DM device creation and zone reporting under load to ensure no crashes occur during table revalidation.

Typical attack path

1. Obtain local access on a system with zoned DM targets
2. Create or manipulate a zoned dm-crypt or similar table while the device is suspended
3. Race blk_revalidate_disk_zones with dm_blk_report_zones calls
4. Trigger failure path in revalidation to free resources still in use
5. Exploit the resulting use-after-free for memory corruption or code execution

How to detect it

Review kernel logs for oops or use-after-free warnings involving dm_blk_report_zones or zone_revalidate_map; inspect process activity around blkdev_report_zones_ioctl and blk_revalidate_disk_zones on systems with zoned DM devices; no widespread in-the-wild exploitation indicators are known.

What your security team should do

• Prioritize patching kernel and affected operator packages within the next maintenance window
• Identify hosts using zoned DM targets and schedule reboots after updates
• Monitor for any downstream dependents that consume the vulnerable kernel packages
• Add the fixed commit hash to internal vulnerability scanners