Re: [PATCH v4 1/2] debugfs: fix use-after-free in debugfs_read_file_str()

[Danilo Krummrich]

On Mon Sep 28, 2026 at 7:35 AM CEST, Greg KH wrote:
> On Sun, Sep 27, 2026 at 07:00:04PM +0200, Danilo Krummrich wrote:
>> On Sun Sep 27, 2026 at 6:37 PM CEST, Greg KH wrote:
>> > This is probably not right, don't do loops like this.  Either fail or
>> > succeed, don't loop.
>> 
>> Please see [1], where I listed a couple of alternatives (e.g. use GFP_NOWAIT and
>> accept allocation failures).  I'm not very opinionated about which of the
>> options we use, but GFP_ATOMIC seems wrong for this.
>> 
>> > Again, let's see the real use case here, what is hitting this in
>> > userspace today and what debugfs kernel files are causing it?
>> 
>> Not sure if this was hit in the field, but in any case, the reader lacks the RCU
>> read-side critical section required by the writer's reclamation.
>> 
>> As mentioned in [1], there is also a separate caller-side race in SoundWire [2]:
>> nothing prevents a concurrent write from freeing the string while
>> request_firmware() is using it.
>> 
>> This is also why I think the API is a bit of a footgun. Fixing the debugfs
>> reader won't address these caller-side accesses; something like the synchronized
>> accessors suggested in [1] could address the broader API issue.
>
> Ick, how about we just delete it then?  I thought we had removed debugfs
> string functions already because of problems like this in the past...

That's an option, but it seems people really seek for having a convinient API
for this. And I think we can provide something that is "hard to get wrong" based
on what I suggested, which I think is better than letting people open-code this.