Skip to main content
VulnerabilityPublished

CVE-2026-99185: Linux kernel · firewire: core: fix race condition in split transaction handling

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited : upgrade to a8caee0e623ca5d56e829032f9ec073c09e4d224 or 7f9f2d6abc40f79e802b4063859eda343043b85c when convenient.

Data as of 28 Oct 2026, 10:58 UTC

Severity
Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

Patch
Available – fixed in a8caee0e623ca5d56e829032f9ec073c09e4d224, 7f9f2d6abc40f79e802b4063859eda343043b85c

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 28 Oct 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Linux kernel to a8caee0e623ca5d56e829032f9ec073c09e4d224 or 7f9f2d6abc40f79e802b4063859eda343043b85c.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ fa2dc27100768a8a994c377051fa17a47cc66c76, < a8caee0e623ca5d56e829032f9ec073c09e4d224
Fixed in
  • a8caee0e623ca5d56e829032f9ec073c09e4d224
LinuxLinuxAffected
  • ≥ fa2dc27100768a8a994c377051fa17a47cc66c76, < 7f9f2d6abc40f79e802b4063859eda343043b85c
Fixed in
  • 7f9f2d6abc40f79e802b4063859eda343043b85c
LinuxLinuxAffected
  • =6.19
Fixed in–

Description

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.

References

Community reviews

Loading reviews…