[BUG] dm-integrity: dangling reboot notifier after resume vs remove race

[BUG] dm-integrity: dangling reboot notifier after resume vs remove race

[Junzhe Yu]

[-- Attachment #1: Type: text/plain, Size: 3800 bytes --]

Hello,

I am reporting a KASAN slab use-after-free in dm-integrity involving the
reboot notifier registration path.

Summary
=======

A late do_resume() can register ic->reboot_notifier on a dm_integrity_c
object that a concurrent DM_DEV_REMOVE path is destroying. The removal path
unregisters the old notifier via dm_integrity_postsuspend() and later frees
ic in dm_integrity_dtr(), but does not unregister the notifier that the
racing resume just installed. The global reboot notifier chain is then left
with a dangling node; a later notifier_chain_register() walk touches it and
panics under KASAN.

Affected
========

- Confirmed on Linux 6.6.144 (da47cbc254661aa66d61ef061485a7080305c4be)
- Originally found on Linux 6.6.0 (ffc253263a1375a65fa6c9f62a893e9767fbebfa)
- Files: drivers/md/dm-integrity.c, drivers/md/dm-ioctl.c, kernel/notifier.c
- Config: CONFIG_DM=y, CONFIG_DM_INTEGRITY=y, CONFIG_KASAN=y

Root cause (brief)
==================

1. do_resume() in drivers/md/dm-ioctl.c resumes mapped device md without
    rechecking whether md has already entered the DMF_FREEING removal path.
2. Under the bad interleaving, removal has already unregistered the old
    ic->reboot_notifier through dm_integrity_postsuspend().
3. The late do_resume() continues into dm_integrity_resume() and registers a
    new ic->reboot_notifier on the global reboot notifier chain.
4. Removal then frees this ic via dm_table_destroy() / dm_integrity_dtr(),
    but no second postsuspend() runs to unregister the newly registered
    notifier.
5. The chain retains a dangling notifier_block embedded in the freed ic.
    A later notifier_chain_register() walks the list to insert by priority,
    touches the freed node, and panics.

Crash excerpt (KASAN)
=====================

BUG: KASAN: slab-use-after-free in notifier_chain_register+0x2aa/0x310 
kernel/notifier.c:35
Call Trace:
  notifier_chain_register+0x2aa/0x310
  blocking_notifier_chain_register+0x6e/0xc0
  dm_integrity_resume+0x5a4/0x1a20 drivers/md/dm-integrity.c:3293
  dm_table_resume_targets+0x1d5/0x350
  dm_resume+0x19e/0x2b0
  dev_suspend+0x543/0x7e0

Allocated by: dm_integrity_ctr -> table_load
Freed by:     dm_integrity_dtr -> __dm_destroy -> DM_DEV_REMOVE

Full stack is in the attached tarball as stacktrace.txt.

Impact
======

Privileged local DoS (CAP_SYS_ADMIN required to use /dev/mapper/control).
dm-integrity is an optional target. The race can be hit reliably (especially
with CPU-pinned workers), but we do not have a stable reclaim path to RIP
control. We are reporting this as a low-risk privileged DoS / functional
memory-safety bug, not as a high-severity exploit.

Reproducer
==========

Attached: dm-integrity-notifier-uaf-repro.tar.gz

VM-only (do not run on a production host). Minimized PoC: concurrent
DM_DEV_CREATE / DM_TABLE_LOAD (two integrity tables) / DM_DEV_SUSPEND
(resume) / DM_DEV_REMOVE. Workers use sched_setaffinity to CPU 0; without
CPU binding the race may miss on some hosts.

Quick path (Docker + KVM):

   tar xzf dm-integrity-notifier-uaf-repro.tar.gz
   cd <extracted-dir>   # contains Dockerfile, poc.c, repro.sh, ...
   docker build -t dm-integrity-uaf -f Dockerfile .
   mkdir -p artifacts
   docker run --rm --privileged --device=/dev/kvm --network=host \
     -v "$PWD/artifacts:/artifacts" \
     -e OUTPUT_DIR=/artifacts \
     -e RUN_TIMEOUT_SEC=180 \
     dm-integrity-uaf

Expected within ~20-90s after the PoC starts (first run also builds the
kernel):

   BUG: KASAN: slab-use-after-free in notifier_chain_register
   ...
   dm_integrity_resume
   ...
   Kernel panic - not syncing: KASAN: panic_on_warn set ...

I am happy to test patches. Please let me know if you need more detail.

Thanks,
Yu Junzhe
FuzzAnything <fuzzanything@gmail.com>

[-- Attachment #2: dm-integrity-notifier-uaf-repro.tar.gz --]
[-- Type: application/x-gzip, Size: 9366 bytes --]

Re: [BUG] dm-integrity: dangling reboot notifier after resume vs remove race

[Mikulas Patocka]

On Sat, 18 Jul 2026, Junzhe Yu wrote:

> Hello,
> 
> I am reporting a KASAN slab use-after-free in dm-integrity involving the
> reboot notifier registration path.
> 
> Summary
> =======
> 
> A late do_resume() can register ic->reboot_notifier on a dm_integrity_c
> object that a concurrent DM_DEV_REMOVE path is destroying. The removal path
> unregisters the old notifier via dm_integrity_postsuspend() and later frees
> ic in dm_integrity_dtr(), but does not unregister the notifier that the
> racing resume just installed. The global reboot notifier chain is then left
> with a dangling node; a later notifier_chain_register() walk touches it and
> panics under KASAN.

Hi

Does this patch fix it?

Mikulas


dm: fix resume-vs-remove race

If the user issues the resume ioctl and the remove ioctl at the same
time, it may be possible that the device is resumed after it is suspended
in __dm_destroy. The result is that the table is destroyed without
calling the postsuspend method.

Dm targets expect that they may be removed only after the postsuspend
method method was called. If we break this expectation, it can cause
misbehavior in various targets. For example - in the dm-integrity target,
the reboot notifier is not unregistered, leading to use-after-free.

Fix this bug by refusing to resume if the device is being destroyed.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org

---
 drivers/md/dm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/drivers/md/dm.c
===================================================================
--- linux-2.6.orig/drivers/md/dm.c	2026-07-13 20:58:56.000000000 +0200
+++ linux-2.6/drivers/md/dm.c	2026-07-22 17:40:29.000000000 +0200
@@ -3140,7 +3140,7 @@ retry:
 	r = -EINVAL;
 	mutex_lock_nested(&md->suspend_lock, SINGLE_DEPTH_NESTING);
 
-	if (!dm_suspended_md(md))
+	if (!dm_suspended_md(md) || test_bit(DMF_FREEING, &md->flags))
 		goto out;
 
 	if (dm_suspended_internally_md(md)) {

Re: [BUG] dm-integrity: dangling reboot notifier after resume vs remove race

[Junzhe Yu]

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]

Hi Mikulas,

Thanks for the suggested fix. We verified it on Linux 6.6.144 with KASAN
against our minimized PoC (resume racing remove / reboot-notifier UAF).

   if (!dm_suspended_md(md) || test_bit(DMF_FREEING, &md->flags))
           goto out;

Results:
   - unpatched: KASAN slab-use-after-free in notifier_chain_register via
     dm_integrity_resume within ~20s
   - with your change: no KASAN UAF for a 5-minute PoC window

Self-contained test package (patch + poc.c + A/B scripts + captured logs):

   dm-integrity-dm-resume-fix-test.tar.gz

Re-run with Docker (see README.md inside the tarball):

   docker build -t dm-integrity-patch-test -f Dockerfile .
   mkdir -p artifacts
   docker run --rm --privileged --device=/dev/kvm --network=host \
     -v "$PWD/artifacts:/artifacts" -e OUTPUT_DIR=/artifacts \
     dm-integrity-patch-test

Thanks,
Junzhe

On 7/23/2026 12:14 AM, Mikulas Patocka wrote:
>
> On Sat, 18 Jul 2026, Junzhe Yu wrote:
>
>> Hello,
>>
>> I am reporting a KASAN slab use-after-free in dm-integrity involving the
>> reboot notifier registration path.
>>
>> Summary
>> =======
>>
>> A late do_resume() can register ic->reboot_notifier on a dm_integrity_c
>> object that a concurrent DM_DEV_REMOVE path is destroying. The removal path
>> unregisters the old notifier via dm_integrity_postsuspend() and later frees
>> ic in dm_integrity_dtr(), but does not unregister the notifier that the
>> racing resume just installed. The global reboot notifier chain is then left
>> with a dangling node; a later notifier_chain_register() walk touches it and
>> panics under KASAN.
> Hi
>
> Does this patch fix it?
>
> Mikulas
>
>
> dm: fix resume-vs-remove race
>
> If the user issues the resume ioctl and the remove ioctl at the same
> time, it may be possible that the device is resumed after it is suspended
> in __dm_destroy. The result is that the table is destroyed without
> calling the postsuspend method.
>
> Dm targets expect that they may be removed only after the postsuspend
> method method was called. If we break this expectation, it can cause
> misbehavior in various targets. For example - in the dm-integrity target,
> the reboot notifier is not unregistered, leading to use-after-free.
>
> Fix this bug by refusing to resume if the device is being destroyed.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Cc: stable@vger.kernel.org
>
> ---
>   drivers/md/dm.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/drivers/md/dm.c
> ===================================================================
> --- linux-2.6.orig/drivers/md/dm.c	2026-07-13 20:58:56.000000000 +0200
> +++ linux-2.6/drivers/md/dm.c	2026-07-22 17:40:29.000000000 +0200
> @@ -3140,7 +3140,7 @@ retry:
>   	r = -EINVAL;
>   	mutex_lock_nested(&md->suspend_lock, SINGLE_DEPTH_NESTING);
>   
> -	if (!dm_suspended_md(md))
> +	if (!dm_suspended_md(md) || test_bit(DMF_FREEING, &md->flags))
>   		goto out;
>   
>   	if (dm_suspended_internally_md(md)) {
>

[-- Attachment #2: dm-integrity-dm-resume-fix-test.tar.gz --]
[-- Type: application/x-gzip, Size: 12704 bytes --]