* [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister
@ 2025-10-24 5:05 Qiu Wenbo
2025-10-24 6:15 ` Andy Shevchenko
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Qiu Wenbo @ 2025-10-24 5:05 UTC (permalink / raw)
To: Daniel Scally, Hans de Goede
Cc: Qiu Wenbo, Qiu Wenbo, platform-driver-x86, linux-kernel,
Ilpo Järvinen , Sakari Ailus, Andy Shevchenko
From: Qiu Wenbo <qiuwenbo@kylinsec.com.cn>
regulator_unregister() already frees the associated GPIO device. On
ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
random failures when other drivers (typically Intel THC) attempt to
allocate interrupts. The root cause is that the reference count of the
pinctrl_intel_platform module unexpectedly drops to zero when this
driver defers its probe.
This behavior can also be reproduced by unloading the module directly.
Fix the issue by removing the redundant release of the GPIO device
during regulator unregistration.
Fixes: 1e5d088a52c2 ("platform/x86: int3472: Stop using devm_gpiod_get()")
Signed-off-by: Qiu Wenbo <qiuwenbo@kylinsec.com.cn>
---
drivers/platform/x86/intel/int3472/clk_and_regulator.c | 5 +----
include/linux/platform_data/x86/int3472.h | 1 -
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/platform/x86/intel/int3472/clk_and_regulator.c b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
index 476ec24d37020..9e052b164a1ab 100644
--- a/drivers/platform/x86/intel/int3472/clk_and_regulator.c
+++ b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
@@ -245,15 +245,12 @@ int skl_int3472_register_regulator(struct int3472_discrete_device *int3472,
if (IS_ERR(regulator->rdev))
return PTR_ERR(regulator->rdev);
- int3472->regulators[int3472->n_regulator_gpios].ena_gpio = gpio;
int3472->n_regulator_gpios++;
return 0;
}
void skl_int3472_unregister_regulator(struct int3472_discrete_device *int3472)
{
- for (int i = 0; i < int3472->n_regulator_gpios; i++) {
+ for (int i = 0; i < int3472->n_regulator_gpios; i++)
regulator_unregister(int3472->regulators[i].rdev);
- gpiod_put(int3472->regulators[i].ena_gpio);
- }
}
diff --git a/include/linux/platform_data/x86/int3472.h b/include/linux/platform_data/x86/int3472.h
index 1571e9157fa50..b1b837583d544 100644
--- a/include/linux/platform_data/x86/int3472.h
+++ b/include/linux/platform_data/x86/int3472.h
@@ -100,7 +100,6 @@ struct int3472_gpio_regulator {
struct regulator_consumer_supply supply_map[GPIO_REGULATOR_SUPPLY_MAP_COUNT * 2];
char supply_name_upper[GPIO_SUPPLY_NAME_LENGTH];
char regulator_name[GPIO_REGULATOR_NAME_LENGTH];
- struct gpio_desc *ena_gpio;
struct regulator_dev *rdev;
struct regulator_desc rdesc;
};
--
2.51.1
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-24 5:05 [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister Qiu Wenbo
@ 2025-10-24 6:15 ` Andy Shevchenko
2025-10-24 7:25 ` Sakari Ailus
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: Andy Shevchenko @ 2025-10-24 6:15 UTC (permalink / raw)
To: Qiu Wenbo
Cc: Daniel Scally, Hans de Goede, Qiu Wenbo, platform-driver-x86,
linux-kernel, Ilpo Järvinen, Sakari Ailus, Andy Shevchenko
On Fri, Oct 24, 2025 at 01:05:37PM +0800, Qiu Wenbo wrote:
>
> regulator_unregister() already frees the associated GPIO device. On
> ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
> random failures when other drivers (typically Intel THC) attempt to
> allocate interrupts. The root cause is that the reference count of the
> pinctrl_intel_platform module unexpectedly drops to zero when this
> driver defers its probe.
>
> This behavior can also be reproduced by unloading the module directly.
>
> Fix the issue by removing the redundant release of the GPIO device
> during regulator unregistration.
>
> Fixes: 1e5d088a52c2 ("platform/x86: int3472: Stop using devm_gpiod_get()")
>
Should not be a blank line here.
> Signed-off-by: Qiu Wenbo <qiuwenbo@kylinsec.com.cn>
> ---
The change sounds reasonable to me. FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-24 5:05 [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister Qiu Wenbo
2025-10-24 6:15 ` Andy Shevchenko
@ 2025-10-24 7:25 ` Sakari Ailus
2025-10-28 6:30 ` [PATCH v2] " Qiu Wenbo
2025-10-28 8:55 ` [PATCH] " Dan Scally
3 siblings, 0 replies; 14+ messages in thread
From: Sakari Ailus @ 2025-10-24 7:25 UTC (permalink / raw)
To: Qiu Wenbo
Cc: Daniel Scally, Hans de Goede, Qiu Wenbo, platform-driver-x86,
linux-kernel, Ilpo Järvinen, Andy Shevchenko
Hi Qiu,
Thanks for the patch.
On Fri, Oct 24, 2025 at 01:05:37PM +0800, Qiu Wenbo wrote:
> From: Qiu Wenbo <qiuwenbo@kylinsec.com.cn>
>
> regulator_unregister() already frees the associated GPIO device. On
> ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
> random failures when other drivers (typically Intel THC) attempt to
> allocate interrupts. The root cause is that the reference count of the
> pinctrl_intel_platform module unexpectedly drops to zero when this
> driver defers its probe.
>
> This behavior can also be reproduced by unloading the module directly.
>
> Fix the issue by removing the redundant release of the GPIO device
> during regulator unregistration.
>
> Fixes: 1e5d088a52c2 ("platform/x86: int3472: Stop using devm_gpiod_get()")
Shouldn't this be also cc'd to stable@
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
--
Regards,
Sakari Ailus
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v2] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-24 5:05 [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister Qiu Wenbo
2025-10-24 6:15 ` Andy Shevchenko
2025-10-24 7:25 ` Sakari Ailus
@ 2025-10-28 6:30 ` Qiu Wenbo
2025-10-28 9:34 ` Hans de Goede
2025-10-28 16:37 ` Ilpo Järvinen
2025-10-28 8:55 ` [PATCH] " Dan Scally
3 siblings, 2 replies; 14+ messages in thread
From: Qiu Wenbo @ 2025-10-28 6:30 UTC (permalink / raw)
To: Daniel Scally, Hans de Goede
Cc: Ilpo Järvinen, Andy Shevchenko, Sakari Ailus,
platform-driver-x86, linux-kernel
From: Qiu Wenbo <qiuwenbo@kylinsec.com.cn>
regulator_unregister() already frees the associated GPIO device. On
ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
random failures when other drivers (typically Intel THC) attempt to
allocate interrupts. The root cause is that the reference count of the
pinctrl_intel_platform module unexpectedly drops to zero when this
driver defers its probe.
This behavior can also be reproduced by unloading the module directly.
Fix the issue by removing the redundant release of the GPIO device
during regulator unregistration.
Cc: stable@vger.kernel.org
Fixes: 1e5d088a52c2 ("platform/x86: int3472: Stop using devm_gpiod_get()")
Signed-off-by: Qiu Wenbo <qiuwenbo@kylinsec.com.cn>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
Changes since V1:
- Add Reviewed-by: from Andy Shevchenko and Sakari Ailus
- Add Cc to stable@
- Remove the blank line after Fixes:
drivers/platform/x86/intel/int3472/clk_and_regulator.c | 5 +----
include/linux/platform_data/x86/int3472.h | 1 -
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/platform/x86/intel/int3472/clk_and_regulator.c b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
index 476ec24d37020..9e052b164a1ab 100644
--- a/drivers/platform/x86/intel/int3472/clk_and_regulator.c
+++ b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
@@ -245,15 +245,12 @@ int skl_int3472_register_regulator(struct int3472_discrete_device *int3472,
if (IS_ERR(regulator->rdev))
return PTR_ERR(regulator->rdev);
- int3472->regulators[int3472->n_regulator_gpios].ena_gpio = gpio;
int3472->n_regulator_gpios++;
return 0;
}
void skl_int3472_unregister_regulator(struct int3472_discrete_device *int3472)
{
- for (int i = 0; i < int3472->n_regulator_gpios; i++) {
+ for (int i = 0; i < int3472->n_regulator_gpios; i++)
regulator_unregister(int3472->regulators[i].rdev);
- gpiod_put(int3472->regulators[i].ena_gpio);
- }
}
diff --git a/include/linux/platform_data/x86/int3472.h b/include/linux/platform_data/x86/int3472.h
index 1571e9157fa50..b1b837583d544 100644
--- a/include/linux/platform_data/x86/int3472.h
+++ b/include/linux/platform_data/x86/int3472.h
@@ -100,7 +100,6 @@ struct int3472_gpio_regulator {
struct regulator_consumer_supply supply_map[GPIO_REGULATOR_SUPPLY_MAP_COUNT * 2];
char supply_name_upper[GPIO_SUPPLY_NAME_LENGTH];
char regulator_name[GPIO_REGULATOR_NAME_LENGTH];
- struct gpio_desc *ena_gpio;
struct regulator_dev *rdev;
struct regulator_desc rdesc;
};
--
2.51.2
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-24 5:05 [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister Qiu Wenbo
` (2 preceding siblings ...)
2025-10-28 6:30 ` [PATCH v2] " Qiu Wenbo
@ 2025-10-28 8:55 ` Dan Scally
2025-10-28 10:02 ` Andy Shevchenko
3 siblings, 1 reply; 14+ messages in thread
From: Dan Scally @ 2025-10-28 8:55 UTC (permalink / raw)
To: Qiu Wenbo, Daniel Scally, Hans de Goede
Cc: Qiu Wenbo, platform-driver-x86, linux-kernel, Ilpo Järvinen,
Sakari Ailus, Andy Shevchenko
Hi Qiu
On 24/10/2025 06:05, Qiu Wenbo wrote:
> From: Qiu Wenbo <qiuwenbo@kylinsec.com.cn>
>
> regulator_unregister() already frees the associated GPIO device. On
> ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
> random failures when other drivers (typically Intel THC) attempt to
> allocate interrupts. The root cause is that the reference count of the
> pinctrl_intel_platform module unexpectedly drops to zero when this
> driver defers its probe.
>
> This behavior can also be reproduced by unloading the module directly.
>
> Fix the issue by removing the redundant release of the GPIO device
> during regulator unregistration.
>
> Fixes: 1e5d088a52c2 ("platform/x86: int3472: Stop using devm_gpiod_get()")
>
> Signed-off-by: Qiu Wenbo <qiuwenbo@kylinsec.com.cn>
> ---
The change looks good to me, so:
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
However the Fixes tag I wonder about; devm_gpiod_get() will also result in a call to gpiod_put()
when the module is unloaded; doesn't that mean that the same issue will occur before that commit?
Thanks
Dan
> drivers/platform/x86/intel/int3472/clk_and_regulator.c | 5 +----
> include/linux/platform_data/x86/int3472.h | 1 -
> 2 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/platform/x86/intel/int3472/clk_and_regulator.c b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> index 476ec24d37020..9e052b164a1ab 100644
> --- a/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> +++ b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> @@ -245,15 +245,12 @@ int skl_int3472_register_regulator(struct int3472_discrete_device *int3472,
> if (IS_ERR(regulator->rdev))
> return PTR_ERR(regulator->rdev);
>
> - int3472->regulators[int3472->n_regulator_gpios].ena_gpio = gpio;
> int3472->n_regulator_gpios++;
> return 0;
> }
>
> void skl_int3472_unregister_regulator(struct int3472_discrete_device *int3472)
> {
> - for (int i = 0; i < int3472->n_regulator_gpios; i++) {
> + for (int i = 0; i < int3472->n_regulator_gpios; i++)
> regulator_unregister(int3472->regulators[i].rdev);
> - gpiod_put(int3472->regulators[i].ena_gpio);
> - }
> }
> diff --git a/include/linux/platform_data/x86/int3472.h b/include/linux/platform_data/x86/int3472.h
> index 1571e9157fa50..b1b837583d544 100644
> --- a/include/linux/platform_data/x86/int3472.h
> +++ b/include/linux/platform_data/x86/int3472.h
> @@ -100,7 +100,6 @@ struct int3472_gpio_regulator {
> struct regulator_consumer_supply supply_map[GPIO_REGULATOR_SUPPLY_MAP_COUNT * 2];
> char supply_name_upper[GPIO_SUPPLY_NAME_LENGTH];
> char regulator_name[GPIO_REGULATOR_NAME_LENGTH];
> - struct gpio_desc *ena_gpio;
> struct regulator_dev *rdev;
> struct regulator_desc rdesc;
> };
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-28 6:30 ` [PATCH v2] " Qiu Wenbo
@ 2025-10-28 9:34 ` Hans de Goede
2025-10-28 16:37 ` Ilpo Järvinen
1 sibling, 0 replies; 14+ messages in thread
From: Hans de Goede @ 2025-10-28 9:34 UTC (permalink / raw)
To: Qiu Wenbo, Daniel Scally
Cc: Ilpo Järvinen, Andy Shevchenko, Sakari Ailus,
platform-driver-x86, linux-kernel
Hi,
On 28-Oct-25 7:30 AM, Qiu Wenbo wrote:
> From: Qiu Wenbo <qiuwenbo@kylinsec.com.cn>
>
> regulator_unregister() already frees the associated GPIO device. On
> ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
> random failures when other drivers (typically Intel THC) attempt to
> allocate interrupts. The root cause is that the reference count of the
> pinctrl_intel_platform module unexpectedly drops to zero when this
> driver defers its probe.
>
> This behavior can also be reproduced by unloading the module directly.
>
> Fix the issue by removing the redundant release of the GPIO device
> during regulator unregistration.
>
> Cc: stable@vger.kernel.org
> Fixes: 1e5d088a52c2 ("platform/x86: int3472: Stop using devm_gpiod_get()")
> Signed-off-by: Qiu Wenbo <qiuwenbo@kylinsec.com.cn>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede <hansg@kernel.org>
Regards,
Hans
> ---
> Changes since V1:
> - Add Reviewed-by: from Andy Shevchenko and Sakari Ailus
> - Add Cc to stable@
> - Remove the blank line after Fixes:
>
> drivers/platform/x86/intel/int3472/clk_and_regulator.c | 5 +----
> include/linux/platform_data/x86/int3472.h | 1 -
> 2 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/platform/x86/intel/int3472/clk_and_regulator.c b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> index 476ec24d37020..9e052b164a1ab 100644
> --- a/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> +++ b/drivers/platform/x86/intel/int3472/clk_and_regulator.c
> @@ -245,15 +245,12 @@ int skl_int3472_register_regulator(struct int3472_discrete_device *int3472,
> if (IS_ERR(regulator->rdev))
> return PTR_ERR(regulator->rdev);
>
> - int3472->regulators[int3472->n_regulator_gpios].ena_gpio = gpio;
> int3472->n_regulator_gpios++;
> return 0;
> }
>
> void skl_int3472_unregister_regulator(struct int3472_discrete_device *int3472)
> {
> - for (int i = 0; i < int3472->n_regulator_gpios; i++) {
> + for (int i = 0; i < int3472->n_regulator_gpios; i++)
> regulator_unregister(int3472->regulators[i].rdev);
> - gpiod_put(int3472->regulators[i].ena_gpio);
> - }
> }
> diff --git a/include/linux/platform_data/x86/int3472.h b/include/linux/platform_data/x86/int3472.h
> index 1571e9157fa50..b1b837583d544 100644
> --- a/include/linux/platform_data/x86/int3472.h
> +++ b/include/linux/platform_data/x86/int3472.h
> @@ -100,7 +100,6 @@ struct int3472_gpio_regulator {
> struct regulator_consumer_supply supply_map[GPIO_REGULATOR_SUPPLY_MAP_COUNT * 2];
> char supply_name_upper[GPIO_SUPPLY_NAME_LENGTH];
> char regulator_name[GPIO_REGULATOR_NAME_LENGTH];
> - struct gpio_desc *ena_gpio;
> struct regulator_dev *rdev;
> struct regulator_desc rdesc;
> };
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-28 8:55 ` [PATCH] " Dan Scally
@ 2025-10-28 10:02 ` Andy Shevchenko
2025-10-28 10:38 ` Hans de Goede
0 siblings, 1 reply; 14+ messages in thread
From: Andy Shevchenko @ 2025-10-28 10:02 UTC (permalink / raw)
To: Dan Scally
Cc: Qiu Wenbo, Daniel Scally, Hans de Goede, Qiu Wenbo,
platform-driver-x86, linux-kernel, Ilpo Järvinen,
Sakari Ailus, Andy Shevchenko
On Tue, Oct 28, 2025 at 08:55:07AM +0000, Dan Scally wrote:
> On 24/10/2025 06:05, Qiu Wenbo wrote:
> >
> > regulator_unregister() already frees the associated GPIO device. On
> > ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
> > random failures when other drivers (typically Intel THC) attempt to
> > allocate interrupts. The root cause is that the reference count of the
> > pinctrl_intel_platform module unexpectedly drops to zero when this
> > driver defers its probe.
> >
> > This behavior can also be reproduced by unloading the module directly.
> >
> > Fix the issue by removing the redundant release of the GPIO device
> > during regulator unregistration.
> >
> > Fixes: 1e5d088a52c2 ("platform/x86: int3472: Stop using devm_gpiod_get()")
> However the Fixes tag I wonder about; devm_gpiod_get() will also result in a
> call to gpiod_put() when the module is unloaded; doesn't that mean that the
> same issue will occur before that commit?
Actually a good question! To me sounds like it's a bug(?) in regulator code.
It must not release resources it didn't acquire. This sounds like a clear
layering violation.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-28 10:02 ` Andy Shevchenko
@ 2025-10-28 10:38 ` Hans de Goede
2025-10-28 10:54 ` Andy Shevchenko
0 siblings, 1 reply; 14+ messages in thread
From: Hans de Goede @ 2025-10-28 10:38 UTC (permalink / raw)
To: Andy Shevchenko, Dan Scally
Cc: Qiu Wenbo, Daniel Scally, Qiu Wenbo, platform-driver-x86,
linux-kernel, Ilpo Järvinen, Sakari Ailus, Andy Shevchenko
Hi,
On 28-Oct-25 11:02 AM, Andy Shevchenko wrote:
> On Tue, Oct 28, 2025 at 08:55:07AM +0000, Dan Scally wrote:
>> On 24/10/2025 06:05, Qiu Wenbo wrote:
>>>
>>> regulator_unregister() already frees the associated GPIO device. On
>>> ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
>>> random failures when other drivers (typically Intel THC) attempt to
>>> allocate interrupts. The root cause is that the reference count of the
>>> pinctrl_intel_platform module unexpectedly drops to zero when this
>>> driver defers its probe.
>>>
>>> This behavior can also be reproduced by unloading the module directly.
>>>
>>> Fix the issue by removing the redundant release of the GPIO device
>>> during regulator unregistration.
>>>
>>> Fixes: 1e5d088a52c2 ("platform/x86: int3472: Stop using devm_gpiod_get()")
>
>> However the Fixes tag I wonder about; devm_gpiod_get() will also result in a
>> call to gpiod_put() when the module is unloaded; doesn't that mean that the
>> same issue will occur before that commit?
>
> Actually a good question! To me sounds like it's a bug(?) in regulator code.
> It must not release resources it didn't acquire. This sounds like a clear
> layering violation.
I think the problem is that when it comes from devicetree it is acquired
by the regulator core. Only when passed as platform-data as we do here does
this layering violation occur.
I do believe that a transfer of ownership ad done here is ok for
the platform-data special case.
Regards,
Hans
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-28 10:38 ` Hans de Goede
@ 2025-10-28 10:54 ` Andy Shevchenko
2025-10-28 11:09 ` Dan Scally
0 siblings, 1 reply; 14+ messages in thread
From: Andy Shevchenko @ 2025-10-28 10:54 UTC (permalink / raw)
To: Hans de Goede
Cc: Dan Scally, Qiu Wenbo, Daniel Scally, Qiu Wenbo,
platform-driver-x86, linux-kernel, Ilpo Järvinen,
Sakari Ailus, Andy Shevchenko
On Tue, Oct 28, 2025 at 11:38:00AM +0100, Hans de Goede wrote:
> On 28-Oct-25 11:02 AM, Andy Shevchenko wrote:
> > On Tue, Oct 28, 2025 at 08:55:07AM +0000, Dan Scally wrote:
> >> On 24/10/2025 06:05, Qiu Wenbo wrote:
> >>>
> >>> regulator_unregister() already frees the associated GPIO device. On
> >>> ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
> >>> random failures when other drivers (typically Intel THC) attempt to
> >>> allocate interrupts. The root cause is that the reference count of the
> >>> pinctrl_intel_platform module unexpectedly drops to zero when this
> >>> driver defers its probe.
> >>>
> >>> This behavior can also be reproduced by unloading the module directly.
> >>>
> >>> Fix the issue by removing the redundant release of the GPIO device
> >>> during regulator unregistration.
> >>>
> >>> Fixes: 1e5d088a52c2 ("platform/x86: int3472: Stop using devm_gpiod_get()")
> >
> >> However the Fixes tag I wonder about; devm_gpiod_get() will also result in a
> >> call to gpiod_put() when the module is unloaded; doesn't that mean that the
> >> same issue will occur before that commit?
> >
> > Actually a good question! To me sounds like it's a bug(?) in regulator code.
> > It must not release resources it didn't acquire. This sounds like a clear
> > layering violation.
>
> I think the problem is that when it comes from devicetree it is acquired
> by the regulator core.
Hmm... I probably missed that, but I failed to see this. Any pointers?
> Only when passed as platform-data as we do here does
> this layering violation occur.
>
> I do believe that a transfer of ownership ad done here is ok for
> the platform-data special case.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-28 10:54 ` Andy Shevchenko
@ 2025-10-28 11:09 ` Dan Scally
2025-10-28 11:38 ` Andy Shevchenko
0 siblings, 1 reply; 14+ messages in thread
From: Dan Scally @ 2025-10-28 11:09 UTC (permalink / raw)
To: Andy Shevchenko, Hans de Goede
Cc: Qiu Wenbo, Daniel Scally, Qiu Wenbo, platform-driver-x86,
linux-kernel, Ilpo Järvinen, Sakari Ailus, Andy Shevchenko
On 28/10/2025 10:54, Andy Shevchenko wrote:
> On Tue, Oct 28, 2025 at 11:38:00AM +0100, Hans de Goede wrote:
>> On 28-Oct-25 11:02 AM, Andy Shevchenko wrote:
>>> On Tue, Oct 28, 2025 at 08:55:07AM +0000, Dan Scally wrote:
>>>> On 24/10/2025 06:05, Qiu Wenbo wrote:
>>>>>
>>>>> regulator_unregister() already frees the associated GPIO device. On
>>>>> ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
>>>>> random failures when other drivers (typically Intel THC) attempt to
>>>>> allocate interrupts. The root cause is that the reference count of the
>>>>> pinctrl_intel_platform module unexpectedly drops to zero when this
>>>>> driver defers its probe.
>>>>>
>>>>> This behavior can also be reproduced by unloading the module directly.
>>>>>
>>>>> Fix the issue by removing the redundant release of the GPIO device
>>>>> during regulator unregistration.
>>>>>
>>>>> Fixes: 1e5d088a52c2 ("platform/x86: int3472: Stop using devm_gpiod_get()")
>>>
>>>> However the Fixes tag I wonder about; devm_gpiod_get() will also result in a
>>>> call to gpiod_put() when the module is unloaded; doesn't that mean that the
>>>> same issue will occur before that commit?
>>>
>>> Actually a good question! To me sounds like it's a bug(?) in regulator code.
>>> It must not release resources it didn't acquire. This sounds like a clear
>>> layering violation.
>>
>> I think the problem is that when it comes from devicetree it is acquired
>> by the regulator core.
>
> Hmm... I probably missed that, but I failed to see this. Any pointers?
They can come through the struct regulator_desc.of_parse_cb(), which is called in
regulator_of_init_data(), from regulator_register(). For example:
https://elixir.bootlin.com/linux/v6.17.5/source/drivers/power/supply/mt6370-charger.c#L234>
>> Only when passed as platform-data as we do here does
>> this layering violation occur.
>>
>> I do believe that a transfer of ownership ad done here is ok for
>> the platform-data special case.
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-28 11:09 ` Dan Scally
@ 2025-10-28 11:38 ` Andy Shevchenko
2025-10-28 14:36 ` Hans de Goede
0 siblings, 1 reply; 14+ messages in thread
From: Andy Shevchenko @ 2025-10-28 11:38 UTC (permalink / raw)
To: Dan Scally
Cc: Hans de Goede, Qiu Wenbo, Daniel Scally, Qiu Wenbo,
platform-driver-x86, linux-kernel, Ilpo Järvinen,
Sakari Ailus, Andy Shevchenko
On Tue, Oct 28, 2025 at 11:09:12AM +0000, Dan Scally wrote:
> On 28/10/2025 10:54, Andy Shevchenko wrote:
> > On Tue, Oct 28, 2025 at 11:38:00AM +0100, Hans de Goede wrote:
> > > On 28-Oct-25 11:02 AM, Andy Shevchenko wrote:
> > > > On Tue, Oct 28, 2025 at 08:55:07AM +0000, Dan Scally wrote:
> > > > > On 24/10/2025 06:05, Qiu Wenbo wrote:
...
> > > > > However the Fixes tag I wonder about; devm_gpiod_get() will also result in a
> > > > > call to gpiod_put() when the module is unloaded; doesn't that mean that the
> > > > > same issue will occur before that commit?
> > > >
> > > > Actually a good question! To me sounds like it's a bug(?) in regulator code.
> > > > It must not release resources it didn't acquire. This sounds like a clear
> > > > layering violation.
> > >
> > > I think the problem is that when it comes from devicetree it is acquired
> > > by the regulator core.
> >
> > Hmm... I probably missed that, but I failed to see this. Any pointers?
>
> They can come through the struct regulator_desc.of_parse_cb(), which is called in
> regulator_of_init_data(), from regulator_register(). For example: https://elixir.bootlin.com/linux/v6.17.5/source/drivers/power/supply/mt6370-charger.c#L234>
Ah, thank you, Dan, for the pointers. Indeed, that's how it's done. Hmm, still
why can't we let the regulator consumer to decide when to clean the resource?
I think this is an attempt to have a refcounting against shared GPIO resource
and it should be done in the GPIOLIB (if not yet). In regulator that put
call should probably be conditional (based on the source of GPIO request).
> > > Only when passed as platform-data as we do here does
> > > this layering violation occur.
> > >
> > > I do believe that a transfer of ownership ad done here is ok for
> > > the platform-data special case.
As an exception, maybe...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-28 11:38 ` Andy Shevchenko
@ 2025-10-28 14:36 ` Hans de Goede
2025-10-28 14:47 ` Andy Shevchenko
0 siblings, 1 reply; 14+ messages in thread
From: Hans de Goede @ 2025-10-28 14:36 UTC (permalink / raw)
To: Andy Shevchenko, Dan Scally
Cc: Qiu Wenbo, Daniel Scally, Qiu Wenbo, platform-driver-x86,
linux-kernel, Ilpo Järvinen, Sakari Ailus, Andy Shevchenko
Hi,
On 28-Oct-25 12:38 PM, Andy Shevchenko wrote:
> On Tue, Oct 28, 2025 at 11:09:12AM +0000, Dan Scally wrote:
>> On 28/10/2025 10:54, Andy Shevchenko wrote:
>>> On Tue, Oct 28, 2025 at 11:38:00AM +0100, Hans de Goede wrote:
>>>> On 28-Oct-25 11:02 AM, Andy Shevchenko wrote:
>>>>> On Tue, Oct 28, 2025 at 08:55:07AM +0000, Dan Scally wrote:
>>>>>> On 24/10/2025 06:05, Qiu Wenbo wrote:
>
> ...
>
>>>>>> However the Fixes tag I wonder about; devm_gpiod_get() will also result in a
>>>>>> call to gpiod_put() when the module is unloaded; doesn't that mean that the
>>>>>> same issue will occur before that commit?
>>>>>
>>>>> Actually a good question! To me sounds like it's a bug(?) in regulator code.
>>>>> It must not release resources it didn't acquire. This sounds like a clear
>>>>> layering violation.
>>>>
>>>> I think the problem is that when it comes from devicetree it is acquired
>>>> by the regulator core.
>>>
>>> Hmm... I probably missed that, but I failed to see this. Any pointers?
>>
>> They can come through the struct regulator_desc.of_parse_cb(), which is called in
>> regulator_of_init_data(), from regulator_register(). For example: https://elixir.bootlin.com/linux/v6.17.5/source/drivers/power/supply/mt6370-charger.c#L234>
>
> Ah, thank you, Dan, for the pointers. Indeed, that's how it's done. Hmm, still
> why can't we let the regulator consumer to decide when to clean the resource?
> I think this is an attempt to have a refcounting against shared GPIO resource
> and it should be done in the GPIOLIB (if not yet). In regulator that put
> call should probably be conditional (based on the source of GPIO request).
Fixing this sounds like a somewhat big undertaking. In the mean time
I think we should move forward with this patch to fix the immediate
issue with the double free.
Regards,
Hans
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-28 14:36 ` Hans de Goede
@ 2025-10-28 14:47 ` Andy Shevchenko
0 siblings, 0 replies; 14+ messages in thread
From: Andy Shevchenko @ 2025-10-28 14:47 UTC (permalink / raw)
To: Hans de Goede
Cc: Dan Scally, Qiu Wenbo, Daniel Scally, Qiu Wenbo,
platform-driver-x86, linux-kernel, Ilpo Järvinen,
Sakari Ailus, Andy Shevchenko
On Tue, Oct 28, 2025 at 03:36:56PM +0100, Hans de Goede wrote:
> On 28-Oct-25 12:38 PM, Andy Shevchenko wrote:
> > On Tue, Oct 28, 2025 at 11:09:12AM +0000, Dan Scally wrote:
> >> On 28/10/2025 10:54, Andy Shevchenko wrote:
> >>> On Tue, Oct 28, 2025 at 11:38:00AM +0100, Hans de Goede wrote:
> >>>> On 28-Oct-25 11:02 AM, Andy Shevchenko wrote:
> >>>>> On Tue, Oct 28, 2025 at 08:55:07AM +0000, Dan Scally wrote:
> >>>>>> On 24/10/2025 06:05, Qiu Wenbo wrote:
...
> >>>>>> However the Fixes tag I wonder about; devm_gpiod_get() will also result in a
> >>>>>> call to gpiod_put() when the module is unloaded; doesn't that mean that the
> >>>>>> same issue will occur before that commit?
> >>>>>
> >>>>> Actually a good question! To me sounds like it's a bug(?) in regulator code.
> >>>>> It must not release resources it didn't acquire. This sounds like a clear
> >>>>> layering violation.
> >>>>
> >>>> I think the problem is that when it comes from devicetree it is acquired
> >>>> by the regulator core.
> >>>
> >>> Hmm... I probably missed that, but I failed to see this. Any pointers?
> >>
> >> They can come through the struct regulator_desc.of_parse_cb(), which is called in
> >> regulator_of_init_data(), from regulator_register(). For example: https://elixir.bootlin.com/linux/v6.17.5/source/drivers/power/supply/mt6370-charger.c#L234>
> >
> > Ah, thank you, Dan, for the pointers. Indeed, that's how it's done. Hmm, still
> > why can't we let the regulator consumer to decide when to clean the resource?
> > I think this is an attempt to have a refcounting against shared GPIO resource
> > and it should be done in the GPIOLIB (if not yet). In regulator that put
> > call should probably be conditional (based on the source of GPIO request).
>
> Fixing this sounds like a somewhat big undertaking. In the mean time
> I think we should move forward with this patch to fix the immediate
> issue with the double free.
And I am not objecting to apply this as you may see in the tags given so far.
In regard to the undertaking it seems in Bart's (GPIOLIB maintainer) TODO list.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] platform/x86: int3472: Fix double free of GPIO device during unregister
2025-10-28 6:30 ` [PATCH v2] " Qiu Wenbo
2025-10-28 9:34 ` Hans de Goede
@ 2025-10-28 16:37 ` Ilpo Järvinen
1 sibling, 0 replies; 14+ messages in thread
From: Ilpo Järvinen @ 2025-10-28 16:37 UTC (permalink / raw)
To: Daniel Scally, Hans de Goede, Qiu Wenbo
Cc: Andy Shevchenko, Sakari Ailus, platform-driver-x86, linux-kernel
On Tue, 28 Oct 2025 14:30:09 +0800, Qiu Wenbo wrote:
> regulator_unregister() already frees the associated GPIO device. On
> ThinkPad X9 (Lunar Lake), this causes a double free issue that leads to
> random failures when other drivers (typically Intel THC) attempt to
> allocate interrupts. The root cause is that the reference count of the
> pinctrl_intel_platform module unexpectedly drops to zero when this
> driver defers its probe.
>
> [...]
Thank you for your contribution, it has been applied to my local
review-ilpo-fixes branch. Note it will show up in the public
platform-drivers-x86/review-ilpo-fixes branch only once I've pushed my
local branch there, which might take a while.
The list of commits applied:
[1/1] platform/x86: int3472: Fix double free of GPIO device during unregister
commit: f0f7a3f542c1698edb69075f25a3f846207facba
--
i.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2025-10-28 16:37 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-24 5:05 [PATCH] platform/x86: int3472: Fix double free of GPIO device during unregister Qiu Wenbo
2025-10-24 6:15 ` Andy Shevchenko
2025-10-24 7:25 ` Sakari Ailus
2025-10-28 6:30 ` [PATCH v2] " Qiu Wenbo
2025-10-28 9:34 ` Hans de Goede
2025-10-28 16:37 ` Ilpo Järvinen
2025-10-28 8:55 ` [PATCH] " Dan Scally
2025-10-28 10:02 ` Andy Shevchenko
2025-10-28 10:38 ` Hans de Goede
2025-10-28 10:54 ` Andy Shevchenko
2025-10-28 11:09 ` Dan Scally
2025-10-28 11:38 ` Andy Shevchenko
2025-10-28 14:36 ` Hans de Goede
2025-10-28 14:47 ` Andy Shevchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox