Re: [PATCH] firmware_loader: do not queue completed sysfs fallback requests

Mukesh Ojha <[email protected]>
Newsgroups dev.linux.lists.driver-core,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On Mon, Aug 03, 2026 at 08:40:06PM +0200, Danilo Krummrich wrote:
> On Mon Aug 3, 2026 at 8:12 PM CEST, Mukesh Ojha wrote:
> > On Thu, Jul 16, 2026 at 01:46:01PM +0530, Mukesh Ojha wrote:
> >> fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to
> >> pending_fw_head. device_add() publishes the fallback loading interface, so
> >> a userspace helper which discovers the device by scanning sysfs can write 0
> >> to the loading attribute and complete the request before it is queued as
> >> pending.
> >> 
> >> In that interleaving firmware_loading_store() calls fw_state_done() while
> >> pending_list still points to itself, so it cannot remove an entry from
> >> pending_fw_head. The subsequent unconditional list_add() then queues an
> >> already-completed fw_priv. Once the request is released, pending_fw_head
> >> can retain a pointer to freed memory and the next fallback request can
> >> fault while validating the list.
> >> 
> >> Only in-flight fallback requests need suspend or reboot abort handling. If
> >> the request is already DONE after device_add(), return success from the
> >> fallback path without sending another uevent, waiting again, or queueing it
> >> as pending. This preserves the invariant that pending_fw_head contains only
> >> active fallback requests.
> >> 
> >> Fixes: 75d95e2e39b2 ("firmware_loader: fix use-after-free in firmware_fallback_sysfs")
> >> Signed-off-by: Mukesh Ojha <[email protected]>
> >
> > Can we consider this fix for this mentioned issue ?
> 
> Sure, how did you come across this issue?

with Kasan with some fuzzing.

-Mukesh
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.