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

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 <[email protected]>