CVE-2025-38141

In the Linux kernel, the following vulnerability has been resolved:

dm: fix dmblkreport_zones

If dmgetlivetable() returned NULL, dmputlivetable() was never called. Also, it is possible that md->zonerevalidatemap will change while calling this function. Only read it once, so that we are always using the same value. Otherwise we might miss a call to dmputlive_table().

Finally, while md->zonerevalidatemap is set and a process is calling blkrevalidatediskzones() to set up the zone append emulation resources, it is possible that another process, perhaps triggered by blkdevreportzonesioctl(), will call dmblkreportzones(). If blkrevalidatediskzones() fails, these resources can be freed while the other process is still using them, causing a use-after-free error.

blkrevalidatediskzones() will only ever be called when initially setting up the zone append emulation resources, such as when setting up a zoned dm-crypt table for the first time. Further table swaps will not set md->zonerevalidatemap or call blkrevalidatediskzones(). However it must be called using the new table (referenced by md->zonerevalidatemap) and the new queue limits while the DM device is suspended. dmblkreportzones() needs some way to distinguish between a call from blkrevalidatediskzones(), which must be allowed to use md->zonerevalidatemap to access this not yet activated table, and all other calls to dmblkreportzones(), which should not be allowed while the device is suspended and cannot use md->zonerevalidatemap, since the zone resources might be freed by the process currently calling blkrevalidatediskzones().

Solve this by tracking the process that sets md->zonerevalidatemap in dmrevalidatezones() and only allowing that process to make use of it in dmblkreport_zones().