[PATCH] dm-verity: clear LSM integrity state on suspend

dm-verity publishes its root hash and signature state to LSMs in
verity_preresume(). LSMs such as IPE store this information in the block
device's security blob and use it to authorize access to files.

The original LSM integration relied on DM_TARGET_IMMUTABLE to prevent
verity from being replaced by a different target type. However, DM allows
tables containing a DM_TARGET_WILDCARD target to replace immutable
targets. The block device can then retain the old integrity state even
though its data is no longer verified by dm-verity.

Clear the published root hash and signature state in verity_postsuspend()
so that the block device does not retain stale dm-verity attributes after
the verity target is replaced.

Fixes: a6af7bc3d72f ("dm-verity: expose root hash digest and signature data to LSMs")
Assisted-by: gpt-6-astra
Signed-off-by: Fan Wu <wufan@kernel.org>
---
 drivers/md/dm-verity-target.c | 39 ++++++++++++++++++++++++++++-------
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
index cb105ccc47ec..6d589867623c 100644
--- a/drivers/md/dm-verity-target.c
+++ b/drivers/md/dm-verity-target.c

@@ -825,13 +825,6 @@ static int verity_map(struct dm_target *ti, struct bio *bio)
 	return DM_MAPIO_SUBMITTED;
 }
 
-static void verity_postsuspend(struct dm_target *ti)
-{
-	struct dm_verity *v = ti->private;
-	flush_workqueue(v->verify_wq);
-	dm_bufio_client_reset(v->bufio);
-}
-
 /*
  * Status: V (valid) or C (corruption found)
  */

@@ -1733,6 +1726,11 @@ static int verity_security_set_signature(struct block_device *bdev,
 					  v->sig_size);
 }
 
+static void verity_security_clear_signature(struct block_device *bdev)
+{
+	security_bdev_setintegrity(bdev, LSM_INT_DMVERITY_SIG_VALID, NULL, 0);
+}
+
 #else
 
 static inline int verity_security_set_signature(struct block_device *bdev,

@@ -1741,6 +1739,10 @@ static inline int verity_security_set_signature(struct block_device *bdev,
 	return 0;
 }
 
+static inline void verity_security_clear_signature(struct block_device *bdev)
+{
+}
+
 #endif /* CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG */
 
 /*

@@ -1779,8 +1781,31 @@ static int verity_preresume(struct dm_target *ti)
 	return r;
 }
 
+static void verity_security_clear_integrity(struct dm_target *ti)
+{
+	struct block_device *bdev = dm_disk(dm_table_get_md(ti->table))->part0;
+
+	security_bdev_setintegrity(bdev, LSM_INT_DMVERITY_ROOTHASH, NULL, 0);
+	verity_security_clear_signature(bdev);
+}
+
+#else
+
+static inline void verity_security_clear_integrity(struct dm_target *ti)
+{
+}
+
 #endif /* CONFIG_SECURITY */
 
+static void verity_postsuspend(struct dm_target *ti)
+{
+	struct dm_verity *v = ti->private;
+
+	flush_workqueue(v->verify_wq);
+	dm_bufio_client_reset(v->bufio);
+	verity_security_clear_integrity(ti);
+}
+
 static struct target_type verity_target = {
 	.name		= "verity",
 /* Note: the LSMs depend on the singleton and immutable features */

base-commit: 93f51579e7df248780214094418f205253383cc5
-- 
2.55.0

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dm-verity: clearing LSM state on suspend breaks IPE for cached files
- [High] ipe: Use-After-Free in evaluate_dmv_roothash() due to missing RCU
--

commit 0a1a0f42158da1707e32f8b9739a8420e73985d1
Author: Fan Wu [off-list ref]

dm-verity: clear LSM integrity state on suspend

This commit updates dm-verity to clear the published root hash and signature
state from the LSM security blob during verity_postsuspend(). This prevents
the block device from retaining stale attributes if the verity target is
replaced with a different target type.

[ ... ]

[Severity: High]
Does passing NULL to security_bdev_setintegrity() trigger a use-after-free
in IPE?

When this is called, ipe_bdev_setintegrity() appears to free the root hash
without RCU synchronization:

security/ipe/hooks.c:ipe_bdev_setintegrity() {
	if (!value) {
		ipe_digest_free(blob->root_hash);
		blob->root_hash = NULL;
...

If a concurrent thread is evaluating an mprotect or execve call, could it
dereference this freed memory in evaluate_dmv_roothash()?

security/ipe/eval.c:evaluate_dmv_roothash() {
	...
	ipe_digest_eval(p->value, ctx->ipe_bdev->root_hash);
...

[Severity: High]
Does unconditionally clearing the integrity state on every table suspend break
IPE evaluation for already cached files?

During a temporary freeze or table reload, clearing the LSM integrity state
will cause concurrent VFS operations on already-cached files to see a cleared
state. Will this result in spurious -EACCES failures since IPE will deny
access despite the files being valid?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921220516.121589-1-wufan@kernel.org?part=1

On Mon, Sep 21, 2026 at 3:18 PM [off-list ref] wrote:

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dm-verity: clearing LSM state on suspend breaks IPE for cached files
- [High] ipe: Use-After-Free in evaluate_dmv_roothash() due to missing RCU
--

commit 0a1a0f42158da1707e32f8b9739a8420e73985d1
Author: Fan Wu [off-list ref]

dm-verity: clear LSM integrity state on suspend

This commit updates dm-verity to clear the published root hash and signature
state from the LSM security blob during verity_postsuspend(). This prevents
the block device from retaining stale attributes if the verity target is
replaced with a different target type.

quoted

diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
index cb105ccc47ecb..6d589867623c0 100644
--- a/drivers/md/dm-verity-target.c
+++ b/drivers/md/dm-verity-target.c

[ ... ]

quoted

@@ -1779,8 +1781,31 @@ static int verity_preresume(struct dm_target *ti)
      return r;
 }

+static void verity_security_clear_integrity(struct dm_target *ti)
+{
+     struct block_device *bdev = dm_disk(dm_table_get_md(ti->table))->part0;
+
+     security_bdev_setintegrity(bdev, LSM_INT_DMVERITY_ROOTHASH, NULL, 0);

[Severity: High]
Does passing NULL to security_bdev_setintegrity() trigger a use-after-free
in IPE?

When this is called, ipe_bdev_setintegrity() appears to free the root hash
without RCU synchronization:

security/ipe/hooks.c:ipe_bdev_setintegrity() {
        if (!value) {
                ipe_digest_free(blob->root_hash);
                blob->root_hash = NULL;
...

If a concurrent thread is evaluating an mprotect or execve call, could it
dereference this freed memory in evaluate_dmv_roothash()?

security/ipe/eval.c:evaluate_dmv_roothash() {
        ...
        ipe_digest_eval(p->value, ctx->ipe_bdev->root_hash);
...

I will post an UAF fix for this, however this is an ipe issue so not
blocking this patch.

quoted

+     verity_security_clear_signature(bdev);
+}
+
+#else
+
+static inline void verity_security_clear_integrity(struct dm_target *ti)
+{
+}
+
 #endif /* CONFIG_SECURITY */

+static void verity_postsuspend(struct dm_target *ti)
+{
+     struct dm_verity *v = ti->private;
+
+     flush_workqueue(v->verify_wq);
+     dm_bufio_client_reset(v->bufio);
+     verity_security_clear_integrity(ti);

[Severity: High]
Does unconditionally clearing the integrity state on every table suspend break
IPE evaluation for already cached files?

During a temporary freeze or table reload, clearing the LSM integrity state
will cause concurrent VFS operations on already-cached files to see a cleared
state. Will this result in spurious -EACCES failures since IPE will deny
access despite the files being valid?

This is the expected behavior. Tracking the verification status of
cached data is impractical.

The deny issue can also be avoided by creating a new dm device instead
of swapping tables.

-Fan

Accepted, thanks.

I've just deleted the "Fixes:" line, so that it doesn't go into -stable 
kernels.

Mikulas



On Mon, 21 Sep 2026, Fan Wu wrote: