From: hyunjungg <hj351016@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>,
Richard Weinberger <richard@nod.at>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Hyunjung Ko <hj351016@gmail.com>
Subject: [PATCH] jffs2: validate summary offset in the XIP scan path
Date: Fri, 6 Nov 2026 18:51:07 +0900 [thread overview]
Message-ID: <20261106095108.2405364-1-hj351016@gmail.com> (raw)
From: Hyunjung Ko <hj351016@gmail.com>
jffs2_scan_eraseblock() locates the summary node at the end of an
eraseblock and derives both a pointer and a length from the on-flash
summary marker:
sumptr = buf + je32_to_cpu(sm->offset);
sumlen = c->sector_size - je32_to_cpu(sm->offset);
In the non-XIP branch this is followed by
if (sumlen > c->sector_size)
goto full_scan;
so a bogus sm->offset (for which sector_size - offset underflows to a
large value) is rejected. The XIP branch (taken when the whole device
was successfully mtd_point()ed, e.g. an mtdram-backed MTD) is missing
that check.
On a crafted image an attacker controls the bytes of the summary marker
at the end of the last eraseblock. Setting sm->magic == JFFS2_SUM_MAGIC
and sm->offset > sector_size makes sumlen wrap to ~4 GiB while sumptr
still points inside the mapped flash. jffs2_sum_scan_sumnode() then runs
crc = crc32(0, summary->sum,
sumsize - sizeof(struct jffs2_raw_summary));
with the attacker-controlled sumsize, reading far past the end of the
mtd_point() mapping -- an out-of-bounds read (KASAN: vmalloc OOB /
general protection fault) of controlled length. The preceding header
CRC checks are computed over data read from the attacker-controlled
flash and can be satisfied, so they do not prevent the over-read.
Mirror the non-XIP guard in the XIP branch.
Reproduced under KASAN on 7.4-rc1 by mounting a crafted mtdram-backed
image (the XIP mtd_point() branch): KASAN reports a vmalloc-out-of-bounds
read in the summary-node crc32 over the mapped flash.
Signed-off-by: Hyunjung Ko <hj351016@gmail.com>
---
fs/jffs2/scan.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
--- a/fs/jffs2/scan.c
+++ b/fs/jffs2/scan.c
@@ -495,6 +495,10 @@ static int jffs2_scan_eraseblock (struct jffs2_sb_info *c, struct jffs2_eraseblo
if (je32_to_cpu(sm->magic) == JFFS2_SUM_MAGIC) {
sumptr = buf + je32_to_cpu(sm->offset);
sumlen = c->sector_size - je32_to_cpu(sm->offset);
+
+ /* sm->offset may be garbage even if MAGIC matched */
+ if (sumlen > c->sector_size)
+ goto full_scan;
}
} else {
/* If NAND flash, read a whole page of it. Else just the end */
next reply other threads:[~2026-11-06 9:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 9:51 hyunjungg [this message]
2026-11-06 10:11 ` [PATCH v2] jffs2: validate summary length before scanning the summary node hyunjungg
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=20261106095108.2405364-1-hj351016@gmail.com \
--to=hj351016@gmail.com \
--cc=dwmw2@infradead.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
all inboxes | Powered by JetHome®