All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Rosen Penev" <rosenp@gmail.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH] ARM: dts: BCM5301X: R7000: add nvram node
Date: Thu, 10 Sep 2026 00:20:54 +0000	[thread overview]
Message-ID: <20260910002055.231CA1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260910001300.117062-1-rosenp@gmail.com>

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

Pre-existing issues:
- [High] Missing length validation in `brcm_nvram_parse` allows for out-of-bounds heap read/write and potential panics (preexisting).
--

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

ARM: dts: BCM5301X: R7000: add nvram node

This commit adds the nvram node to the BCM4709 Netgear R7000 device tree
and configures it for gmac0.

> diff --git a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts
> index 24ba8f8f9bf36..0f3a00bc38c14 100644
> --- a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r7000.dts
> @@ -25,6 +25,15 @@ memory@0 {
>  		      <0x88000000 0x08000000>;
>  	};
>  
> +	nvram@1c080000 {
> +		compatible = "brcm,nvram";

[Severity: High]
This is a pre-existing issue, but adding this DTS node exposes the device to a
missing length validation in the brcm_nvram driver.

In drivers/nvmem/brcm_nvram.c:brcm_nvram_parse(), if the NVRAM flash is
completely erased or uninitialized (e.g. all 0xFF or 0x00),
brcm_nvram_copy_data() calculates priv->data_len as 0. This causes
devm_kzalloc() to return ZERO_SIZE_PTR.

Will the subsequent memcmp() dereference this invalid pointer and cause a
panic?

    if (memcmp(header->magic, NVRAM_MAGIC, 4)) {

Furthermore, if len is larger than priv->data_len, it is validated against
the mapped region size (priv->nvmem_size) instead of the allocated heap
size:

    if (len > priv->nvmem_size) {

Can this lead to an out-of-bounds heap read and write in
brcm_nvram_add_cells()?

    tmp = priv->data[len - 1];
    priv->data[len - 1] = '\0';

> +		reg = <0x1c080000 0x180000>;
> +
> +		et0macaddr: et0macaddr {
> +			#nvmem-cell-cells = <1>;
> +		};
> +	};

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

      reply	other threads:[~2026-09-10  0:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10  0:13 [PATCH] ARM: dts: BCM5301X: R7000: add nvram node Rosen Penev
2026-09-10  0:20 ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260910002055.231CA1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=rosenp@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.