CVE-2026-99185
NoneCVSS
—
EPSS
0.2%
Published
Oct 28, 2026
CISA due date
—
Cloudanix analysis
A timing bug in the way the operating system manages certain device communications could let a local attacker crash the system or gain elevated access.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in split transaction handling where both fw_core_handle_response and the timeout callback can process the same pending transaction entry, resulting in use-after-free on the initiator side.
Why it matters to the business
Systems relying on FireWire hardware may experience kernel instability, crashes, or local privilege escalation; the issue affects a narrow set of Linux deployments but requires prompt patching to avoid operational disruption.
How an attack unfolds
An attacker with local access triggers concurrent split transactions while manipulating timing so that the response handler and timeout callback both attempt to free or reuse the same transaction structure, leading to memory corruption.
How to fix it
Update to a Linux kernel version containing the fix that ensures the response handler leaves the entry in the list when timer_delete returns zero; rebuild and reboot with the patched kernel.
How to confirm the fix worked
Confirm the running kernel contains the corrected split-transaction logic by inspecting the firewire core source or checking for the presence of the timer_delete return-value guard; test by exercising split transactions under load.
Typical attack path
- Obtain local code execution on a Linux system with the firewire core loaded
- Craft or trigger split transactions that race the pending list handlers
- Cause timer_delete to return zero while the timeout callback is active
- Trigger double processing that frees the transaction entry twice
- Exploit the resulting use-after-free for kernel memory corruption or escalation
How to detect it
Review kernel logs for use-after-free or double-free reports involving the firewire core pending transaction list; inspect for unusual timing patterns around split transaction responses and timeouts.
What your security team should do
- Prioritize kernel upgrade on any hosts exposing FireWire interfaces or using firewire modules
- Disable the firewire subsystem if the hardware is not required
- Monitor for kernel oops or panic logs referencing firewire transaction handling
- Apply updates within standard change windows given low EPSS and no known exploitation
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|