kernel/git/next/linux-next.git/drivers/md/dm-ima.c, branch master

dm-ima: use active table's size if available

2026-05-04T12:53:52+00:00

It is possible that the dm_ima_measure_on_* functions run at the same time as a table is getting swapped, but before the md->ima.active_table is updated by dm_ima_measure_on_device_resume(). Instead of using the current device size, use the size of the active table that is being measured (assuming there is one), so the information is consistent. Also, don't allocate a separate string to hold the capactiy. Just print it directly to the measurement buffer. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka

dm-ima: Fail more gracefully in dm_ima_measure_on_*

2026-05-04T12:53:44+00:00

In all the dm_ima_measure_on_* functions besides dm_ima_measure_on_table_load(), even if measuring the event fails, it's still possible to update dm->ima, so that it continues to correctly track the device state. This means that one measurement failure won't cause future measurements to record the wrong data. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka

dm-ima: Handle race between rename and table swap

2026-05-04T12:53:35+00:00

a device rename could happen after do_resume() removed the inactive table that it was swapping to out of the hash cell, but before it was made the active table. In this case, the table metadata would still have the old name. Update the swapped table's metadata to avoid this. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka

dm-ima: Fix issues with dm_ima_measure_on_device_rename

2026-05-04T12:53:27+00:00

dm_ima_measure_on_device_rename() can be called on a device before it ever loads a table, so it needs to handle the case where there is no table metadata. Also, it was only updating the table_metadata on the active table. If there was an inactive table when the device was renamed and that table was later swapped in as the active table, it would still have the old name. dm_ima_measure_on_device_rename() was also needlessly allocating new memory for the updated table metadata, instead of just reusing the existing memory. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka

dm-ima: remove new_map from dm_ima_measure_on_device_clear

2026-05-04T12:53:19+00:00

Now that two processes can't modify md->ima in dm_ima_measure_on_device_clear() at the same time, there's no need to track if an inactive table was actually removed. We might as well clean it up unconditionally, on the off chance that a previous ima measurement failed and left md->ima.inactive_table behind. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka

dm-ima: Fix UAF errors and measuring incorrect context

2026-05-04T12:53:09+00:00

the dm-ima code did not keep the dm_ima_measure_on_* functions from running at the same time. This could lead to various errors. If two processes were updating the device state, one could update the state first, but the other could measure the state first, causing the the current device state to appear incorrect. If a table load happened while a device was resuming, the IMA measurement could report the wrong table being active. And if two dm_ima_measure_on_* functions ran at the same time, one of them could free data that the other was accessing, causing a crash. All the core dm functions that call a dm_ima_measure_on_* function update the device state they want to measure under the _hash_lock, except for do_resume(). But holding the _hash_lock is not a good way to synchronize these functions. It's a global mutex, that is needed in many dm operations, and the dm_ima_measure_* functions can sleep, blocking any dm operation on any device that needs the _hash_lock. To serialize and order the IMA measurement functions, the dm_ima_measurements now has two counters, update_idx and measure_idx. update_idx is incremented while holding the _hash_lock and saved, along with the device name and uuid, in a dm_ima_context struct. Once the _hash_lock is dropped, the dm_ima_measure_* function is called. It waits until measure_idx matches the saved value of update_idx, ensuring that the updates and measurements happen in the same order if there are multiple processes changing the device at the same time. Then it measures the device, updates measure_idx, and wakes up any other process waiting to do a measurement. This makes sure that the measurements are serialized and done in the order that the _hash_lock was acquired in. But they only block other measurements for the same device, which are unlikely to happen at the same time. do_resume() is trickier, because it removes the inactive table while holding the _hash_lock, but doesn't hold it while updating md->map. To make sure it is also ordered, the IMA code grabs the _hash_lock after md->map is updated. Then it makes sure that the device isn't being removed and that another do_resume() hasn't already changed the active table again, and serializes like the other functions do. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka

dm-ima: don't copy the active table to the inactive table

2026-05-04T12:52:45+00:00

If an inactive table was cleared, dm_ima_measure_on_table_clear() was copying the ima.active_table to ima.inactive_table. This is not what device-mapper does, and it makes the IMA measurements show an inactive table when there isn't one. Also, once this is removed, the code no longer needs to keep checking if the active and the inactive table point to the same memory. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka

dm-ima: Remove status_flags from dm_ima_measure_on_table_load()

2026-05-04T12:52:37+00:00

There is no status flag that is is used for STATUSTYPE_IMA type status() calls, and STATUSTYPE_IMA itself is not a valid status flag. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka

dm-ima: remove broken last_target_measured logic

2026-05-04T12:52:28+00:00

When it ran out of space for adding more targets to the ima_buf, dm_ima_measure_on_table_load() would measure the dm device early, and then add the rest of the targets and measure it again. last_target_measured was intended to flag the last target measured so that the device wouldn't get remeasured, if no new targets were added after the early measurement. But the way to code works, the dm device will never be measured early unless there is another target to add to the ima_buf. Instead, if there is only one more target to add, that target was getting added to the ima_buf, but it wasn't getting remeasured, because last_target_measured was set. Since dm_ima_measure_on_table_load() only measures a device early when there are more targets to add, the final measurement must always happen, and last_target_measured is unneeded. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka

dm-ima: remove dm_ima_reset_data()

2026-05-04T12:52:18+00:00

There's no point in saving the string length of DM_IMA_VERSION_STR. It's a constant, so the compiler will precompute it. dm_create() will already zero out the rest of dm->ima. Signed-off-by: Benjamin Marzinski Signed-off-by: Mikulas Patocka