From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 18DDE50276 for ; Sun, 19 Jul 2026 01:08:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784423313; cv=none; b=m8U7V4qq0+XdktA3X1WfVG1mC9FpVGXY2cp7RFkXxq8+BxPRKN67VkP/d9JXcBpwokMdT3Zd7771UY67qzXhPDIN1hBzh4wOSD/CVxRuVlJDwNwQPpcyuoI4Q2F4fVhGKZ71/U72L6he/hDJjSlBDGDr6wO7ryshqUznn0pLKdU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784423313; c=relaxed/simple; bh=UGxSHi8cOn0uNpx7MEVqo9nMzemyx/MeWuc94D281qw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZYMS6K18aDJOth1rkkQB/H/3y3Suv8WRXKRq0deZGhyR+/9vn9C67dsjP7Sunqe40X11535nO6oWdRE0Pqv4ZMrAaTw20WDRMMerX+7VQU+t0iTevhAh5gpd2FD/hBMnJYq2dxpw4LZNQGmuac9dU4ZG+vArYYczXRih5zyyhFg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=C8ZYl+E8; arc=none smtp.client-ip=209.85.210.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="C8ZYl+E8" Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-848643382fcso10410111b3a.1 for ; Sat, 18 Jul 2026 18:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784423311; x=1785028111; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=NuToQr39obqpD4VdspvFEgg8d1UCcxlVMRw6FO2YI44=; b=C8ZYl+E8h+7+BKdQ25kSk8Mj9ylRiGk3acY7GSxZivkTvCElDcxmIzaicfsZneDxtm kGnHu6EgjjbNv4UtFycmSeQaG6Z+RrJgE1hpR9L/38WfS760BoOACfme5ry1ZOCBq97y SV234RoD81Yx0byLQcUlGHiJ7JarfWSAz1ci4g9RCnvw/ZY6x5ZvVI/+ceA/Yy6cICCE Mhs3mCW9NQ03sedeyFxRgbYIweX/lwgkv0fpCs85BIz2iWXiBE3vFQElahBGjN5rDlHR 5iy3XI6rogCQTU/gIgmCYNjgMLb78xK8DIPkAJD2ZGNpu2H7RWTpOyauT088UKlp7byE 70wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784423311; x=1785028111; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=NuToQr39obqpD4VdspvFEgg8d1UCcxlVMRw6FO2YI44=; b=IYDqdL01n+M1OJVaHlBVhoxpgNrOl5xbmUQrZ8DM04tf6So1p+LnGxXFbr/gu0hPlg BxwSkf85SLw9dNt+XLOn2d1e1CFBSZ2VIDQ7jHNgZITXL3s6EcBBZytqDMqZ2kTT/3do FzJDscriznIVZpTpiwNjVgq7S3YJSk8vnyN3QPoBWoekd9sHwxls+7PSRkZmxpCt4gie skb97P6LJfXbd9ycZ4g+XZ2DiGqH+rjC1/fCNeYO35eLOk3dXXOI22FVbQ9IEEpht2pG t3II25qXMPyrwUbpk4B3jGXAlsTgTvFpRq/wF1ZNe8S0xiECSIMkvcwvRuq3oXBfXcI+ L/Rg== X-Forwarded-Encrypted: i=1; AHgh+RpWO8cO5xPz33rcYR4mwMWevbeddV/EQ9Snmyh8Nlnq5JhPKbLhCL5AdKgM25NpByax8f12l9UcsFPb9Sk=@vger.kernel.org X-Gm-Message-State: AOJu0YzXFOqPVwjOsSDQwNAh0Vh3g1/Po3orwYWwqKaH8Xtwqe//AGhv mChnKnRqAZz9YMwx9KKVXH21UPFaeZknCGDsCKerDwUc2DWh8vd+CnWV X-Gm-Gg: AfdE7clIQwyYbhPbw94SRXhR8MWBs2uK3TeyDJoAK29RTxuI47acndjTnamrJUjDFet pDUXHxjOWGarzxukfya7dZgEiPVqewLX/btMZSCdTs1uCMAj2khCHsYXzUlSMP1TC5dFkP+Y/Zu 8eoo4cj5WG6S7VWu5BrITX1GBEZtWD8eJtjzwZ/paGTOa49sBDj2EW5ym4S6Vqr4dXl/bI9cdsN FVAXqYZRYaEPpSr6GvZPP+MXEqHqjNM4urqKC8RLU4yS/NhKoA6HKT6ZLSQw6ErnsfQHXdiNPnT iObYYmx9Arnoq4gZPjQQXoGhjvxupDgMxpzjdcpuH5IVhLyMk8DamZAUu/ofn/uByRf7YtlDjSX XRHmqqDKR0ksQT/abHeBJjY8KqeA60AlZwH1n/5MrsE1Nmh1GDCuPR/r+s82AV1pCuu0JCsZtkk +YPEkvYateFKaCm5ArPP9ehEqZCK8xcxc6lj5jl0ED5JmJ3i8XfvwwOkX8ALYDDpHfRo4= X-Received: by 2002:a05:6a00:f8d:b0:847:94bb:30e2 with SMTP id d2e1a72fcca58-84c294d4bd3mr8627469b3a.41.1784423311283; Sat, 18 Jul 2026 18:08:31 -0700 (PDT) Received: from nugod-NUC15CRHU5.tail9f095a.ts.net ([218.237.104.87]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84c2af9af73sm3446544b3a.53.2026.07.18.18.08.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Jul 2026 18:08:30 -0700 (PDT) From: HyeongJun An To: Pratyush Yadav , Michael Walle , Tudor Ambarus , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra Cc: Takahiro Kuwano , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, HyeongJun An Subject: [PATCH 1/2] mtd: spi-nor: sfdp: check the length of the xSPI Profile 1.0 table Date: Sun, 19 Jul 2026 10:08:19 +0900 Message-ID: <20260719010820.1924739-2-sammiee5311@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260719010820.1924739-1-sammiee5311@gmail.com> References: <20260719010820.1924739-1-sammiee5311@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit spi_nor_parse_profile1() sizes its bounce buffer from the length the flash reports in the SFDP parameter header, then indexes that buffer at fixed offsets: len = profile1_header->length * sizeof(*dwords); dwords = kmalloc(len, GFP_KERNEL); ... dummy = FIELD_GET(PROFILE1_DWORD5_DUMMY_166MHZ, dwords[SFDP_DWORD(5)]); The parser reads up to DWORD5, but never checks that the table is that long. The length is a u8 the flash supplies, so a device advertising the table with a shorter length makes the read run past the allocation: with a length of one the buffer is four bytes and dwords[SFDP_DWORD(5)] reads sixteen bytes beyond it. A length of zero is worse, as kmalloc() then returns ZERO_SIZE_PTR rather than an error and the first access dereferences it. The bytes read out of bounds are not just discarded either, they end up as the dummy cycle count programmed for 8D-8D-8D fast reads. SFDP tables that do not match what the flash actually implements are common enough that this file already carries fixup hooks for them, and malformed SFDP has caused memory-safety bugs here before. See commit f0f0cfdc3a02 ("mtd: spi-nor: Fix shift-out-of-bounds in spi_nor_set_erase_type"). Reject a table shorter than the highest DWORD the parser reads, the way spi_nor_parse_4bait() already does with SFDP_4BAIT_DWORD_MAX. Failing an optional parameter table is not fatal: spi_nor_parse_sfdp() warns and carries on with the data gathered so far. Fixes: fb27f198971a ("mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An --- drivers/mtd/spi-nor/sfdp.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c index 4600983cb579..d3d85b5d1b4a 100644 --- a/drivers/mtd/spi-nor/sfdp.c +++ b/drivers/mtd/spi-nor/sfdp.c @@ -1175,6 +1175,7 @@ static int spi_nor_parse_4bait(struct spi_nor *nor, #define PROFILE1_DWORD5_DUMMY_166MHZ GENMASK(31, 27) #define PROFILE1_DWORD5_DUMMY_133MHZ GENMASK(21, 17) #define PROFILE1_DWORD5_DUMMY_100MHZ GENMASK(11, 7) +#define SFDP_PROFILE1_DWORD_MAX 5 /** * spi_nor_parse_profile1() - parse the xSPI Profile 1.0 table @@ -1192,6 +1193,9 @@ static int spi_nor_parse_profile1(struct spi_nor *nor, int ret; u8 dummy, opcode; + if (profile1_header->length < SFDP_PROFILE1_DWORD_MAX) + return -EINVAL; + len = profile1_header->length * sizeof(*dwords); dwords = kmalloc(len, GFP_KERNEL); if (!dwords) -- 2.43.0