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

Mukesh Ojha <[email protected]> Mon, 3 Aug 2026 23:42:37 +0530
Newsgroups dev.linux.lists.driver-core,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
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 ?

> ---
>  drivers/base/firmware_loader/fallback.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
> index 3ef0b312ae71..ffe1b3784788 100644
> --- a/drivers/base/firmware_loader/fallback.c
> +++ b/drivers/base/firmware_loader/fallback.c
> @@ -95,6 +95,15 @@ static int fw_load_sysfs_fallback(struct fw_sysfs *fw_sysfs, long timeout)
>  		retval = -EINTR;
>  		goto out;
>  	}
> +	/*
> +	 * device_add() exposes the loading interface before pending_list is
> +	 * linked into pending_fw_head, so fw_state_done() may run first.
> +	 */
> +	if (fw_state_is_done(fw_priv)) {
> +		mutex_unlock(&fw_lock);
> +		goto out;
> +	}
> +
>  	list_add(&fw_priv->pending_list, &pending_fw_head);
>  	mutex_unlock(&fw_lock);
>  
> -- 
> 2.53.0
> 

-- 
-Mukesh Ojha