Re: [BUG] dm-integrity: mode R resume NULL deref when DIRTY_BITMAP is set

Mikulas Patocka <[email protected]>
Newsgroups dev.linux.lists.dm-devel,org.kernel.vger.linux-kernel
Message-ID <[email protected]>

On Mon, 17 Aug 2026, Yu Junzhe wrote:

> Hello,
> 
> I am reporting a null-pointer dereference in dm-integrity resume: recovery
> mode R skips journal allocation, but dm_integrity_resume() still issues
> journal I/O when the on-disk superblock has SB_FLAG_DIRTY_BITMAP.
> 
> Summary
> =======
> 
> create_journal() runs only when mode != 'R', so ic->journal stays NULL.
> Resume treats DIRTY_BITMAP as "journal pages hold a bitmap" and calls
> rw_journal_sectors() before any journal/mode check:
> 
>   if (ic->sb->flags & cpu_to_le32(SB_FLAG_DIRTY_BITMAP)) {
>       rw_journal_sectors(ic, REQ_OP_READ, ...);  /* uses ic->journal[] */
> 
> rw_journal_sectors() then passes that NULL page list into dm_io():
> 
>   io_req.mem.type = DM_IO_PAGE_LIST;
>   io_req.mem.ptr.pl = &ic->journal[pl_index];  /* NULL in mode R */
> 
> list_get_page() does *p = pl->page with pl == NULL (KASAN range [0x8-0xf]).
> 
> DIRTY_BITMAP is set while bitmap mode (B) is active and is cleared on a
> clean postsuspend. It remains on disk after an unclean stop of mode B
> (crash / power loss). Reloading that device in recovery mode R is a
> documented recovery path and hits this bug.
> 
> Affected
> ========
> 
> - Confirmed on Linux 6.6.144 (da47cbc254661aa66d61ef061485a7080305c4be),
>   KASAN guest
> - Still present on torvalds/linux master as of 2026-08-17: resume still
>   calls rw_journal_sectors() under DIRTY_BITMAP with no journal / mode-R
>   guard
> - Files: drivers/md/dm-integrity.c
> - Config: CONFIG_DM=y, CONFIG_DM_INTEGRITY=y (KASAN for the report)
> 
> Crash excerpt (from minimized PoC)
> ==================================
> 
> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
> CPU: 0 PID: 234 Comm: repro Not tainted 6.6.144 #15
> RIP: 0010:list_get_page+0x7e/0x150
> Call Trace:
>  <TASK>
>   dispatch_io
>   sync_io
>   dm_io
>   rw_journal_sectors
>   dm_integrity_resume
>   dm_table_resume_targets
>   __dm_resume
>   dm_resume
>   dev_suspend
>   ctl_ioctl
>   dm_ctl_ioctl
>   __x64_sys_ioctl
>  </TASK>
> Kernel panic - not syncing: Fatal exception
> 
> Full oops and a self-contained Docker/QEMU reproducer (poc.c + KASAN
> guest) are available on request.
> 
> I am happy to test patches or send the reproducer package.
> 
> Thanks,
> Yu Junzhe
> FuzzAnything <[email protected]>

Hi

Does this patch fix it?

Mikulas


dm-integrity: fix NULL pointer dereference when the 'R' flag is used

If the dm-integrity device has the SB_FLAG_DIRTY_BITMAP flag set and the
user activates the device in the 'R' mode, a crash in dm_integrity_resume
happens because the function attempts to read the journal containing the
bitmap.

This patch makes dm-integrity skip any writes to the device in
dm_integrity_resume if the device is activated in the 'R' mode.

Signed-off-by: Mikulas Patocka <[email protected]>
Cc: [email protected]

---
 drivers/md/dm-integrity.c |    5 +++++
 1 file changed, 5 insertions(+)

Index: linux-2.6/drivers/md/dm-integrity.c
===================================================================
--- linux-2.6.orig/drivers/md/dm-integrity.c	2026-08-10 14:00:08.000000000 +0200
+++ linux-2.6/drivers/md/dm-integrity.c	2026-08-17 17:01:02.000000000 +0200
@@ -3875,6 +3875,10 @@ static void dm_integrity_resume(struct d
 	r = sync_rw_sb(ic, REQ_OP_READ);
 	if (r)
 		dm_integrity_io_error(ic, "reading superblock", r);
+
+	if (ic->mode == 'R')
+		goto skip_writes;
+
 	if ((ic->sb->flags & flags) != flags) {
 		ic->sb->flags |= flags;
 		r = sync_rw_sb(ic, REQ_OP_WRITE | REQ_FUA);
@@ -3984,6 +3988,7 @@ static void dm_integrity_resume(struct d
 		}
 	}
 
+skip_writes:
 	ic->reboot_notifier.notifier_call = dm_integrity_reboot;
 	ic->reboot_notifier.next = NULL;
 	ic->reboot_notifier.priority = INT_MAX - 1;	/* be notified after md and before hardware drivers */
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.