CVE-2026-99185 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
firewire: core: fix race condition in split transaction handling
For a split transaction, either fw_core_handle_response() or split_transaction_timeout_callback() may manipulate the same transaction entry in the pending transaction list. The return value of timer_delete() is used to determine which function handles the entry. If the transaction is a split transaction and timer_delete() returns zero, the timeout callback may already be running. In this case, the response handler must leave the entry in the list for the timeout callback to remove.
A previous code refactoring broke this behavior, introducing a race condition in which both functions could process the same transaction. This could lead to a use-after-free on the transaction initiator side.
Fix the regression by ensuring that the response handler does not process the transaction when timer_delete() returns zero. The timeout callback is responsible for removing the entry from the pending transaction list.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel's FireWire subsystem contains a critical concurrency flaw within its split transaction handling logic, specifically involving race conditions between asynchronous event handlers and timer callbacks. Split transactions in FireWire are complex operations that often require multiple steps to complete, necessitating robust state management to ensure data integrity and system stability. The vulnerability arises from the interaction between two distinct execution paths: fw_core_handle_response(), which processes incoming responses to transaction requests, and split_transaction_timeout_callback(), which manages timeouts for pending transactions. Both functions operate on the same shared data structure, specifically the entry within the pending transaction list associated with a specific transaction initiator. Under normal circumstances, these functions are designed to be mutually exclusive in their handling of any single transaction entry. However, a recent code refactoring inadvertently disrupted this synchronization mechanism, leading to a scenario where both handlers could attempt to access and modify the same memory structure concurrently without adequate locking or atomicity guarantees.
The core technical flaw lies in the logic used to determine which function should assume responsibility for cleaning up the transaction entry after timer_delete() is called. The original design relied on the return value of timer_delete() as a signal to decide whether the timeout callback was still active. If timer_delete() returned zero, it indicated that the timer had not yet fired or was in a state where the callback might already be executing. In such cases, the response handler was supposed to defer removal of the entry to the timeout callback to prevent double-freeing or use-after-free errors. The regression introduced by the refactoring failed to preserve this conditional logic correctly. Consequently, when timer_delete() returned zero, indicating that the timeout callback could potentially be running, the response handler proceeded to process and remove the transaction entry anyway. This created a race condition where both the response handler and the timeout callback attempted to manipulate or free the same memory block simultaneously.
The operational impact of this vulnerability is severe, primarily manifesting as a use-after-free error on the transaction initiator side. When two threads concurrently access and modify the same kernel object without proper synchronization, it leads to undefined behavior that can corrupt kernel data structures, cause system crashes, or lead to privilege escalation if an attacker can exploit the memory corruption state. In the context of FireWire, which is often used for high-speed peripheral connections in professional audio, video, and storage applications, such instability can result in significant service disruption. The use-after-free condition allows for potential exploitation by local attackers who may trigger these race conditions through specific sequences of device interactions or timing manipulations, potentially gaining unauthorized access to kernel memory or causing denial-of-service conditions that affect system reliability.
To mitigate this vulnerability and restore correct synchronization behavior, the fix ensures that when timer_delete() returns zero, indicating a potential overlap with an active timeout callback, the response handler explicitly refrains from processing or removing the transaction entry. Instead, responsibility for cleaning up the pending transaction list is delegated entirely to the split_transaction_timeout_callback(). This approach re-establishes mutual exclusion by ensuring only one execution path handles the lifecycle of each transaction entry at any given time. From a security standards perspective, this issue aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'). The exploitation vector relates to timing-based attacks where an adversary attempts to manipulate the race window between timer expiration and response handling. Mitigation strategies involve applying the kernel patch that corrects the conditional logic around timer_delete() return values, thereby enforcing strict ownership of transaction state transitions and preventing concurrent access violations in the FireWire core subsystem.