CVE-2026-90107 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
net/smc: free pending qentry in smc_llc_flow_stop() before memset
smc_llc_flow_stop() resets a flow struct with a blind memset:
spin_lock_bh(&lgr->llc_flow_lock); memset(flow, 0, sizeof(*flow)); flow->type = SMC_LLC_FLOW_NONE; spin_unlock_bh(&lgr->llc_flow_lock);
If flow->qentry is non-NULL at this point the pointer is overwritten without the allocation being freed, leaking one kmalloc object.
A late-arriving duplicate CONFIRM_LINK or ADD_LINK_CONT message can set flow->qentry after the legitimate message has been consumed by the waiter via smc_llc_flow_qentry_clr() (which NULLs the pointer but leaves flow->type non-zero) but before the flow completes and smc_llc_flow_stop() runs. In that window the duplicate is stashed into flow->qentry, and then lost when smc_llc_flow_stop() zeros the struct.
Call smc_llc_flow_qentry_del() inside the lock before the memset. smc_llc_flow_qentry_del() already checks flow->qentry before freeing, so the normal case where no entry is pending is a no-op.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel's SMC (Shared Memory Communications) subsystem contains a resource management flaw within the LLC link group flow handling logic that results in a memory leak of kernel heap allocations. This vulnerability arises from an improper sequence of operations during the termination or reset of an LLC flow, specifically within the smc_llc_flow_stop function. The core issue is rooted in the use of a blind memset operation to zero out the entire flow structure without first ensuring that any dynamically allocated resources associated with pending queue entries are properly released. This oversight leads to the loss of references to kernel memory objects allocated via kmalloc, preventing their return to the system's memory pool and causing gradual resource exhaustion over time if triggered repeatedly.
The technical mechanism behind this vulnerability involves a race condition window during message processing in the SMC LLC layer. When an incoming CONFIRM_LINK or ADD_LINK_CONT message is processed, it may set the flow->qentry pointer to point to a newly allocated queue entry structure. If a legitimate consumer thread processes and clears this entry via smc_llc_flow_qentry_clr, which nullifies the qentry pointer but leaves other fields like type non-zero, there remains a critical window before the flow is fully stopped. During this interval, if a late-arriving duplicate message arrives, it may successfully stash its own queue entry into the now-available flow->qentry field because the previous entry has been logically removed from active processing queues but not yet physically freed or cleared in the context of the upcoming stop operation. When smc_llc_flow_stop subsequently executes, it acquires the LLC flow lock and performs a memset on the entire flow structure to reset its state. This action overwrites the qentry pointer with NULL without invoking the appropriate deallocation routine for the pending queue entry that was stashed during the race window. Consequently, the memory allocated for this duplicate queue entry becomes unreachable and is leaked from kernel space.
From an operational impact perspective, while a single instance of this leak may appear negligible in terms of immediate system stability, it represents a classic resource exhaustion vulnerability. In environments where SMC connections are frequently established, terminated, or experience network latency leading to message duplication, the repeated leakage of kmalloc objects can contribute to increased kernel memory pressure. Over extended periods or under high-load conditions with frequent flow resets, this accumulation of unreleased heap allocations can degrade system performance and potentially lead to out-of-memory conditions within the kernel slab allocator. This type of vulnerability is particularly concerning in production environments where long-running services rely on SMC for high-performance inter-process communication, as it undermines the reliability and longevity of the host system without necessarily causing an immediate crash or denial of service event visible at the application layer.
The resolution to this issue involves modifying the smc_llc_flow_stop function to explicitly handle pending queue entries before performing the memory zeroing operation. The fix requires calling smc_llc_flow_qentry_del within the protection of the LLC flow lock, immediately prior to executing the memset on the flow structure. This ensures that any qentry pointer present in the flow struct is properly processed by the deletion routine, which safely checks for non-NULL pointers and frees the associated memory if necessary. By integrating this cleanup step into the standard stop sequence, the vulnerability is mitigated as all pending allocations are guaranteed to be released before their references are overwritten. This approach maintains thread safety through the existing spinlock mechanism while ensuring complete resource lifecycle management.
This vulnerability aligns with CWE-401, which describes a missing release of memory after effective usage, and falls under the broader category of improper resource shutdown or cleanup. In terms of attack classification within the MITRE ATT&CK framework, this flaw relates to Tactic TA0005 (Defense Evasion) specifically through techniques that involve hiding resources or consuming system resources to degrade service availability, although it is primarily a defect rather than an exploitable exploit vector for direct compromise. The fix emphasizes the importance of rigorous state management in kernel networking stacks, ensuring that all dynamic allocations tied to protocol states are explicitly freed during state transitions to prevent silent memory leaks that can accumulate over time and impact system stability.