All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Linus Walleij <linus.walleij@linaro.org>,
	linux-gpio@vger.kernel.org, Sergey Shtylyov <s.shtylyov@omp.ru>
Cc: linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org
Subject: Re: [PATCH] pinctrl: rockchip: fix NULL ptr deref in rockchip_pinctrl_parse_groups()
Date: Sun, 07 Sep 2025 19:28:50 +0200	[thread overview]
Message-ID: <6789547.RUnXabflUD@phil> (raw)
In-Reply-To: <179c9e8c-8760-41e6-aad7-7a128df60984@omp.ru>

Am Mittwoch, 3. September 2025, 21:48:54 Mitteleuropäische Sommerzeit schrieb Sergey Shtylyov:
> In the Rockchip driver, rockchip_pinctrl_parse_groups() assumes that the
> "rockchip,pins" property will always be present in the DT node it parses
> and so doesn't check the result of of_get_property() for NULL. If the DT
> passed to the kernel happens to have such property missing, then we will
> get a kernel oops when the pointer is dereferenced in the *for* loop just
> a few lines after the call.  I think it's better to play safe by checking
> the list variable for NULL (and reporting error if so), like we check the
> size variable for validity further down...
> 
> Found by Linux Verification Center (linuxtesting.org) with the Svace static
> analysis tool.
> 
> Fixes: d3e5116119bd ("pinctrl: add pinctrl driver for Rockchip SoCs")
> Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>

Assuming that the DT is our friend, really is a bad assumption :-) .

While I can't imagine what 12-year-ago-me was thinking then, simply
checking the return value really is the better way

Reviewed-by: Heiko Stuebner <heiko@sntech.de>


> 
> ---
> The patch is against the master branch of Linus Torvalds' linux.git repo.
> 
>  drivers/pinctrl/pinctrl-rockchip.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> Index: linux/drivers/pinctrl/pinctrl-rockchip.c
> ===================================================================
> --- linux.orig/drivers/pinctrl/pinctrl-rockchip.c
> +++ linux/drivers/pinctrl/pinctrl-rockchip.c
> @@ -3488,7 +3488,9 @@ static int rockchip_pinctrl_parse_groups
>  	 * do sanity check and calculate pins number
>  	 */
>  	list = of_get_property(np, "rockchip,pins", &size);
> -	/* we do not check return since it's safe node passed down */
> +	if (!list)
> +		return dev_err_probe(dev, -EINVAL,
> +				     "%pOF: no rockchip,pins property\n", np);
>  	size /= sizeof(*list);
>  	if (!size || size % 4)
>  		return dev_err_probe(dev, -EINVAL,
> 






WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: Linus Walleij <linus.walleij@linaro.org>,
	linux-gpio@vger.kernel.org, Sergey Shtylyov <s.shtylyov@omp.ru>
Cc: linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org
Subject: Re: [PATCH] pinctrl: rockchip: fix NULL ptr deref in rockchip_pinctrl_parse_groups()
Date: Sun, 07 Sep 2025 19:28:50 +0200	[thread overview]
Message-ID: <6789547.RUnXabflUD@phil> (raw)
In-Reply-To: <179c9e8c-8760-41e6-aad7-7a128df60984@omp.ru>

Am Mittwoch, 3. September 2025, 21:48:54 Mitteleuropäische Sommerzeit schrieb Sergey Shtylyov:
> In the Rockchip driver, rockchip_pinctrl_parse_groups() assumes that the
> "rockchip,pins" property will always be present in the DT node it parses
> and so doesn't check the result of of_get_property() for NULL. If the DT
> passed to the kernel happens to have such property missing, then we will
> get a kernel oops when the pointer is dereferenced in the *for* loop just
> a few lines after the call.  I think it's better to play safe by checking
> the list variable for NULL (and reporting error if so), like we check the
> size variable for validity further down...
> 
> Found by Linux Verification Center (linuxtesting.org) with the Svace static
> analysis tool.
> 
> Fixes: d3e5116119bd ("pinctrl: add pinctrl driver for Rockchip SoCs")
> Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>

Assuming that the DT is our friend, really is a bad assumption :-) .

While I can't imagine what 12-year-ago-me was thinking then, simply
checking the return value really is the better way

Reviewed-by: Heiko Stuebner <heiko@sntech.de>


> 
> ---
> The patch is against the master branch of Linus Torvalds' linux.git repo.
> 
>  drivers/pinctrl/pinctrl-rockchip.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> Index: linux/drivers/pinctrl/pinctrl-rockchip.c
> ===================================================================
> --- linux.orig/drivers/pinctrl/pinctrl-rockchip.c
> +++ linux/drivers/pinctrl/pinctrl-rockchip.c
> @@ -3488,7 +3488,9 @@ static int rockchip_pinctrl_parse_groups
>  	 * do sanity check and calculate pins number
>  	 */
>  	list = of_get_property(np, "rockchip,pins", &size);
> -	/* we do not check return since it's safe node passed down */
> +	if (!list)
> +		return dev_err_probe(dev, -EINVAL,
> +				     "%pOF: no rockchip,pins property\n", np);
>  	size /= sizeof(*list);
>  	if (!size || size % 4)
>  		return dev_err_probe(dev, -EINVAL,
> 





_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2025-09-07 17:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-03 19:48 [PATCH] pinctrl: rockchip: fix NULL ptr deref in rockchip_pinctrl_parse_groups() Sergey Shtylyov
2025-09-03 19:48 ` Sergey Shtylyov
2025-09-07 17:28 ` Heiko Stuebner [this message]
2025-09-07 17:28   ` Heiko Stuebner
2025-09-08  5:53   ` Chen-Yu Tsai
2025-09-08  5:53     ` Chen-Yu Tsai
2025-09-08 14:36     ` Sergey Shtylyov
2025-09-08 14:36       ` Sergey Shtylyov
2025-09-08 12:59 ` Linus Walleij
2025-09-08 12:59   ` Linus Walleij
2025-10-16  9:29   ` Sergey Shtylyov
2025-10-16  9:29     ` Sergey Shtylyov

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=6789547.RUnXabflUD@phil \
    --to=heiko@sntech.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=s.shtylyov@omp.ru \
    /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.