[PATCH] ARM: dts: BCM5301X: EA9200: fix nvram size

[PATCH] ARM: dts: BCM5301X: EA9200: fix nvram size

[Rosen Penev]

Fixes:

[ 0.182121] WARNING: CPU: 0 PID: 1 at drivers/nvmem/brcm_nvram.c:85 brcm_nvram_probe+0x400/0x480
[ 0.182159] Unexpected (big) NVRAM size: 1056112 B

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts b/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
index af411679a14a..37593e7582ba 100644
--- a/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
+++ b/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
@@ -26,7 +26,7 @@ memory@0 {
 
 	nvram@1c080000 {
 		compatible = "brcm,nvram";
-		reg = <0x1c080000 0x180000>;
+		reg = <0x1c080000 0x100000>;
 
 		et2macaddr: et2macaddr {
 			#nvmem-cell-cells = <1>;
-- 
2.54.0

Re: [PATCH] ARM: dts: BCM5301X: EA9200: fix nvram size

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Heap out-of-bounds read and write in `brcm_nvram_add_cells` due to mismatched logical length validation.
- [High] Fatal page fault due to `ZERO_SIZE_PTR` dereference if the NVRAM partition contains only padding bytes.
--

commit f8d0bb1af13fdcf08114311cb9160479fcd6bdb5
Author: Rosen Penev <rosenp@gmail.com>

ARM: dts: BCM5301X: EA9200: fix nvram size
    
Fixes:
    
[ 0.182121] WARNING: CPU: 0 PID: 1 at drivers/nvmem/brcm_nvram.c:85 brcm_nvram_probe+0x400/0x480
[ 0.182159] Unexpected (big) NVRAM size: 1056112 B
    
Signed-off-by: Rosen Penev <rosenp@gmail.com>

> diff --git a/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts b/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
> index 5bbc2ba0f9598..87569408bb695 100644
> --- a/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
> @@ -26,7 +26,7 @@ memory@0 {
>  
>  	nvram@1c080000 {
>  		compatible = "brcm,nvram";
> -		reg = <0x1c080000 0x180000>;
> +		reg = <0x1c080000 0x100000>;

[Severity: Critical]
This is a pre-existing issue, but I noticed a potential out-of-bounds heap
read and write in drivers/nvmem/brcm_nvram.c when parsing NVRAM partitions.

In brcm_nvram_parse(), the length check validates the logical length defined
in the header against the total partition size rather than the allocated data
length:

drivers/nvmem/brcm_nvram.c:brcm_nvram_parse() {
    ...
    if (len > priv->nvmem_size) {
    ...
}

If the flash data defines a header->len larger than the non-padding data
size but smaller than the total partition size (priv->nvmem_size), the driver
calls brcm_nvram_add_cells() with a len larger than the allocation:

drivers/nvmem/brcm_nvram.c:brcm_nvram_add_cells() {
    ...
    tmp = priv->data[len - 1];
    priv->data[len - 1] = '\0';
    ...
}

Can this lead to memory corruption if reading from a malformed flash
partition?

[Severity: High]
This is a pre-existing issue, but I also noticed a potential page fault
if the NVRAM partition is completely empty.

In drivers/nvmem/brcm_nvram.c:brcm_nvram_copy_data(), if the partition only
contains padding bytes, priv->data_len becomes 0. devm_kzalloc() will return
the ZERO_SIZE_PTR token (0x10) which bypasses the NULL check:

drivers/nvmem/brcm_nvram.c:brcm_nvram_copy_data() {
    ...
    priv->data = devm_kzalloc(priv->dev, priv->data_len, GFP_KERNEL);
    if (!priv->data)
        return -ENOMEM;
    ...
}

The ZERO_SIZE_PTR is then cast and dereferenced in brcm_nvram_parse():

drivers/nvmem/brcm_nvram.c:brcm_nvram_parse() {
    ...
    if (memcmp(header->magic, NVRAM_MAGIC, 4)) {
    ...
}

Could this cause a kernel panic due to dereferencing address 0x10 when
probing an erased flash partition?

>  
>  		et2macaddr: et2macaddr {
>  			#nvmem-cell-cells = <1>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260628231049.1248899-1-rosenp@gmail.com?part=1

Re: [PATCH] ARM: dts: BCM5301X: EA9200: fix nvram size

[Rosen Penev]

On Sun, Jun 28, 2026 at 4:21 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> Pre-existing issues:
> - [Critical] Heap out-of-bounds read and write in `brcm_nvram_add_cells` due to mismatched logical length validation.
> - [High] Fatal page fault due to `ZERO_SIZE_PTR` dereference if the NVRAM partition contains only padding bytes.
These issues were fixed separately.
> --
>
> commit f8d0bb1af13fdcf08114311cb9160479fcd6bdb5
> Author: Rosen Penev <rosenp@gmail.com>
>
> ARM: dts: BCM5301X: EA9200: fix nvram size
>
> Fixes:
>
> [ 0.182121] WARNING: CPU: 0 PID: 1 at drivers/nvmem/brcm_nvram.c:85 brcm_nvram_probe+0x400/0x480
> [ 0.182159] Unexpected (big) NVRAM size: 1056112 B
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>
> > diff --git a/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts b/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
> > index 5bbc2ba0f9598..87569408bb695 100644
> > --- a/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
> > +++ b/arch/arm/boot/dts/broadcom/bcm4709-linksys-ea9200.dts
> > @@ -26,7 +26,7 @@ memory@0 {
> >
> >       nvram@1c080000 {
> >               compatible = "brcm,nvram";
> > -             reg = <0x1c080000 0x180000>;
> > +             reg = <0x1c080000 0x100000>;
>
> [Severity: Critical]
> This is a pre-existing issue, but I noticed a potential out-of-bounds heap
> read and write in drivers/nvmem/brcm_nvram.c when parsing NVRAM partitions.
>
> In brcm_nvram_parse(), the length check validates the logical length defined
> in the header against the total partition size rather than the allocated data
> length:
>
> drivers/nvmem/brcm_nvram.c:brcm_nvram_parse() {
>     ...
>     if (len > priv->nvmem_size) {
>     ...
> }
>
> If the flash data defines a header->len larger than the non-padding data
> size but smaller than the total partition size (priv->nvmem_size), the driver
> calls brcm_nvram_add_cells() with a len larger than the allocation:
>
> drivers/nvmem/brcm_nvram.c:brcm_nvram_add_cells() {
>     ...
>     tmp = priv->data[len - 1];
>     priv->data[len - 1] = '\0';
>     ...
> }
>
> Can this lead to memory corruption if reading from a malformed flash
> partition?
>
> [Severity: High]
> This is a pre-existing issue, but I also noticed a potential page fault
> if the NVRAM partition is completely empty.
>
> In drivers/nvmem/brcm_nvram.c:brcm_nvram_copy_data(), if the partition only
> contains padding bytes, priv->data_len becomes 0. devm_kzalloc() will return
> the ZERO_SIZE_PTR token (0x10) which bypasses the NULL check:
>
> drivers/nvmem/brcm_nvram.c:brcm_nvram_copy_data() {
>     ...
>     priv->data = devm_kzalloc(priv->dev, priv->data_len, GFP_KERNEL);
>     if (!priv->data)
>         return -ENOMEM;
>     ...
> }
>
> The ZERO_SIZE_PTR is then cast and dereferenced in brcm_nvram_parse():
>
> drivers/nvmem/brcm_nvram.c:brcm_nvram_parse() {
>     ...
>     if (memcmp(header->magic, NVRAM_MAGIC, 4)) {
>     ...
> }
>
> Could this cause a kernel panic due to dereferencing address 0x10 when
> probing an erased flash partition?
>
> >
> >               et2macaddr: et2macaddr {
> >                       #nvmem-cell-cells = <1>;
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260628231049.1248899-1-rosenp@gmail.com?part=1

Re: [PATCH] ARM: dts: BCM5301X: EA9200: fix nvram size

[Florian Fainelli]

From: Florian Fainelli <f.fainelli@gmail.com>

On Sun, 28 Jun 2026 16:10:49 -0700, Rosen Penev <rosenp@gmail.com> wrote:
> Fixes:
> 
> [ 0.182121] WARNING: CPU: 0 PID: 1 at drivers/nvmem/brcm_nvram.c:85 brcm_nvram_probe+0x400/0x480
> [ 0.182159] Unexpected (big) NVRAM size: 1056112 B
> 
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---

Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian