CVE-2025-38140

What it actually does

In the Linux kernel device-mapper (dm) subsystem, dm_revalidate_zones() skips blk_revalidate_disk_zones() for already-zoned devices, allowing table swaps that change zoned settings or sizes on devices with zone write plugs; this leaves disk->conv_zones_bitmap and disk->nr_zones inconsistent, enabling out-of-bounds reads (for example in bdev_zone_is_seq()) or corruption of nr_zones values.

Why it matters to the business

Enterprises using zoned block devices (ZNS/SMR) with device-mapper targets that allocate zone write plug resources face risk of kernel memory corruption or crashes during table reloads, resulting in storage stack downtime, potential data unavailability, and the need for urgent kernel updates across fleets.

How an attack unfolds

An attacker who can trigger or control device-mapper table reloads (via udev, multipath, or privileged storage configuration) supplies a new table that alters zone emulation, device size, or zone size on a device already possessing zone write plug resources; the resulting bitmap or nr_zones mismatch is then dereferenced by zoned I/O paths, producing invalid memory access.

How to fix it

Upgrade the Linux kernel to a revision containing commit ac8acb0bfd98a1c65f3ca9a3e217a766124eebd8 or later; for packaged distributions apply the fixed kyverno-policy-reporter releases 3.1.4-r2 (Chainguard/Wolfi) or equivalent; restrict dm table reloads that alter zoned geometry on devices with zone write plugs until patched.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit; attempt a dm table reload that would change zoned settings on a device with zone write plugs and verify the operation is now rejected; inspect /sys/block/<dev>/queue/nr_zones and zoned attributes before and after any allowed reloads to ensure they remain consistent.

Typical attack path

1. Obtain privileges sufficient to reload a device-mapper table on a zoned device that uses zone write plugs
2. Issue a table swap that changes zoned parameters, device capacity, or zone size
3. Trigger zoned I/O or zone-status queries that invoke bdev_zone_is_seq() or similar helpers
4. Observe or exploit the resulting invalid memory read or kernel fault

How to detect it

Review kernel logs (dmesg, journalctl) for oops/panic messages referencing dm_revalidate_zones, blk_revalidate_disk_zones, conv_zones_bitmap, or bdev_zone_is_seq around the time of dm table reload events; correlate with audit logs showing dmsetup table loads or udev-triggered table swaps on zoned devices.

What your security team should do

• Prioritize kernel updates on all systems exposing zoned block devices through device-mapper
• Audit storage configurations for use of zone write plugs and limit table-swap privileges
• Monitor EPSS trend and kernel mailing list for any subsequent exploit reports
• Test patched kernels in staging environments that replicate zoned storage workloads before broad deployment