[PATCH] nvmem: brcm_nvram: reject empty NVRAM partition

[PATCH] nvmem: brcm_nvram: reject empty NVRAM partition

[Rosen Penev]

If the partition is completely erased (all padding bytes), the trimming
loop reduces data_len to 0. devm_kzalloc(dev, 0, GFP_KERNEL) returns
ZERO_SIZE_PTR ((void *)16), which is non-NULL and bypasses the NULL
check. The subsequent cast of priv->data to struct brcm_nvram_header *
and dereference of header->magic causes a page fault on address 0x10.

Reject data_len smaller than the header before allocating.

Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 drivers/nvmem/brcm_nvram.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/nvmem/brcm_nvram.c b/drivers/nvmem/brcm_nvram.c
index a29183ecd3e0..9f77aee37121 100644
--- a/drivers/nvmem/brcm_nvram.c
+++ b/drivers/nvmem/brcm_nvram.c
@@ -84,6 +84,11 @@ static int brcm_nvram_copy_data(struct brcm_nvram *priv, struct platform_device
 	}
 	WARN(priv->data_len > SZ_128K, "Unexpected (big) NVRAM size: %zu B\n", priv->data_len);
 
+	if (priv->data_len < sizeof(struct brcm_nvram_header)) {
+		dev_err(priv->dev, "NVRAM data too small (%zu)\n", priv->data_len);
+		return -EINVAL;
+	}
+
 	priv->data = devm_kzalloc(priv->dev, priv->data_len, GFP_KERNEL);
 	if (!priv->data)
 		return -ENOMEM;
-- 
2.55.0

Re: [PATCH] nvmem: brcm_nvram: reject empty NVRAM partition

[Srinivas Kandagatla]

On Fri, 03 Jul 2026 15:28:30 -0700, Rosen Penev wrote:
> If the partition is completely erased (all padding bytes), the trimming
> loop reduces data_len to 0. devm_kzalloc(dev, 0, GFP_KERNEL) returns
> ZERO_SIZE_PTR ((void *)16), which is non-NULL and bypasses the NULL
> check. The subsequent cast of priv->data to struct brcm_nvram_header *
> and dereference of header->magic causes a page fault on address 0x10.
> 
> Reject data_len smaller than the header before allocating.
> 
> [...]

Applied, thanks!

[1/1] nvmem: brcm_nvram: reject empty NVRAM partition
      commit: 5f75913830bc584dc6f43af8dca8de0dd910517e

Best regards,
-- 
Srinivas Kandagatla <srini@kernel.org>