On Thu, 17 Jul 2025, Hou Tao wrote: > Hi, > > On 7/17/2025 10:07 PM, Li Lingfeng wrote: > > There is a window between freeing md->ima.active_table.hash and setting > > md->ima.active_table.hash to NULL in dm_ima_measure_on_device_resume(). > > If dm_ima_measure_on_device_remove() accesses md->ima.active_table.hash > > concurrently during this window, it could lead to a double free or UAF, > > as shown below: > > The UAF is a problem. However, I think the order of > dm_ima_measure_on_device_remove() and dm_ima_measure_on_device_resume is > bigger problem. Is it possible to order these two invocations properly > by using suspend_lock ? That's a good point. The patch just papers over the problem. It will fix the UAF warning, but it won't fix the fact that dm_ima_measure_on_device_resume can race with dm_ima_measure_on_device_remove. The real fix would be to make sure that dm_ima_measure_* calls are never called concurrently on the same table - we should use existing device mapper locks for that. Mikukas
