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 for Android: free password hash cracker in your pocket

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

Message-ID: <0fc5c657-4edf-474f-9df7-3c3473b5f458@kernel.org>
Date: Thu, 4 Dec 2025 12:53:37 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Bartosz Golaszewski <brgl@...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 04/12/2025 12:22, Bartosz Golaszewski wrote:
> 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.

That's not the answer to my question. You can unbind every other reset
controller. Why is this special although maybe you mentioned below?

> 
>>
>>> 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.

So you mean that between every other reset consumer and reset provider
there is a devlink? And here there is no devlink?


Best regards,
Krzysztof