From: Michael Bommarito <michael.bommarito@gmail.com>
To: linux-mtd@lists.infradead.org,
David Woodhouse <dwmw2@infradead.org>,
Richard Weinberger <richard@nod.at>
Cc: Zhihao Cheng <chengzhihao1@huawei.com>,
Artem Sadovnikov <a.sadovnikov@ispras.ru>,
Kees Cook <kees@kernel.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] jffs2: bound summary reads on crafted flash
Date: Wed, 15 Apr 2026 08:48:11 -0400 [thread overview]
Message-ID: <20260415124813.246588-1-michael.bommarito@gmail.com> (raw)
Hi,
Two mount-time out-of-bounds reads in fs/jffs2/summary.c that are
reachable when the kernel mounts a crafted JFFS2 flash image. Both
reproduced on v7.0-rc7 under UML with CONFIG_KASAN=y and
CONFIG_MTD_BLOCK2MTD=y; pre-fix each oopses in
jffs2_sum_scan_sumnode, post-fix the same images are rejected with a
warning and the scanner falls back to the full scan path.
1/2 -- jffs2_sum_scan_sumnode() computes
crc = crc32(0, summary->sum,
sumsize - sizeof(struct jffs2_raw_summary));
If a crafted on-flash jffs2_sum_marker.offset drives sumsize
below sizeof(struct jffs2_raw_summary) (= 32), the subtraction
underflows in size_t and crc32() walks ~16 EiB. The earlier
header reads of summary->totlen / ->hdr_crc / ->node_crc are
OOB for the same class of sumsize values. Bound sumsize at
JFFS2_SUMMARY_FRAME_SIZE (header + marker = 40) which is the
minimum frame the writer at jffs2_sum_write_sumnode() emits.
KASAN evidence:
BUG: KASAN: slab-out-of-bounds in
jffs2_sum_scan_sumnode+0x131/0x1611
Read of size 4 at addr 00000000621fb004 by task mount/31
Located 4 bytes to the right of 4096-byte region
2/2 -- jffs2_sum_process_sum_data() iterates summary->sum_num times
with no bounds check on the remaining payload. Crafted
sum_num > (actual entries) walks sp off the summary buffer;
nodetype is then read from adjacent slab memory, and if those
bytes decode as one of the known case labels the handler
calls sum_link_node_ref() with offset/totlen pulled from the
OOB bytes. Pass sumsize into the helper and bound sp before
every nodetype read and every type-specific field access.
KASAN evidence (patch 1 applied so the bug is reached):
BUG: KASAN: slab-out-of-bounds in
jffs2_sum_scan_sumnode+0x6bd/0x16bf
Read of size 2 at addr 00000000621fb000 by task mount/31
Located 0 bytes to the right of 4096-byte region
A matching sum_num=1 image (same bytes, honest sum_num) does
not splat.
Impact:
Mount-time only, CAP_SYS_ADMIN required to attach the MTD and
call mount(2). Not reachable from unprivileged users, user
namespaces, FUSE, or network. Relevant practically on embedded
devices that auto-mount JFFS2 on boot when the flash is writable
out-of-band.
1/2 is an OOB read / DoS on mount.
2/2 is not just an OOB read: the type-specific handlers run past
the buffer boundary before sp is bounded, so corrupted in-memory
jeb state can persist past the faulting iteration rather than
cleanly oopsing. Closing the bound prevents that sequence. No
controlled kernel write, no RCE primitive in evidence.
Reproduction artefacts (craft scripts, UML init, pre/post KASAN
logs) are on the reporter side on request.
Thanks,
Mike
Michael Bommarito (2):
jffs2: reject truncated summary node before header validation
jffs2: bound summary entry walks against the payload
fs/jffs2/summary.c | 44 +++++++++++++++++++++++++++++++++++++++++---
1 file changed, 41 insertions(+), 3 deletions(-)
--
2.53.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next reply other threads:[~2026-04-15 12:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 12:48 Michael Bommarito [this message]
2026-04-15 12:48 ` [PATCH 1/2] jffs2: reject truncated summary node before header validation Michael Bommarito
2026-04-15 12:48 ` [PATCH 2/2] jffs2: bound summary entry walks against the payload Michael Bommarito
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=20260415124813.246588-1-michael.bommarito@gmail.com \
--to=michael.bommarito@gmail.com \
--cc=a.sadovnikov@ispras.ru \
--cc=chengzhihao1@huawei.com \
--cc=dwmw2@infradead.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox