Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Luca Leonardo Scorcia" <l.scorcia@gmail.com>
Cc: robh@kernel.org, dmitry.torokhov@gmail.com,
	devicetree@vger.kernel.org, conor+dt@kernel.org,
	linux-input@vger.kernel.org
Subject: Re: [PATCH v9 6/9] input: keyboard: mtk-pmic-keys: Add MT6392 support
Date: Sun, 21 Jun 2026 08:28:17 +0000	[thread overview]
Message-ID: <20260621082818.428DB1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260621081634.467858-7-l.scorcia@gmail.com>

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

Pre-existing issues:
- [High] Potential array overflow when iterating over device tree child nodes if disabled nodes are present.
--

commit 59fc7db0ad7a68e49a6e83f5d6e6861165fb6460
Author: Val Packett <val@packett.cool>
Subject: input: keyboard: mtk-pmic-keys: Add MT6392 support

This commit adds support for the MT6392 PMIC to the MediaTek PMIC keys driver
by introducing its specific register definitions.

> diff --git a/drivers/input/keyboard/mtk-pmic-keys.c b/drivers/input/keyboard/mtk-pmic-keys.c
> index c78d9f6d97c4f..8b4a89fce4fb1 100644
> --- a/drivers/input/keyboard/mtk-pmic-keys.c
> +++ b/drivers/input/keyboard/mtk-pmic-keys.c

[ ... ]

[Severity: High]
This isn't a bug introduced by this patch, but there is a pre-existing issue
in mtk_pmic_keys_probe().

Is it possible for the loop iteration to cause an out-of-bounds array access?

The code starts by validating the available child node count against the
maximum allowed keys:

	keycount = of_get_available_child_count(node);
	if (keycount > MTK_PMIC_MAX_KEY_COUNT ||
	    keycount > ARRAY_SIZE(irqnames)) {
		dev_err(keys->dev, "too many keys defined (%d)\n", keycount);
		return -EINVAL;
	}

However, the loop below it iterates over all child nodes, including those
with status="disabled":

	for_each_child_of_node_scoped(node, child) {
		keys->keys[index].regs = &mtk_pmic_regs->keys_regs[index];

		keys->keys[index].irq =
			platform_get_irq_byname(pdev, irqnames[index]);

If a device tree happens to contain more than two child nodes in total but
only two or fewer are marked as available, the initial keycount check passes.

The loop will then execute more than twice, and when the index reaches 2,
it overflows the keys->keys array and the irqnames array.

Would it be better to use for_each_available_child_of_node_scoped() here
instead to safely skip the disabled nodes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260621081634.467858-1-l.scorcia@gmail.com?part=6

  reply	other threads:[~2026-06-21  8:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-21  8:13 [PATCH v9 0/9] Add support for MT6392 PMIC Luca Leonardo Scorcia
2026-06-21  8:13 ` [PATCH v9 1/9] dt-bindings: mfd: mt6397: Add " Luca Leonardo Scorcia
2026-06-21  8:13 ` [PATCH v9 2/9] dt-bindings: input: mtk-pmic-keys: Add MT6392 PMIC keys Luca Leonardo Scorcia
2026-06-21  8:13 ` [PATCH v9 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC Luca Leonardo Scorcia
2026-06-21  8:30   ` sashiko-bot
2026-06-21  8:13 ` [PATCH v9 4/9] mfd: mt6397: Use MFD_CELL_* to describe sub-devices Luca Leonardo Scorcia
2026-06-21  8:29   ` sashiko-bot
2026-06-21  8:13 ` [PATCH v9 5/9] mfd: mt6397: Add support for MT6392 PMIC Luca Leonardo Scorcia
2026-06-21  8:32   ` sashiko-bot
2026-06-21  8:13 ` [PATCH v9 6/9] input: keyboard: mtk-pmic-keys: Add MT6392 support Luca Leonardo Scorcia
2026-06-21  8:28   ` sashiko-bot [this message]
2026-06-21  8:13 ` [PATCH v9 7/9] pinctrl: mediatek: mt6397: Add MediaTek MT6392 Luca Leonardo Scorcia
2026-06-21  8:30   ` sashiko-bot
2026-06-21  8:13 ` [PATCH v9 8/9] regulator: Add MediaTek MT6392 regulator Luca Leonardo Scorcia
2026-06-21  8:30   ` sashiko-bot
2026-06-21  8:13 ` [PATCH v9 9/9] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi Luca Leonardo Scorcia

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=20260621082818.428DB1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=l.scorcia@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=robh@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox