linux-kernel - Re: [PATCH v5 6/8] gpio: cdev: put emitting the line state events on a workqueue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMRc=MdJBuTLEkxNjY8sgAS84g0WyHe27NYjtf_WDwZ53Ja0-w@mail.gmail.com>
Date: Fri, 14 Nov 2025 16:26:56 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
Cc: "bartosz.golaszewski@...aro.org" <bartosz.golaszewski@...aro.org>, 
	"warthog618@...il.com" <warthog618@...il.com>, 
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linus.walleij@...aro.org" <linus.walleij@...aro.org>
Subject: Re: [PATCH v5 6/8] gpio: cdev: put emitting the line state events on
 a workqueue

On Fri, Nov 14, 2025 at 12:57 PM Sverdlin, Alexander
<alexander.sverdlin@...mens.com> wrote:
>
> Hi Bartosz,
>
> On Fri, 2025-11-14 at 02:11 -0800, Bartosz Golaszewski wrote:
> > > > > > In order to allow line state notifications to be emitted from atomic
> > > > > > context (for instance: from gpiod_direction_input/output()), we must
> > > > > > stop calling any sleeping functions in lineinfo_changed_notify(). To
> > > > > > that end let's use the new workqueue.
> > > > > >
> > > > > > Let's atomically allocate small structures containing the required data
> > > > > > and fill it with information immediately upon being notified about the
> > > > > > change except for the pinctrl state which will be retrieved later from
> > > > > > process context. We can pretty reliably do this as pin functions are
> > > > > > typically set once per boot.
> > > > > >
> > > > > > Let's make sure to bump the reference count of GPIO device and the GPIO
> > > > > > character device file descriptor to keep both alive until the event was
> > > > > > queued.
> > > > > >
> > > > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> > > > >
> > > > > starting from this patch up to the current linux-next (v6.18-rcX)
> > > > > I see the following refcnt warnings + KASAN UAF reports on either reboot
> > > > > (when gpio-manager is being stopped) or
> > > > > `systemctl kill --signal=SIGKILL gpio-manager` (if some GPIOs are being
> > > > > requested from (owned by) gpio-manager prior to kill):
> > >
> > > []
> > >
> > > > Thanks for the bug report. I confirm it's reproducible on my side too.
> > > > It never occurred to me to try and SIGKILL gpio-manager. On normal
> > > > exit, nothing bad happens. Let me look into it.
> > >
> > > In my case it happens also on every reboot/shutdown, however if I
> > > `systemctl stop gpio-manager`, I don't see the issue... not sure yet,
> > > what is the difference... and I'm not telling SIGKILL is how one
> > > should stop gpio-manager, but I'm happy SIGKILL now allows you to
> > > reproduce the issue in the kernel code!
> > >
> >
> > When the process is killed, it seems the character device's file struct is no
> > longer valid even though chrdev_release() was not yet called - it's called
> > after we try to send out this notification. I think it's best to just check
> > if the file is active and not do anything if it isn't.
> >
> > Can you test the following change before I submit a formal patch?
>
> thank you for the quick fix!
> I've tested the below patch (on top of v6.18-rc4 with quite some debug options
> and even KASAN) and I don't get any issues, neither killing gpio-manager,
> nor during reboot.
>
> Feel free to add my
> Tested-by: Alexander Sverdlin <alexander.sverdlin@...mens.com>
>

Thanks! I still want to investigate it a bit more as the same issue
appears even without SIGKILL if I run the following python script:

import gpiod
chip = gpiod.Chip("/dev/gpiochip0")
chip.watch_line_info(0)
req = chip.request_lines({0: None})

It basically happens if the same process is watching the line it
requests and then gets killed and the ordering of operations is right.
In gpio-manager when existing cleanly, we free resources in the right
order but this python script lets the OS handle cleanup and the same
issue occurs.

I want to get to the bottom of what's going on.

Bart