All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Michal Piekos" <michal.piekos@mmpsystems.pl>
Cc: linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v2] iio: adc: sun20i-gpadc: support non-contiguous channel lookups
Date: Thu, 14 May 2026 12:16:08 +0000	[thread overview]
Message-ID: <20260514121608.EF78FC2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <20260514-fix-sunxi-gpadc-sparse-channels-v2-1-d4a66b70c7a7@mmpsystems.pl>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Missing validation of iiospec->nargs leads to uninitialized stack memory read
- [Low] Spelling and grammar errors in the commit message
--

commit 0da362a2628891f0ec84a4906fcbc3b1521286d2
Author: Michal Piekos <michal.piekos@mmpsystems.pl>

iio: adc: sun20i-gpadc: support non-contiguous channel lookups

This commit adds a fwnode_xlate callback to support sparse channel maps
by mapping the devicetree phandle argument to the registered channel whose
ID matches the hardware channel number.

> Using consumer driver like iio-hwmon which resolve channels thorugh
> io-channels phandles will fail for sparse channels because IIO core by
> default threats phandle argument as index into channel array.

This isn't a bug, but there are typos in the commit message: "thorugh"
instead of "through", and "threats" instead of "treats".

> diff --git a/drivers/iio/adc/sun20i-gpadc-iio.c b/drivers/iio/adc/sun20i-gpadc-iio.c
> index 861c14da75add..78c9a52f38df0 100644
> --- a/drivers/iio/adc/sun20i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun20i-gpadc-iio.c

[ ... ]

> @@ -139,8 +139,20 @@ static irqreturn_t sun20i_gpadc_irq_handler(int irq, void *data)
>  	return IRQ_HANDLED;
>  }
>  
> +static int
> +sun20i_gpadc_fwnode_xlate(struct iio_dev *indio_dev,
> +			  const struct fwnode_reference_args *iiospec)
> +{
> +	for (unsigned int i = 0; i < indio_dev->num_channels; i++)
> +		if (indio_dev->channels[i].channel == iiospec->args[0])

Is it possible to read uninitialized stack memory here?

The IIO core function __fwnode_iio_channel_get() allocates iiospec on the
stack without zero-initializing it. When parsing a reference from a
malformed devicetree node (e.g., #io-channel-cells = <0>), an ACPI table,
or a software node, fwnode_property_get_reference_args() returns success
and sets iiospec->nargs = 0 but leaves the args array unmodified.

If iiospec->nargs is not verified, this evaluates iiospec->args[0]
using uninitialized memory. If this garbage data happens to match an
existing channel ID, the driver could spuriously map a random channel.

Should this function check if iiospec->nargs < 1 before accessing the
arguments array?

> +			return i;
> +
> +	return -EINVAL;
> +}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514-fix-sunxi-gpadc-sparse-channels-v2-1-d4a66b70c7a7@mmpsystems.pl?part=1

  reply	other threads:[~2026-05-14 12:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14  3:19 [PATCH v2] iio: adc: sun20i-gpadc: support non-contiguous channel lookups Michal Piekos
2026-05-14 12:16 ` sashiko-bot [this message]
2026-05-15  9:26 ` Andy Shevchenko

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=20260514121608.EF78FC2BCB3@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=michal.piekos@mmpsystems.pl \
    --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.