All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Roman Vivchar" <rva333@protonmail.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v5 3/4] nvmem: mtk-efuse: add CPU speedbin post-processing
Date: Wed, 30 Sep 2026 10:27:24 +0000	[thread overview]
Message-ID: <20260930102725.57E831F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260930-6572-nvmem-v5-3-384d2a3a1770@protonmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] nvmem: flawed string matching applies cpu-speedbin hook to unintended prefixes
- [High] nvmem: out-of-bounds access on zero-length cell in mtk_efuse_cpu_speedbin_pp()
--

commit 6fd2c8ebf274a3effe09809dbfe826b5c25b063f
Author: Roman Vivchar <rva333@protonmail.com>

nvmem: mtk-efuse: add CPU speedbin post-processing

This commit adds support for converting CPU speedbin values stored in efuse
into a bitmask for opp-supported-hw usage in device trees on mobile SoCs.

> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index 980c29d013375..d2e5c69c580e3 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
> @@ -70,6 +70,18 @@ static int mtk_efuse_gpu_speedbin_pp(void *context, const char *id, int index,
>  	return 0;
>  }
>  
> +static int mtk_efuse_cpu_speedbin_pp(void *context, const char *id, int index,
> +				     unsigned int offset, void *data, size_t bytes)
> +{
> +	u8 *val = data;
> +
> +	if (val[0] >= 8)

[Severity: High]
If a device tree defines a matching nvmem cell with a length of 0 bytes
(e.g., reg = <0x0 0x0>), the nvmem core allocates an empty buffer using
kzalloc(0, GFP_KERNEL), which returns the ZERO_SIZE_PTR macro.

Could this unconditionally dereference that ZERO_SIZE_PTR and cause a
kernel panic when reading the cell?

> +		return -EINVAL;
> +
> +	val[0] = BIT(val[0]);
> +	return 0;
> +}
> +
>  static void mtk_efuse_fixup_dt_cell_info(struct nvmem_device *nvmem,
>  					 struct nvmem_cell_info *cell)
>  {

[ ... ]

> @@ -83,6 +95,13 @@ static void mtk_efuse_fixup_dt_cell_info(struct nvmem_device *nvmem,
>  	if (cell->nbits <= 3 &&
>  	    strncmp(cell->name, "gpu-speedbin", min(sz, strlen("gpu-speedbin"))) == 0)
>  		cell->read_post_process = mtk_efuse_gpu_speedbin_pp;
> +
> +	/*
> +	 * On mobile SoCs, the CPU speedbin is a number. Convert it to
> +	 * a bitmask for supported-hw usage.
> +	 */
> +	if (strncmp(cell->name, "cpu-speedbin", min(sz, strlen("cpu-speedbin"))) == 0)

[Severity: High]
Does this string comparison correctly restrict the match to just the
"cpu-speedbin" cell?

Since the comparison length uses min(sz, strlen("cpu-speedbin")), if a
device tree contains a cell with a name that is a shorter prefix of
"cpu-speedbin" (like "cpu" or "c"), the min() function will select the
shorter string's length.

Could this result in strncmp returning 0 for unrelated cell prefixes,
incorrectly applying the post-processing hook and silently corrupting
their data?

> +		cell->read_post_process = mtk_efuse_cpu_speedbin_pp;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930-6572-nvmem-v5-0-384d2a3a1770@protonmail.com?part=3

  reply	other threads:[~2026-09-30 10:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30 10:14 [PATCH v5 0/4] nvmem: mtk-efuse: mt6572 support Roman Vivchar via B4 Relay
2026-09-30 10:14 ` Roman Vivchar
2026-09-30 10:14 ` [PATCH v5 1/4] dt-bindings: nvmem: mediatek: efuse: add mt6572 Roman Vivchar via B4 Relay
2026-09-30 10:14   ` Roman Vivchar
2026-09-30 10:14 ` [PATCH v5 2/4] nvmem: mtk-efuse: add support for 32-bit aligned reads Roman Vivchar via B4 Relay
2026-09-30 10:14   ` Roman Vivchar
2026-09-30 10:14 ` [PATCH v5 3/4] nvmem: mtk-efuse: add CPU speedbin post-processing Roman Vivchar via B4 Relay
2026-09-30 10:14   ` Roman Vivchar
2026-09-30 10:27   ` sashiko-bot [this message]
2026-09-30 10:14 ` [PATCH v5 4/4] nvmem: mtk-efuse: add mt6572 support Roman Vivchar via B4 Relay
2026-09-30 10:14   ` Roman Vivchar

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=20260930102725.57E831F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=rva333@protonmail.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.