From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B65504570ED for ; Wed, 29 Jul 2026 09:47:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785318432; cv=none; b=sd2grH0jc50OY44H/w1sgoy+wcOLp+tg+6QezeZzPxApS9PT8jQ8fZtOraAANfyWVAjsl7/4qGzeX4ADACoQI+4kiUNzfO3z+Z+pm3fxa9eBFEVmu1/qirAEwCwJNpitw2gDkKiDIK/TwCNFgWrGWZxmvaL1Z+0GDnefOuKYO80= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785318432; c=relaxed/simple; bh=xnKWOCsG8E7pmcGhxkKFS/zqU+yArvR4fO2WhdWa0Xs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RsaTER4HctHqewg7nkizaxlfS8ptotqQNK6XgN+oMFfBzOfBsbtlkUfeZsP1nJQuF9utTG7zNA87bKg7frlvzA42DgoSddOe9R/wUji2C/nlp89Xrz67AWT9lSoF8OuSQL7ai98ybTzhfBXWQo5rgMrG+MyDkE0LIOrpxkuPow4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SQLqNrpg; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SQLqNrpg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 652431F000E9; Wed, 29 Jul 2026 09:47:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785318431; bh=u7wD04P5BavPSBp0xZQqSCLpJ/5buKWEDjqBjfO24V0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=SQLqNrpggFq48tIzyp+Cwzr67iOyIhna1NVx8+86RW/S7K6Y0T4DjQE8IHzjiG2CI 1Zmkmth6fNalMLdoZeMCt6AKElbRohqgE8lDwjset6HQwbb+Mbnxa4noaPsiAc7fs3 pRzQ1FJaFKR/ZspVhSDxdCUlDCpT892+Ag3oa27n6/XoWbeQl8JhDPNHIln5VlNn+c xUeoa/FacmoKD04AdjwyH9Ggvt3Ckc/Du99ilTVonO3CmHATSzj29mCzWy3OmKIS1R TpXlHnvRWgnUi2jz2ufmmtTCY+8QCSfO4wGcPjSRGvhRKK8vLP6M7ToTHS3QanuYIk rEs9zrkfW69rQ== From: srini@kernel.org To: gregkh@linuxfoundation.org Cc: linux-kernel@vger.kernel.org, Rosen Penev , Srinivas Kandagatla Subject: [PATCH 13/14] nvmem: brcm_nvram: fix out-of-bounds access on malformed flash data Date: Wed, 29 Jul 2026 10:46:46 +0100 Message-ID: <20260729094647.111468-14-srini@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260729094647.111468-1-srini@kernel.org> References: <20260729094647.111468-1-srini@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Rosen Penev The length check in brcm_nvram_parse() validated header->len against priv->nvmem_size (the full partition size) instead of priv->data_len (the actual allocated data buffer). A malformed flash partition with header->len between the two would pass the check, causing brcm_nvram_add_cells() to read and write priv->data[len - 1] beyond the heap allocation. Also add a minimum bound: len < sizeof(*header) could underflow the data[len - 1] access. Fix both bounds by rejecting len outside [sizeof(*header), priv->data_len]. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev Signed-off-by: Srinivas Kandagatla --- drivers/nvmem/brcm_nvram.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/nvmem/brcm_nvram.c b/drivers/nvmem/brcm_nvram.c index c3b4282aa164..9f77aee37121 100644 --- a/drivers/nvmem/brcm_nvram.c +++ b/drivers/nvmem/brcm_nvram.c @@ -192,9 +192,13 @@ static int brcm_nvram_parse(struct brcm_nvram *priv) } len = le32_to_cpu(header->len); - if (len > priv->nvmem_size) { - dev_err(dev, "NVRAM length (%zd) exceeds mapped size (%zd)\n", len, - priv->nvmem_size); + if (len < sizeof(*header)) { + dev_err(dev, "NVRAM length (%zd) too small\n", len); + return -EINVAL; + } + if (len > priv->data_len) { + dev_err(dev, "NVRAM length (%zd) exceeds data size (%zd)\n", len, + priv->data_len); return -EINVAL; } -- 2.53.0