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

[Danilo Krummrich]

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.

Thanks,
Danilo

[1] https://lore.kernel.org/driver-core/DLPDB44JJRGJ.3K6JNS746M7QC@xxxxxxxxxx/
[2] https://elixir.bootlin.com/linux/v7.2.7/source/drivers/soundwire/debugfs.c#L268