linux-kernel - Re: [PATCH] reset: gpio: suppress bind attributes in sysfs

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMRc=McEX6y_9JF=ji_TQ0aSMaQYe4kjq8Tj1S=vOcbawyXw3w@mail.gmail.com>
Date: Thu, 4 Dec 2025 12:22:12 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, 
	Philipp Zabel <p.zabel@...gutronix.de>, linux-kernel@...r.kernel.org, 
	stable@...r.kernel.org
Subject: Re: [PATCH] reset: gpio: suppress bind attributes in sysfs

On Thu, Dec 4, 2025 at 12:14 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On 04/12/2025 10:44, Bartosz Golaszewski wrote:
> > This is a special device that's created dynamically and is supposed to
> > stay in memory forever. We also currently don't have a devlink between
>
> Not forever. If every consumer is unloaded, this can be unloaded too, no?
>
> > it and the actual reset consumer. Suppress sysfs bind attributes so that
>
> With that reasoning every reset consumer should have suppress binds.
> Devlink should be created by reset controller framework so it is not
> this driver's fault.
>

Here's my reasoning: I will add a devlink but Phillipp requested some
changes so I still need to resend it. It will be a bigger change than
this one-liner. The reset-gpio device was also converted to auxiliary
bus for v6.19 and I will also convert reset core to using fwnodes for
v6.20 so we'll significantly diverge in stable branches, while this
issue is present ever since the reset-gpio driver exists. It's not the
driver's fault but it's easier to fix it here and it very much is a
special case - it's a software based device rammed in between two
firmware-described devices.

>
> > user-space can't unbind the device because - as of now - it will cause a
> > use-after-free splat from any user that puts the reset control handle.
> >
> > Fixes: cee544a40e44 ("reset: gpio: Add GPIO-based reset controller")
>
> Nothing to be fixed here, unless you claim that every reset provider is
> broken as well? What is exactly different in handling devlinks between
> this driver and every other reset provider?
>

I don't care if we keep the tag, it's just that this commit introduced
a way for user-space to crash the system by simply unbinding
reset-gpio and then its active consumers.

And the difference here is that there is no devlink between reset-gpio
and its consumers. We need to first agree how to add it.

Bartosz