All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mehmet Fide" <mehmet.fide@gmail.com>
Cc: imx@lists.linux.dev, Frank.Li@kernel.org
Subject: Re: [PATCH v2 1/2] pinctrl: imx: answer OUTPUT_ENABLE/INPUT_ENABLE queries from the pad register
Date: Wed, 02 Sep 2026 07:56:29 +0000	[thread overview]
Message-ID: <20260902075629.D0B1C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260902073946.3709080-2-mehmet.fide@gmail.com>

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

New issues:
- [High] Dangerous asymmetry between `pin_config_get` (generic) and `pin_config_set` (raw) causes hardware register corruption.
- [Medium] Incomplete transition to generic pinconf API breaks SCU-based platforms.

Pre-existing issues:
- [Critical] Out-of-bounds write during Device Tree parsing in imx_pinctrl_parse_pin_mmio
--

commit 5ebc05bfe4b54b3133759fc4096ed3eedaf8a185
Author: Mehmet Fide <mehmet.fide@screeningeagle.com>

pinctrl: imx: answer OUTPUT_ENABLE/INPUT_ENABLE queries from the pad register

The mmio pinconf get callback ignores which parameter was requested and
returns the raw conf register, so a generic query through
pinctrl_gpio_get_config() gets register bits back instead of the packed
parameter it asked for. Decode the requested parameter and answer
PIN_CONFIG_OUTPUT_ENABLE and PIN_CONFIG_INPUT_ENABLE on SoCs that declare
where those bits live in the pad register.

> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c b/drivers/pinctrl/freescale/pinctrl-imx.c
> index 9a45b376d36f9..506ee6627c827 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
[ ... ]
> @@ -312,6 +313,38 @@ static int imx_pinconf_get_mmio(struct pinctrl_dev *pctldev, unsigned pin_id,
>  	return 0;
>  }
>  
> +static int imx_pinconf_get_mmio(struct pinctrl_dev *pctldev,
> +				unsigned int pin_id, unsigned long *config)
> +{
> +	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
> +	const struct imx_pinctrl_soc_info *info = ipctl->info;
> +	const struct imx_pin_reg *pin_reg = &ipctl->pin_regs[pin_id];
> +	enum pin_config_param param = pinconf_to_config_param(*config);
> +	unsigned int mask;
> +	u32 raw;
> +
> +	/* only the parameters the SoC declares a pad bit for */
> +	switch (param) {
> +	case PIN_CONFIG_OUTPUT_ENABLE:
> +		mask = info->obe_mask;
> +		break;
> +	case PIN_CONFIG_INPUT_ENABLE:
> +		mask = info->ibe_mask;
> +		break;
> +	default:
> +		mask = 0;
> +		break;
> +	}
> +
> +	if (!mask || pin_reg->conf_reg == -1)
> +		return -ENOTSUPP;
> +
> +	raw = readl(ipctl->base + pin_reg->conf_reg);
> +	*config = pinconf_to_config_packed(param, !!(raw & mask));
> +
> +	return 0;
> +}
> +
>  static int imx_pinconf_get(struct pinctrl_dev *pctldev,
>  			   unsigned pin_id, unsigned long *config)
>  {
> @@ -324,6 +357,18 @@ static int imx_pinconf_get(struct pinctrl_dev *pctldev,
>  		return imx_pinconf_get_mmio(pctldev, pin_id, config);
>  }

[Severity: Medium]
Does this bypass the generic decoding logic for SCU platforms?

If a generic caller like pinctrl_gpio_get_config() queries an SCU-based
platform, it appears the SCU path (info->imx_pinconf_get) will overwrite
the generic parameter in *config with a raw hardware register value instead
of unpacking it.

> +static int imx_pinconf_get_raw(struct pinctrl_dev *pctldev,
> +			       unsigned int pin_id, unsigned long *config)
> +{
> +	struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
> +	const struct imx_pinctrl_soc_info *info = ipctl->info;
> +
> +	if (info->flags & IMX_USE_SCU)
> +		return info->imx_pinconf_get(pctldev, pin_id, config);
> +	else
> +		return imx_pinconf_get_raw_mmio(pctldev, pin_id, config);
> +}
> +
>  static int imx_pinconf_set_mmio(struct pinctrl_dev *pctldev,
>  				unsigned pin_id, unsigned long *configs,
>  				unsigned num_configs)

[Severity: High]
Does this introduce an asymmetry between the get and set callbacks causing
hardware corruption?

While the get callback now unpacks generic parameters, imx_pinconf_set_mmio()
remains completely raw. If a generic caller like pinctrl_gpio_set_config()
passes a packed config (e.g., PIN_CONFIG_LEVEL), will it be blindly written
into the hardware pad configuration register here?

[Severity: Critical]
This is a pre-existing issue, but can the Device Tree parsing cause an
out-of-bounds write here?

Looking at imx_pinctrl_parse_pin_mmio() in drivers/pinctrl/freescale/pinctrl-imx.c:

    *pin_id = (mux_reg != -1) ? mux_reg / 4 : conf_reg / 4;
    pin_reg = &ipctl->pin_regs[*pin_id];
    pin->pin = *pin_id;
    pin_reg->mux_reg = mux_reg;
    pin_reg->conf_reg = conf_reg;

If a maliciously crafted Device Tree overlay provides an excessively large
mux_reg or conf_reg value, the unvalidated pin_id is used to index into
ipctl->pin_regs, potentially overwriting arbitrary memory.

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

  reply	other threads:[~2026-09-02  7:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02  7:39 [PATCH v2 0/2] gpio: mmio: report the line direction on chips without direction registers Mehmet Fide
2026-09-02  7:39 ` [PATCH v2 1/2] pinctrl: imx: answer OUTPUT_ENABLE/INPUT_ENABLE queries from the pad register Mehmet Fide
2026-09-02  7:56   ` sashiko-bot [this message]
2026-09-02 11:08     ` Mehmet Fide
2026-09-02  7:39 ` [PATCH v2 2/2] gpio: mmio: track the direction of chips without direction registers Mehmet Fide

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=20260902075629.D0B1C1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=mehmet.fide@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.