UBUNTU-CVE-2026-99185: Use After Free
In the Linux kernel, the following vulnerability has been resolved: firewire: core: fix race condition in split transaction handling For a split transaction, either fwcorehandleresponse() or splittransactiontimeoutcallback() may manipulate the same transaction entry in the pending transaction list. The return value of timerdelete() is used to determine which function handles the entry. If the transaction is a split transaction and timerdelete() 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 timerdelete() returns zero. The timeout callback is responsible for removing the entry from the pending transaction list.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Ensure fw_core_handle_response() leaves the transaction entry in the pending transaction list when timer_delete() returns zero, allowing split_transaction_timeout_callback() to remove it.
Linux kernel FireWire core split transaction handling response-handler processing when timer_delete() returns zero = do not process the transaction
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel FireWire core and acting as the initiator of split transactions are exposed to the described use-after-free race. The issue concerns concurrent response handling and timeout processing for entries in the pending transaction list.
What condition is required for the race to occur?
A split transaction must have its response handler and timeout callback contend for the same pending transaction entry. Specifically, the response handler observes timer_delete() returning zero, indicating that the timeout callback may already be running.
How does the fix prevent the use-after-free?
When timer_delete() returns zero for a split transaction, the response handler leaves the transaction entry untouched. The timeout callback then remains solely responsible for removing the entry from the pending transaction list, preventing both paths from processing it.