[PATCH 6.6.y 0/2] gpio: backport CVE-2026-53226, CVE-2026-64241

[PATCH 6.6.y 0/2] gpio: backport CVE-2026-53226, CVE-2026-64241

[Artem Dinaburg]

Hi Greg, Sasha, and maintainers,

I'm working through the smaller CVE backports still missing from 6.6.y.
These 2 upstream changes belong together for CVE-2026-53226,
CVE-2026-64241. They must be applied in this order because the later change
depends on or completes the earlier one.

The complete series is already present in 6.12.y, 6.18.y, and 7.2.y.

Could you please consider this series for 6.6.y?

Thanks,
Artem Dinaburg

Series:
  1. gpio: rockchip: teardown bugs and resource leaks
  2. gpio: rockchip: fix generic IRQ chip leak on remove

base: v6.6.157 (79643295eba17affbd16ca97f3ef04c90266b28c) plus stable-queue
revision 958ddf240a33ef26b1771be944f0ea6c3b597472

[PATCH 6.6.y 1/2] gpio: rockchip: teardown bugs and resource leaks

[Artem Dinaburg]

From: Marco Scardovi <scardracs@disroot.org>

[ Upstream commit 9500077678230e36d22bf16d2b9539c13e59a801 ]

Address several teardown issues and resource leaks in the driver's remove
path and error handling:

1. Debounce clock reference leak: The debounce clock (bank->db_clk) is
   obtained using of_clk_get() which increments the clock's reference
   count, but clk_put() is never called. Register a devm action to
   cleanly release it on unbind. Note that of_clk_get(..., 1) remains
   necessary over devm_clk_get() because the DT binding does not define
   clock-names, precluding name-based lookup.

2. Unregistered chained IRQ handler: The chained IRQ handler is not
   disconnected in remove(). If a stray interrupt fires after the driver
   is removed, the kernel attempts to execute a stale handler, leading
   to a panic. Fix this by clearing the handler in remove().

3. IRQ domain leak: The linear IRQ domain and its generic chips are
   allocated manually during probe but never removed. Remove the IRQ
   domain during driver teardown to free the associated generic chips
   and mappings.

[ Backport to 6.6.y: For 6.6.y, send with 1c1e0fc88d6e (CVE-2026-53226)
  so generic chips are explicitly removed before irq_domain_remove().
  6.1.y lacks irq_domain_remove_generic_chips(), so it needs a
  separately reviewed older generic-chip teardown backport. ]

Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio")
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Link: https://patch.msgid.link/20260526171050.12785-3-scardracs@disroot.org
[Bartosz: don't emit an error message on devres allocation failure]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Assisted-by: LLM
Signed-off-by: Artem Dinaburg <artem@trailofbits.com>
---
This is patch 1 of 2 in the ordered 6.6.y backport series.
This change addresses CVE-2026-64241. Releases the debounce-clock
reference, disconnects the chained IRQ handler, and removes the IRQ domain
during driver teardown.

The fix is already present in 6.12.y, 6.18.y, and 7.2.y, but not in 6.6.y.

 drivers/gpio/gpio-rockchip.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-rockchip.c b/drivers/gpio/gpio-rockchip.c
index ff9a4b8611d7..e0e4f3ed5fdd 100644
--- a/drivers/gpio/gpio-rockchip.c
+++ b/drivers/gpio/gpio-rockchip.c
@@ -629,10 +629,17 @@ static int rockchip_gpiolib_register(struct rockchip_pin_bank *bank)
 	return ret;
 }
 
+static void rockchip_clk_put(void *data)
+{
+	struct clk *clk = data;
+
+	clk_put(clk);
+}
+
 static int rockchip_get_bank_data(struct rockchip_pin_bank *bank)
 {
 	struct resource res;
-	int id = 0;
+	int id = 0, ret;
 
 	if (of_address_to_resource(bank->of_node, 0, &res)) {
 		dev_err(bank->dev, "cannot find IO resource for bank\n");
@@ -662,6 +669,11 @@ static int rockchip_get_bank_data(struct rockchip_pin_bank *bank)
 			dev_err(bank->dev, "cannot find debounce clk\n");
 			return -EINVAL;
 		}
+
+		ret = devm_add_action_or_reset(bank->dev, rockchip_clk_put,
+					       bank->db_clk);
+		if (ret)
+			return ret;
 	} else {
 		bank->gpio_regs = &gpio_regs_v1;
 		bank->gpio_type = GPIO_TYPE_V1;
@@ -773,6 +785,9 @@ static int rockchip_gpio_remove(struct platform_device *pdev)
 {
 	struct rockchip_pin_bank *bank = platform_get_drvdata(pdev);
 
+	irq_set_chained_handler_and_data(bank->irq, NULL, NULL);
+	if (bank->domain)
+		irq_domain_remove(bank->domain);
 	gpiochip_remove(&bank->gpio_chip);
 
 	return 0;
-- 
2.39.5

[PATCH 6.6.y 2/2] gpio: rockchip: fix generic IRQ chip leak on remove

[Artem Dinaburg]

From: Marco Scardovi <scardracs@disroot.org>

[ Upstream commit 1c1e0fc88d6ef65bf15d517853251f75ab9d18c3 ]

The driver allocates domain generic chips using
irq_alloc_domain_generic_chips() during probe. However, on driver
remove/teardown, the generic chips are not automatically freed when the
IRQ domain is removed because the domain flags do not include
IRQ_DOMAIN_FLAG_DESTROY_GC.

This causes both the domain generic chips structure and the associated
generic chips to be leaked. Additionally, the generic chips remain on
the global gc_list and may later be visited by generic IRQ chip suspend,
resume, or shutdown callbacks after the GPIO bank has been removed,
potentially resulting in a use-after-free and kernel crash.

Fix the resource leak by explicitly calling
irq_domain_remove_generic_chips() before removing the IRQ domain in
rockchip_gpio_remove().

[ Backport to 6.6.y: Use the upstream teardown helper on 6.6. Defer 6.1
  because irq_domain_remove_generic_chips() is absent and needs a
  prerequisite or reviewed target-native cleanup. ]

Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio")
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
Link: https://patch.msgid.link/20260607230504.35392-2-scardracs@disroot.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Assisted-by: LLM
Signed-off-by: Artem Dinaburg <artem@trailofbits.com>
---
This is patch 2 of 2 in the ordered 6.6.y backport series.
This change addresses CVE-2026-53226. The target creates generic IRQ chips
and omits their removal; the prerequisite supplies a complete teardown
helper and the CVE fix invokes it before removing the IRQ domain.

The fix is already present in 6.12.y, 6.18.y, and 7.2.y, but not in 6.6.y.

 drivers/gpio/gpio-rockchip.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-rockchip.c b/drivers/gpio/gpio-rockchip.c
index e0e4f3ed5fdd..86cf3cbcdb40 100644
--- a/drivers/gpio/gpio-rockchip.c
+++ b/drivers/gpio/gpio-rockchip.c
@@ -786,8 +786,10 @@ static int rockchip_gpio_remove(struct platform_device *pdev)
 	struct rockchip_pin_bank *bank = platform_get_drvdata(pdev);
 
 	irq_set_chained_handler_and_data(bank->irq, NULL, NULL);
-	if (bank->domain)
+	if (bank->domain) {
+		irq_domain_remove_generic_chips(bank->domain);
 		irq_domain_remove(bank->domain);
+	}
 	gpiochip_remove(&bank->gpio_chip);
 
 	return 0;
-- 
2.39.5

Re: [PATCH 6.6.y 1/2] gpio: rockchip: teardown bugs and resource leaks

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] gpio: rockchip: UAF in rockchip_gpio_to_irq due to dangling bank->domain
- [Medium] gpio: rockchip: clk_put() on prepared debounce clock triggers WARN_ON_ONCE
--

commit 02053f662558738041ac46d1ce4ccf500e2ba8c2
Author: Marco Scardovi <scardracs@disroot.org>

gpio: rockchip: teardown bugs and resource leaks

This commit addresses several teardown issues and resource leaks in the
driver's remove path and error handling. It registers a devm action to
release the debounce clock, clears the chained IRQ handler in remove(),
and removes the IRQ domain during driver teardown.

Link: https://patch.msgid.link/20260526171050.12785-3-scardracs@disroot.org

> diff --git a/drivers/gpio/gpio-rockchip.c b/drivers/gpio/gpio-rockchip.c
> index ff9a4b8611d7f..e0e4f3ed5fdd4 100644
> --- a/drivers/gpio/gpio-rockchip.c
> +++ b/drivers/gpio/gpio-rockchip.c
> @@ -629,10 +629,17 @@ static int rockchip_gpiolib_register(struct rockchip_pin_bank *bank)
>  	return ret;
>  }
>  
> +static void rockchip_clk_put(void *data)
> +{
> +	struct clk *clk = data;
> +
> +	clk_put(clk);
> +}

[Severity: Medium]
Does this code trigger a warning if the debounce clock is still prepared
and enabled?

If a GPIO line is configured with debounce, it enables the clock:

rockchip_gpio_set_debounce() {
	...
	if (debounce)
		clk_prepare_enable(bank->db_clk);
	...
}

If the driver is unbound while debounce is still active, this devm action
calls clk_put() without unpreparing or disabling the clock first. This
triggers a warning in the clock framework because the active prepare count
is unbalanced.

[ ... ]

> @@ -773,6 +785,9 @@ static int rockchip_gpio_remove(struct platform_device *pdev)
>  {
>  	struct rockchip_pin_bank *bank = platform_get_drvdata(pdev);
>  
> +	irq_set_chained_handler_and_data(bank->irq, NULL, NULL);
> +	if (bank->domain)
> +		irq_domain_remove(bank->domain);

[Severity: High]
Does this cause a use-after-free if another thread tries to map an IRQ
during driver unbind?

The IRQ domain is freed before the GPIO chip is removed, and bank->domain
is never set to NULL. If a concurrent call to gpiod_to_irq() occurs:

rockchip_gpio_to_irq() {
	...
	if (!bank->domain)
		return -ENXIO;
	...
	virq = irq_create_mapping(bank->domain, offset);
	...
}

It bypasses the NULL check and accesses the freed domain memory.

Could this also cause a use-after-free during driver rebind?

If the driver is unbound and then bound again, rockchip_gpiolib_register()
calls gpiochip_add_data() before the new IRQ domain is allocated. A
concurrent call to gpiod_to_irq() during this probe window would see the
stale, dangling bank->domain pointer from the previous unbind and attempt
to use it.

>  	gpiochip_remove(&bank->gpio_chip);
>  
>  	return 0;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008191824.98662-1-artem@trailofbits.com?part=1

Re: [PATCH 6.6.y 2/2] gpio: rockchip: fix generic IRQ chip leak on remove

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] gpio: rockchip: UAF in rockchip_gpio_to_irq due to teardown order
- [High] gpio: rockchip: missing irq mapping disposal causes UAF
--

commit 7ad98fc33c5f3a1c30b1b0722c11e01bbf5172c9
Author: Marco Scardovi <scardracs@disroot.org>
Subject: gpio: rockchip: fix generic IRQ chip leak on remove

This patch addresses a resource leak by explicitly removing the generic
chips and the IRQ domain in rockchip_gpio_remove().

Link: https://patch.msgid.link/20260607230504.35392-2-scardracs@disroot.org

> diff --git a/drivers/gpio/gpio-rockchip.c b/drivers/gpio/gpio-rockchip.c
> index e0e4f3ed5fdd4..86cf3cbcdb403 100644
> --- a/drivers/gpio/gpio-rockchip.c
> +++ b/drivers/gpio/gpio-rockchip.c
> @@ -786,8 +786,10 @@ static int rockchip_gpio_remove(struct platform_device *pdev)
>  	struct rockchip_pin_bank *bank = platform_get_drvdata(pdev);
>  
>  	irq_set_chained_handler_and_data(bank->irq, NULL, NULL);
> -	if (bank->domain)
> +	if (bank->domain) {
> +		irq_domain_remove_generic_chips(bank->domain);
>  		irq_domain_remove(bank->domain);

[Severity: High]
Does removing the IRQ domain before calling gpiochip_remove() introduce a
use-after-free race condition?

Because the GPIO chip is still registered and active in gpiolib, concurrent
operations (like a sysfs write configuring an edge trigger) can still invoke
gpiod_to_irq(). This triggers the driver's .to_irq callback:

rockchip_gpio_to_irq() {
    ...
    virq = irq_create_mapping(bank->domain, offset);
    ...
}

Since bank->domain has already been freed, this will dereference a dangling
pointer. Would reversing the teardown order to call gpiochip_remove() before
freeing the domain unregister sysfs nodes, drain pending operations, and
safely close this race window?

[Severity: High]
Does removing the IRQ domain here without disposing of active mappings leak
those mappings and cause a use-after-free in the core IRQ subsystem?

When the domain is removed without iterating over active pins to call
irq_dispose_mapping(), the core IRQ code hits a warning:

irq_domain_remove() {
    ...
    WARN_ON(!radix_tree_empty(&domain->revmap_tree));
    ...
    irq_domain_free(domain);
}

Active IRQ descriptors will retain a dangling pointer to the freed domain in
their irq_data->domain fields. When consumer drivers subsequently unbind and
free their IRQ, irq_dispose_mapping() accesses the freed domain pointer to
check hierarchy flags, leading to a crash.

Should the active mappings be disposed of before removing the domain?

> +	}
>  	gpiochip_remove(&bank->gpio_chip);
>  
>  	return 0;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261008191824.98662-1-artem@trailofbits.com?part=2

Re: [PATCH 6.6.y 0/2] gpio: backport CVE-2026-53226, CVE-2026-64241

[Sasha Levin]

> Could you please consider this series for 6.6.y?

Queued the series for 6.6, thanks.

-- 
Thanks,
Sasha