Re: [PATCH v2] gpio: shared: fix a race in shared desc release path

[Linus Walleij]

On Tue, Nov 10, 2026 at 11:10 AM Bartosz Golaszewski
<bartosz.golaszewski@xxxxxxxxxxxxxxxx> wrote:

> gpiod_shared_put() races with concurrent calls to
> devm_gpiod_shared_get() like so:
>
> CPU 0 (unbind / probe failure)      CPU 1 (concurrent proxy probe)
> ==============================      ==============================
> gpiod_shared_put()
>   kref_put(&entry->ref, ...)
>     refcount_dec_and_test() // -> 0
>                                     devm_gpiod_shared_get()
>                                       mutex_lock(&entry->lock);
>                                       if (entry->shared_desc) {
>                                         kref_get(&entry->ref); // on 0!
>                                         shared_desc = entry->shared_desc;
>                                       }
>                                       mutex_unlock(&entry->lock);
>     gpio_shared_release()
>       mutex_lock(&entry->lock);
>       kfree(shared_desc);
>       entry->shared_desc = NULL;
>       mutex_unlock(&entry->lock);
>                                       // uses freed shared_desc
>
> Because gpiod_shared_put() decrements entry->ref without holding
> entry->lock and gpio_shared_release() only acquires entry->lock after the
> reference count has already reached zero, a concurrent call to
> devm_gpiod_shared_get() can acquire entry->lock in the intermediate window
> and observe a non-NULL entry->shared_desc. This can result in a
> use-after-free and a double-free when the second consumer releases its
> reference.
>
> Use kref_put_mutex() to ensure the entry lock is taken without a window
> in which a concurrent user can see a non-NULL entry->shared_desc while
> it's being released.
>
> Cc: stable@xxxxxxxxxxxxxxx
> Closes: https://sashiko.dev/#/bug/linux-30e071e4-4e4a-4b63-bd83-df1147055d35
> Fixes: a060b8c511ab ("gpiolib: implement low-level, shared GPIO support")
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxxxxxxxx>

Good find!
Reviewed-by: Linus Walleij <linusw@xxxxxxxxxx>

Yours,
Linus Walleij