[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