[PATCH 0/2] gpio: core: fix const-correctness and remove UAF FIXMEs

[PATCH 0/2] gpio: core: fix const-correctness and remove UAF FIXMEs

[Marco Scardovi (scardracs)]

This series addresses legacy "FIXME Cannot use gpio_chip_guard due to
const desc" comments and open-coded SRCU locks scattered throughout the
gpiolib core and backend lookup paths.

I am aware of the ongoing work to replace the gpio_chip_guard architecture
entirely (see the "revocable objects" patchset discussion at
https://lore.kernel.org/linux-gpio/20260513091043.6766-1-tzungbi@kernel.org/).
While that broader refactoring is being iterated upon, this patch series
provides a simple, completely type-safe fix utilizing the existing SRCU
guard infrastructure. It can be merged today to eliminate the FIXMEs
without conflicting conceptually with future revocable objects.

For clarity during review, the series relies on the following guarantees:

1. Deep Const-Correctness is Preserved:
Updating DEFINE_CLASS(gpio_chip_guard, ...) to accept a `const struct
gpio_desc *desc` does not drop const qualifiers. In C, const-propagation
does not implicitly const-qualify deep pointers. The `desc->gdev` evaluation
yields a mutable `struct gpio_device *`, making the internal guard
assignment perfectly legal and safe for fast-path read operations.

2. Identical SRCU Lifetime Scope:
The DEFINE_CLASS macro's GNU C compound statement `({ ... })` relies
on strict sequence points. Thus, `srcu_read_lock()` is fully acquired
prior to executing `srcu_dereference()`. The guard's lifetime remains
identically bound to the block scope, exactly mirroring the open-coded
`guard(srcu)(&gdev->srcu)` it replaces.

3. Lookup UAF FIXMEs are Architecturally Obsolete:
The FIXME comments removed in the ACPI and swnode backend lookup paths
(warning about dropping the device reference) are functionally obsolete.
By design, `gpiod_find_and_request()` wraps the entire backend lookup
operation inside the global `gpio_devices_srcu` read lock. The lookup
functions are entirely safe to drop their temporary references since the
caller subsequently takes its own permanent references without ever leaving
the SRCU read-side critical section.

Please note that while this patch provides a good solution to clean up the
existing codebase, I fully understand the necessity of deeper and more
radical modifications to robustly secure the subsystem's future.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>

Marco Scardovi (scardracs) (2):
  gpio: core: fix const-correctness of gpio_chip_guard
  gpio: remove obsolete UAF FIXMEs from lookup paths

 drivers/gpio/gpiolib-acpi-core.c |  4 ----
 drivers/gpio/gpiolib-swnode.c    |  4 ----
 drivers/gpio/gpiolib.c           | 28 ++++++++--------------------
 drivers/gpio/gpiolib.h           |  2 +-
 4 files changed, 9 insertions(+), 29 deletions(-)

-- 
2.54.0

[PATCH 1/2] gpio: core: fix const-correctness of gpio_chip_guard

[Marco Scardovi (scardracs)]

The DEFINE_CLASS macro for gpio_chip_guard currently expects a non-const
struct gpio_desc pointer. This prevents the guard from being used cleanly
in fast paths that receive a const descriptor, forcing developers to fall
back to open-coding the SRCU locks.

Update the macro to accept a const struct gpio_desc pointer. This is valid
because the actual targeted gpio_device pointer assignment does not drop
const qualifiers on the target structure.

Convert the open-coded SRCU locks in gpiod_get_raw_value_commit() and
gpiod_to_irq() to use the guard, removing their legacy FIXME comments.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
---
 drivers/gpio/gpiolib.c | 28 ++++++++--------------------
 drivers/gpio/gpiolib.h |  2 +-
 2 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 69743d6deeaf..6b0c6e8abf7b 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -3428,20 +3428,13 @@ static int gpio_chip_get_value(struct gpio_chip *gc, const struct gpio_desc *des
 
 static int gpiod_get_raw_value_commit(const struct gpio_desc *desc)
 {
-	struct gpio_device *gdev;
-	struct gpio_chip *gc;
 	int value;
 
-	/* FIXME Unable to use gpio_chip_guard due to const desc. */
-	gdev = desc->gdev;
-
-	guard(srcu)(&gdev->srcu);
-
-	gc = srcu_dereference(gdev->chip, &gdev->srcu);
-	if (!gc)
+	CLASS(gpio_chip_guard, guard)(desc);
+	if (!guard.gc)
 		return -ENODEV;
 
-	value = gpio_chip_get_value(gc, desc);
+	value = gpio_chip_get_value(guard.gc, desc);
 	value = value < 0 ? value : !!value;
 	trace_gpio_value(desc_to_gpio(desc), 1, value);
 	return value;
@@ -4148,8 +4141,6 @@ EXPORT_SYMBOL_GPL(gpiod_is_shared);
  */
 int gpiod_to_irq(const struct gpio_desc *desc)
 {
-	struct gpio_device *gdev;
-	struct gpio_chip *gc;
 	int offset;
 	int ret;
 
@@ -4157,16 +4148,13 @@ int gpiod_to_irq(const struct gpio_desc *desc)
 	if (ret <= 0)
 		return -EINVAL;
 
-	gdev = desc->gdev;
-	/* FIXME Cannot use gpio_chip_guard due to const desc. */
-	guard(srcu)(&gdev->srcu);
-	gc = srcu_dereference(gdev->chip, &gdev->srcu);
-	if (!gc)
+	CLASS(gpio_chip_guard, guard)(desc);
+	if (!guard.gc)
 		return -ENODEV;
 
 	offset = gpiod_hwgpio(desc);
-	if (gc->to_irq) {
-		ret = gc->to_irq(gc, offset);
+	if (guard.gc->to_irq) {
+		ret = guard.gc->to_irq(guard.gc, offset);
 		if (ret)
 			return ret;
 
@@ -4174,7 +4162,7 @@ int gpiod_to_irq(const struct gpio_desc *desc)
 		return -ENXIO;
 	}
 #ifdef CONFIG_GPIOLIB_IRQCHIP
-	if (gc->irq.chip) {
+	if (guard.gc->irq.chip) {
 		/*
 		 * Avoid race condition with other code, which tries to lookup
 		 * an IRQ before the irqchip has been properly registered,
diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h
index dc4cb61a9318..650a702741df 100644
--- a/drivers/gpio/gpiolib.h
+++ b/drivers/gpio/gpiolib.h
@@ -244,7 +244,7 @@ DEFINE_CLASS(gpio_chip_guard,
 
 		_guard;
 	     }),
-	     struct gpio_desc *desc)
+	     const struct gpio_desc *desc)
 
 int gpiod_request(struct gpio_desc *desc, const char *label);
 int gpiod_request_commit(struct gpio_desc *desc, const char *label);
-- 
2.54.0

[PATCH 2/2] gpio: remove obsolete UAF FIXMEs from lookup paths

[Marco Scardovi (scardracs)]

The ACPI and swnode GPIO lookup backends both temporarily grab a reference
to the gpio_device, resolve the descriptor, and then drop the reference
before returning the descriptor to the caller. They carry FIXME comments
warning that the descriptor is being returned without its backing device
reference.

However, the gpiod_find_and_request() core functionally prevents any
use-after-free window by wrapping the entire lookup operation inside the
gpio_devices_srcu read lock. The lookup functions are correct to drop
their references since the caller (gpiod_request) will subsequently take
its own permanent module and device references safely.

Remove these obsolete FIXMEs to prevent misleading future subsystem
developers.

Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Marco Scardovi <scardracs@disroot.org>
---
 drivers/gpio/gpiolib-acpi-core.c | 4 ----
 drivers/gpio/gpiolib-swnode.c    | 4 ----
 2 files changed, 8 deletions(-)

diff --git a/drivers/gpio/gpiolib-acpi-core.c b/drivers/gpio/gpiolib-acpi-core.c
index eb8a40cfb7a9..1a762a2988b7 100644
--- a/drivers/gpio/gpiolib-acpi-core.c
+++ b/drivers/gpio/gpiolib-acpi-core.c
@@ -142,10 +142,6 @@ static struct gpio_desc *acpi_get_gpiod(char *path, unsigned int pin)
 	if (!gdev)
 		return ERR_PTR(-EPROBE_DEFER);
 
-	/*
-	 * FIXME: keep track of the reference to the GPIO device somehow
-	 * instead of putting it here.
-	 */
 	return gpio_device_get_desc(gdev, pin);
 }
 
diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c
index 4374067f621e..8d9591aa9304 100644
--- a/drivers/gpio/gpiolib-swnode.c
+++ b/drivers/gpio/gpiolib-swnode.c
@@ -114,10 +114,6 @@ struct gpio_desc *swnode_find_gpio(struct fwnode_handle *fwnode,
 	if (IS_ERR(gdev))
 		return ERR_CAST(gdev);
 
-	/*
-	 * FIXME: The GPIO device reference is put at return but the descriptor
-	 * is passed on. Find a proper solution.
-	 */
 	desc = gpio_device_get_desc(gdev, args.args[0]);
 	*flags = args.args[1]; /* We expect native GPIO flags */
 
-- 
2.54.0

Re: [PATCH 0/2] gpio: core: fix const-correctness and remove UAF FIXMEs

[Andy Shevchenko]

On Sun, May 24, 2026 at 06:27:06PM +0200, Marco Scardovi (scardracs) wrote:
> This series addresses legacy "FIXME Cannot use gpio_chip_guard due to
> const desc" comments and open-coded SRCU locks scattered throughout the
> gpiolib core and backend lookup paths.
> 
> I am aware of the ongoing work to replace the gpio_chip_guard architecture
> entirely (see the "revocable objects" patchset discussion at
> https://lore.kernel.org/linux-gpio/20260513091043.6766-1-tzungbi@kernel.org/).
> While that broader refactoring is being iterated upon, this patch series
> provides a simple, completely type-safe fix utilizing the existing SRCU
> guard infrastructure. It can be merged today to eliminate the FIXMEs
> without conflicting conceptually with future revocable objects.

Sounds reasonable to me and the code looks good, but I haven't deeply checked that.
Hence
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

and personally I very much like the second patch and agree that it's good to
have rather sooner in tree in case the change is correct.

But we anyway need to know Bart's take on this.

> For clarity during review, the series relies on the following guarantees:
> 
> 1. Deep Const-Correctness is Preserved:
> Updating DEFINE_CLASS(gpio_chip_guard, ...) to accept a `const struct
> gpio_desc *desc` does not drop const qualifiers. In C, const-propagation
> does not implicitly const-qualify deep pointers. The `desc->gdev` evaluation
> yields a mutable `struct gpio_device *`, making the internal guard
> assignment perfectly legal and safe for fast-path read operations.
> 
> 2. Identical SRCU Lifetime Scope:
> The DEFINE_CLASS macro's GNU C compound statement `({ ... })` relies
> on strict sequence points. Thus, `srcu_read_lock()` is fully acquired
> prior to executing `srcu_dereference()`. The guard's lifetime remains
> identically bound to the block scope, exactly mirroring the open-coded
> `guard(srcu)(&gdev->srcu)` it replaces.
> 
> 3. Lookup UAF FIXMEs are Architecturally Obsolete:
> The FIXME comments removed in the ACPI and swnode backend lookup paths
> (warning about dropping the device reference) are functionally obsolete.
> By design, `gpiod_find_and_request()` wraps the entire backend lookup
> operation inside the global `gpio_devices_srcu` read lock. The lookup
> functions are entirely safe to drop their temporary references since the
> caller subsequently takes its own permanent references without ever leaving
> the SRCU read-side critical section.
> 
> Please note that while this patch provides a good solution to clean up the
> existing codebase, I fully understand the necessity of deeper and more
> radical modifications to robustly secure the subsystem's future.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 0/2] gpio: core: fix const-correctness and remove UAF FIXMEs

[Bartosz Golaszewski]

On Sun, 24 May 2026 18:27:06 +0200, Marco Scardovi (scardracs) wrote:
> This series addresses legacy "FIXME Cannot use gpio_chip_guard due to
> const desc" comments and open-coded SRCU locks scattered throughout the
> gpiolib core and backend lookup paths.
> 
> I am aware of the ongoing work to replace the gpio_chip_guard architecture
> entirely (see the "revocable objects" patchset discussion at
> https://lore.kernel.org/linux-gpio/20260513091043.6766-1-tzungbi@kernel.org/).
> While that broader refactoring is being iterated upon, this patch series
> provides a simple, completely type-safe fix utilizing the existing SRCU
> guard infrastructure. It can be merged today to eliminate the FIXMEs
> without conflicting conceptually with future revocable objects.
> 
> [...]

Applied, thanks!

[1/2] gpio: core: fix const-correctness of gpio_chip_guard
      https://git.kernel.org/brgl/c/aa7e8b7ef03151305a387654280306684687ade9
[2/2] gpio: remove obsolete UAF FIXMEs from lookup paths
      https://git.kernel.org/brgl/c/07c44ee9fdf196dcec14675c793e3139ec8a15b5

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>