From: Yu Junzhe <junzheyu1@gmail.com>
To: Mike Snitzer <snitzer@kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>,
Benjamin Marzinski <bmarzins@redhat.com>,
Alasdair Kergon <agk@redhat.com>
Cc: dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [BUG] dm-integrity: mode R resume NULL deref when DIRTY_BITMAP is set
Date: Mon, 17 Aug 2026 10:06:04 +0000 [thread overview]
Message-ID: <20260817100605.292-1-junzheyu1@gmail.com> (raw)
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 <fuzzanything@gmail.com>
next reply other threads:[~2026-08-17 10:06 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 10:06 Yu Junzhe [this message]
2026-08-17 15:10 ` [BUG] dm-integrity: mode R resume NULL deref when DIRTY_BITMAP is set Mikulas Patocka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260817100605.292-1-junzheyu1@gmail.com \
--to=junzheyu1@gmail.com \
--cc=agk@redhat.com \
--cc=bmarzins@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=snitzer@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.