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

[Greg KH]

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

thanks,

greg k-h