linux-hardening - [PATCH] mtd: Avoid boot crash in RedBoot partition table parser

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <92af570970aadee773f2b0b18179efef0f34be93.1771114891.git.fthain@linux-m68k.org>
Date: Sun, 15 Feb 2026 11:21:31 +1100
From: Finn Thain <fthain@...ux-m68k.org>
To: Miquel Raynal <miquel.raynal@...tlin.com>,
    Richard Weinberger <richard@....at>,
    Vignesh Raghavendra <vigneshr@...com>,
    Miguel Ojeda <ojeda@...nel.org>,
    Kees Cook <kees@...nel.org>
Cc: stable@...r.kernel.org,
    linux-hardening@...r.kernel.org,
    linux-mtd@...ts.infradead.org,
    linux-kernel@...r.kernel.org
Subject: [PATCH] mtd: Avoid boot crash in RedBoot partition table parser

Given CONFIG_FORTIFY_SOURCE=y, and given a recent compiler,
commit 439a1bcac648 ("fortify: Use __builtin_dynamic_object_size() when
available") produces the warning below and an oops.

    Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000
    ------------[ cut here ]------------
    WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1
    memcmp: detected buffer overflow: 15 byte read of buffer size 14
    Modules linked in:
    CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE

I couldn't see how memcmp() exceeds the buffer here, so the simplest way
to prevent the regression was to perform memcmp() on the original name
rather than the copy.

Cc: stable@...r.kernel.org
Cc: linux-hardening@...r.kernel.org
Fixes: 439a1bcac648 ("fortify: Use __builtin_dynamic_object_size() when available")
Signed-off-by: Finn Thain <fthain@...ux-m68k.org>
---
I put commit 439a1bcac648 into a Fixes tag because git bisect identified
that commit as the source of the regression. But I don't know anything
about __builtin_dynamic_object_size() or its limitations. So perhaps the
real bug lies elsewhere. The compiler I'm using is this one:

$ armeb-softfloat-linux-musleabi-gcc --version
armeb-softfloat-linux-musleabi-gcc (Gentoo Hardened 13.4.1_p20250807 p8) 13.4.1 20250807
---
 drivers/mtd/parsers/redboot.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/parsers/redboot.c b/drivers/mtd/parsers/redboot.c
index 3b55b676ca6b..6e253f6c45c9 100644
--- a/drivers/mtd/parsers/redboot.c
+++ b/drivers/mtd/parsers/redboot.c
@@ -269,14 +269,14 @@ static int parse_redboot_partitions(struct mtd_info *master,
 		parts[i].name = names;
 
 		strcpy(names, fl->img->name);
+		names += strlen(names) + 1;
+
 #ifdef CONFIG_MTD_REDBOOT_PARTS_READONLY
-		if (!memcmp(names, "RedBoot", 8) ||
-		    !memcmp(names, "RedBoot config", 15) ||
-		    !memcmp(names, "FIS directory", 14)) {
+		if (!memcmp(fl->img->name, "RedBoot", 8) ||
+		    !memcmp(fl->img->name, "RedBoot config", 15) ||
+		    !memcmp(fl->img->name, "FIS directory", 14))
 			parts[i].mask_flags = MTD_WRITEABLE;
-		}
 #endif
-		names += strlen(names) + 1;
 
 #ifdef CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED
 		if (fl->next && fl->img->flash_base + fl->img->size + master->erasesize <= fl->next->img->flash_base) {
-- 
2.49.1