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

On Sun, Jun 28, 2026 at 4:21 PM <[email protected]> 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 <[email protected]>
>
> 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 <[email protected]>
>
> > 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/[email protected]?part=1