CVE-2026-90213 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
firewire: core: fix memory leak in error path of build_tree()
In the error path of build_tree(), node instances can remain in the local linked list when the function returns.
Whenever an invalid value is detected in the self ID sequence, each allocated node instance is either an entry in the linked list or an entry in the ports array of its parent node. Therefore, the allocate node instances can be safely released by traversing the linked list from its head.
Release the remaining node instances with for_each_fw_node() before returning to the caller.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel's FireWire core subsystem contains a memory leak vulnerability within the build_tree function, specifically triggered during error handling paths when processing self ID sequences. This issue arises from an incomplete cleanup procedure that fails to properly deallocate dynamically allocated node instances under certain failure conditions. The firewire driver is responsible for managing hardware topology discovery and configuration on IEEE 1394 networks, a process that involves parsing self IDs transmitted by devices to construct a tree representation of the network structure. During this initialization phase, the kernel allocates memory structures to represent each detected node in the bus topology.
The technical flaw occurs when an invalid value is encountered within the self ID sequence received from connected FireWire devices. In such scenarios, the build_tree function detects the error but does not fully release all previously allocated resources before returning control to the caller. Specifically, any node instances that were added to local linked lists or inserted into parent port arrays remain in memory despite the failure of the topology building process. This results in a classic resource leak where kernel memory is consumed and never returned to the system pool, leading to gradual degradation of available memory resources over time if such errors occur repeatedly during device enumeration or reconnection events.
From an operational impact perspective, this vulnerability primarily affects system stability through progressive memory exhaustion rather than immediate service disruption. While individual instances may consume minimal amounts of kernel space, repeated occurrences can lead to increased pressure on the kernel's memory allocator. In resource-constrained environments or systems with frequent hot-plugging of FireWire devices, these leaks could contribute to out-of-memory conditions affecting other critical subsystems. The vulnerability does not allow for remote code execution or privilege escalation but represents a denial-of-service vector through resource depletion that impacts system reliability and performance over extended periods.
This issue aligns with CWE-401, which describes missing release of memory after successful allocation, as well as CWE-772, referring to the lack of releasing resources after acquiring them. The failure pattern corresponds to improper error handling where cleanup routines are omitted in specific code paths that handle exceptional conditions rather than normal execution flows. Security researchers and kernel developers classify this type of defect under common vulnerability patterns related to resource management failures during initialization sequences.
Mitigation strategies involve applying the upstream Linux kernel patch that addresses this specific memory leak by ensuring comprehensive deallocation of all allocated node instances before function return. System administrators should ensure their kernels are updated with patches containing fixes for firewire core subsystem issues, particularly those addressing build_tree error path handling. For environments where FireWire connectivity is not required, disabling the relevant kernel modules can eliminate exposure to this vulnerability entirely. Continuous monitoring of system memory usage patterns may help detect unusual consumption trends that could indicate active exploitation or accumulation of such leaks in production systems.