From: HyeongJun An <sammiee5311@gmail.com>
To: Pratyush Yadav <pratyush@kernel.org>,
Michael Walle <mwalle@kernel.org>,
Tudor Ambarus <tudor.ambarus@linaro.org>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>
Cc: Takahiro Kuwano <takahiro.kuwano@infineon.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, HyeongJun An <sammiee5311@gmail.com>
Subject: [PATCH 0/2] mtd: spi-nor: sfdp: bound two optional parameter tables
Date: Sun, 19 Jul 2026 10:08:18 +0900 [thread overview]
Message-ID: <20260719010820.1924739-1-sammiee5311@gmail.com> (raw)
Two of the optional SFDP parameter table parsers allocate a bounce buffer
from the table length the flash reports, then index it at fixed offsets
without checking the table is long enough to hold them.
spi_nor_parse_profile1() reads up to DWORD5, never checks the length
spi_nor_parse_sccr() reads up to DWORD22, never checks the length
The length is a u8 supplied by the flash, so a device that advertises
either table with a shorter length makes the read run past the
allocation, and a length of zero makes kmalloc() hand back
ZERO_SIZE_PTR, which the parsers then dereference.
spi_nor_parse_4bait() already guards its table this way with
SFDP_4BAIT_DWORD_MAX, so both patches just apply the same check.
spi_nor_parse_sccr_mc() is left alone: it derives its highest index from
the length it allocated with, so it stays in bounds.
The two parsers were added at different times, so they carry different
Fixes tags and are split into one patch each.
Found by code inspection; I have no xSPI or multi-die part to reproduce
this on, so this is not runtime tested.
HyeongJun An (2):
mtd: spi-nor: sfdp: check the length of the xSPI Profile 1.0 table
mtd: spi-nor: sfdp: check the length of the SCCR map
drivers/mtd/spi-nor/sfdp.c | 8 ++++++++
1 file changed, 8 insertions(+)
--
2.43.0
next reply other threads:[~2026-07-19 1:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-19 1:08 HyeongJun An [this message]
2026-07-19 1:08 ` [PATCH 1/2] mtd: spi-nor: sfdp: check the length of the xSPI Profile 1.0 table HyeongJun An
2026-07-20 7:41 ` Michael Walle
2026-07-19 1:08 ` [PATCH 2/2] mtd: spi-nor: sfdp: check the length of the SCCR map HyeongJun An
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=20260719010820.1924739-1-sammiee5311@gmail.com \
--to=sammiee5311@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@kernel.org \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
--cc=takahiro.kuwano@infineon.com \
--cc=tudor.ambarus@linaro.org \
--cc=vigneshr@ti.com \
/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®