CVE-2026-90284 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
firmware_loader: do not queue completed sysfs fallback requests
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability in the Linux kernel firmware loader subsystem stems from a race condition during the initialization of device-specific firmware loading interfaces via sysfs. Specifically, the function fw_load_sysfs_fallback() invokes device_add() to publish the fallback loading interface before adding the associated firmware private data structure, known as fw_priv, to the pending_fw_head list. This ordering creates a window where userspace applications can discover the newly published device by scanning the sysfs filesystem and interact with it immediately. A malicious or buggy userspace helper may write zero to the loading attribute of this interface, which triggers the firmware_loading_store() function to mark the request as completed via fw_state_done(). Because the fw_priv has not yet been added to the pending_fw_head list at this stage, the completion logic operates on a state where the pending_list pointer still points to itself rather than to an actual entry in the global queue.
This interleaving results in a critical failure of the kernel's internal list management mechanisms. When firmware_loading_store() attempts to remove the completed request from the pending_fw_head, it fails because the structural integrity required for removal is absent due to the premature completion state relative to the insertion point. Consequently, subsequent code proceeds with an unconditional list_add operation that queues a fw_priv object which has already been marked as done and effectively processed. This violates the fundamental invariant of the firmware loading subsystem, which expects pending_fw_head to contain only active, in-flight requests awaiting processing or timeout handling. The presence of completed objects in this queue introduces logical inconsistencies that can cascade into more severe memory safety issues during subsequent operations on the list.
The operational impact of this flaw is significant, primarily manifesting as a use-after-free vulnerability and potential kernel panic. Once the already-queued but logically completed fw_priv request is released by higher-level firmware loading logic, it may be freed from memory. However, because it remains linked within pending_fw_head through the corrupted list pointers, subsequent fallback requests that iterate over this head to validate or process entries will encounter a pointer to freed memory. Dereferencing this dangling pointer leads to an invalid memory access fault, causing system instability, denial of service, or potentially arbitrary code execution if the attacker can control the contents of the freed memory region through heap spraying techniques. This represents a classic time-of-check-to-time-of-use scenario exacerbated by asynchronous userspace interaction with kernel interfaces exposed via sysfs.
From a classification perspective, this vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition), as the core issue is the lack of atomicity between device publication and queue insertion. It also relates to CWE-416, Use After Free, due to the retention of pointers to released memory structures within active kernel lists. In terms of the MITRE ATT&CK framework for Linux systems, this flaw could be leveraged in techniques associated with Taint Analysis or Defense Evasion by manipulating sysfs attributes to trigger state inconsistencies that bypass normal error handling paths. The vulnerability highlights the risks inherent in exposing asynchronous hardware initialization states directly to userspace without sufficient synchronization barriers.
To mitigate this issue, the kernel developers implemented a fix that ensures only in-flight fallback requests are subject to suspend or reboot abort handling logic. The corrected code path checks if the request is already marked as DONE immediately after device_add(). If so, it returns success from the fallback path without sending another uevent, waiting for further completion signals, or queuing the object into pending_fw_head. This preserves the invariant that pending_fw_head contains exclusively active requests requiring management during system state changes. Administrators and developers should ensure their systems are updated with patches addressing this specific firmware loader race condition to prevent potential exploitation through sysfs manipulation. Regular auditing of userspace interactions with kernel-sysfs interfaces is also recommended to detect any anomalous timing patterns that might indicate attempts to exploit similar synchronization flaws in other subsystems.