From: Baruch Siach <baruch@tkos.co.il>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Thomas Gleixner" <tglx@linutronix.de>
Cc: Thierry Reding <thierry.reding@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Andrew Lunn <andrew@lunn.ch>,
Gregory Clement <gregory.clement@bootlin.com>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Chris Packham <chris.packham@alliedtelesis.co.nz>,
Sascha Hauer <s.hauer@pengutronix.de>,
Ralph Sennhauser <ralph.sennhauser@gmail.com>,
linux-pwm@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] gpio: mvebu: fix potential user-after-free on probe
Date: Mon, 30 Nov 2020 20:12:53 +0200 [thread overview]
Message-ID: <878saipvbu.fsf@tarshish> (raw)
In-Reply-To: <20201130153036.p3gdsauxsmas3rbo@pengutronix.de>
Hi Uwe,
(+ tglx)
On Mon, Nov 30 2020, Uwe Kleine-König wrote:
> On Mon, Nov 30, 2020 at 05:09:53PM +0200, Baruch Siach wrote:
>> When mvebu_pwm_probe() fails IRQ domain is not released. Goto the
>> err_domain label on failure to release IRQ domain.
>>
>> Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support")
>> Reported-by: Andrew Lunn <andrew@lunn.ch>
>> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>> ---
>> v2: Don't leak pwm resources (Uwe Kleine-König)
>>
>> This is split out of the "gpio: mvebu: Armada 8K/7K PWM support" series.
>> I'll rebase the series v2 on top on this fix.
>> ---
>> drivers/gpio/gpio-mvebu.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
>> index 433e2c3f3fd5..c53ed975a180 100644
>> --- a/drivers/gpio/gpio-mvebu.c
>> +++ b/drivers/gpio/gpio-mvebu.c
>> @@ -1255,8 +1255,11 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
>> }
>>
>> /* Some MVEBU SoCs have simple PWM support for GPIO lines */
>> - if (IS_ENABLED(CONFIG_PWM))
>> - return mvebu_pwm_probe(pdev, mvchip, id);
>> + if (IS_ENABLED(CONFIG_PWM)) {
>> + err = mvebu_pwm_probe(pdev, mvchip, id);
>> + if (err)
>> + goto err_domain;
>
> I only looked quickly, but I wonder if you need to undo
> irq_alloc_domain_generic_chips(), too?!
So it seems. __irq_alloc_domain_generic_chips() calls kzalloc() for the
gc field of irq_domain. But I could not find any code that releases this
allocation. These drivers call irq_alloc_domain_generic_chips(), but do
not release gc on failure:
drivers/irqchip/irq-ingenic-tcu.c
drivers/irqchip/irq-orion.c
drivers/irqchip/irq-renesas-irqc.c
drivers/irqchip/irq-sunxi-nmi.c
drivers/pinctrl/pinctrl-rockchip.c
Some of them apparently skip the cleanup because the system would be
unusable anyway. But most of them call irq_domain_remove() on failure.
Thomas, what is the right thing to do here? Should we just call
kfree(mvchip->domain->gc);
directly to release the allocation?
Thanks,
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
WARNING: multiple messages have this Message-ID (diff)
From: Baruch Siach <baruch@tkos.co.il>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Thomas Gleixner" <tglx@linutronix.de>
Cc: Andrew Lunn <andrew@lunn.ch>,
Sascha Hauer <s.hauer@pengutronix.de>,
linux-pwm@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>,
Chris Packham <chris.packham@alliedtelesis.co.nz>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Thierry Reding <thierry.reding@gmail.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
linux-gpio@vger.kernel.org,
Ralph Sennhauser <ralph.sennhauser@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
Gregory Clement <gregory.clement@bootlin.com>,
linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH v2] gpio: mvebu: fix potential user-after-free on probe
Date: Mon, 30 Nov 2020 20:12:53 +0200 [thread overview]
Message-ID: <878saipvbu.fsf@tarshish> (raw)
In-Reply-To: <20201130153036.p3gdsauxsmas3rbo@pengutronix.de>
Hi Uwe,
(+ tglx)
On Mon, Nov 30 2020, Uwe Kleine-König wrote:
> On Mon, Nov 30, 2020 at 05:09:53PM +0200, Baruch Siach wrote:
>> When mvebu_pwm_probe() fails IRQ domain is not released. Goto the
>> err_domain label on failure to release IRQ domain.
>>
>> Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support")
>> Reported-by: Andrew Lunn <andrew@lunn.ch>
>> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>> ---
>> v2: Don't leak pwm resources (Uwe Kleine-König)
>>
>> This is split out of the "gpio: mvebu: Armada 8K/7K PWM support" series.
>> I'll rebase the series v2 on top on this fix.
>> ---
>> drivers/gpio/gpio-mvebu.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
>> index 433e2c3f3fd5..c53ed975a180 100644
>> --- a/drivers/gpio/gpio-mvebu.c
>> +++ b/drivers/gpio/gpio-mvebu.c
>> @@ -1255,8 +1255,11 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
>> }
>>
>> /* Some MVEBU SoCs have simple PWM support for GPIO lines */
>> - if (IS_ENABLED(CONFIG_PWM))
>> - return mvebu_pwm_probe(pdev, mvchip, id);
>> + if (IS_ENABLED(CONFIG_PWM)) {
>> + err = mvebu_pwm_probe(pdev, mvchip, id);
>> + if (err)
>> + goto err_domain;
>
> I only looked quickly, but I wonder if you need to undo
> irq_alloc_domain_generic_chips(), too?!
So it seems. __irq_alloc_domain_generic_chips() calls kzalloc() for the
gc field of irq_domain. But I could not find any code that releases this
allocation. These drivers call irq_alloc_domain_generic_chips(), but do
not release gc on failure:
drivers/irqchip/irq-ingenic-tcu.c
drivers/irqchip/irq-orion.c
drivers/irqchip/irq-renesas-irqc.c
drivers/irqchip/irq-sunxi-nmi.c
drivers/pinctrl/pinctrl-rockchip.c
Some of them apparently skip the cleanup because the system would be
unusable anyway. But most of them call irq_domain_remove() on failure.
Thomas, what is the right thing to do here? Should we just call
kfree(mvchip->domain->gc);
directly to release the allocation?
Thanks,
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-30 18:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 15:09 [PATCH v2] gpio: mvebu: fix potential user-after-free on probe Baruch Siach
2020-11-30 15:09 ` Baruch Siach
2020-11-30 15:30 ` Uwe Kleine-König
2020-11-30 15:30 ` Uwe Kleine-König
2020-11-30 18:12 ` Baruch Siach [this message]
2020-11-30 18:12 ` Baruch Siach
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=878saipvbu.fsf@tarshish \
--to=baruch@tkos.co.il \
--cc=andrew@lunn.ch \
--cc=bgolaszewski@baylibre.com \
--cc=chris.packham@alliedtelesis.co.nz \
--cc=gregory.clement@bootlin.com \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=ralph.sennhauser@gmail.com \
--cc=s.hauer@pengutronix.de \
--cc=sebastian.hesselbarth@gmail.com \
--cc=tglx@linutronix.de \
--cc=thierry.reding@gmail.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=u.kleine-koenig@pengutronix.de \
/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.