CVE-2026-98560 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
net/rds: size a connection's path set by the transport it ends up with
__rds_conn_create() computes npaths from the caller's transport before it decides whether a connection to one of the host's own addresses is to be handled by the loopback transport instead. That substitution is what an RDS/TCP socket sending to a local address gets, and after it the path init loop still runs for the TCP transport's RDS_MPATH_WORKERS paths and allocates an ordered workqueue for each, while rds_loop_conn_alloc() only ever provides transport data for path 0.
rds_conn_destroy() sizes its teardown from c_trans, by then the loopback transport, so it visits path 0 only - and rds_conn_path_destroy() would skip the other paths anyway, since it returns before destroy_workqueue() for a path without transport data. kfree(c_path) then drops the last pointers to seven workqueues. That repeats for every such connection, on every netns teardown or module unload, and every distinct local destination address is a separate connection.
Recompute npaths once the transport is final, so that creation and destruction agree on the set of paths. The c_path array stays sized for the caller's transport; the unused entries are freed with it.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in the Linux kernel within the Reliable Datagram Sockets (RDS) subsystem represents a critical resource management flaw rooted in inconsistent state handling during connection initialization and teardown. Specifically, the function __rds_conn_create() calculates the number of paths, denoted as npaths, based on the transport protocol initially requested by the caller rather than the actual transport that will handle the connection after internal routing logic determines it should use the loopback interface for local addresses. This discrepancy arises because RDS/TCP sockets sending to a local address are internally redirected to the loopback transport, yet the initial allocation of resources assumes the characteristics of the original TCP transport. Consequently, the system proceeds to initialize and allocate an ordered workqueue for each path defined by the TCP transport's configuration, which typically involves multiple worker paths known as RDS_MPATH_WORKERS. However, the loopback transport implementation is designed to provide valid transport data only for the first path index zero, leaving subsequent allocated resources without proper association or management context within that specific transport layer.
This architectural inconsistency leads directly to a use-after-free condition during connection destruction. When rds_conn_destroy() executes its teardown sequence, it relies on c_trans which now correctly points to the loopback transport due to the earlier substitution logic. As a result, the cleanup routine iterates only over path zero, effectively ignoring the previously allocated workqueues for the remaining paths. The function rds_conn_path_destroy() further exacerbates this issue by returning early when encountering paths that lack valid transport data, thereby skipping the necessary destroy_workqueue calls for those entries. This oversight leaves multiple kernel memory allocations unreleased, specifically seven workqueues in typical configurations, resulting in a significant resource leak. These leaked resources persist until the network namespace is torn down or the RDS module is unloaded, at which point kfree(c_path) releases the array pointer but does not address the dangling references to the orphaned workqueues, leading to potential memory corruption or system instability upon subsequent operations involving similar connection patterns.
The operational impact of this vulnerability extends beyond simple resource exhaustion. While immediate exploitation for arbitrary code execution is unlikely due to the nature of kernel object leaks rather than direct control flow hijacking, the cumulative effect on systems with high volumes of local RDS connections can lead to memory pressure and eventual denial of service conditions. Each distinct local destination address creates a separate connection instance, meaning that sustained traffic patterns targeting multiple loopback addresses will progressively deplete kernel memory resources associated with workqueues. This behavior aligns with CWE-401, which describes the failure to release memory after it becomes available for reuse, and falls under the broader category of resource management errors. From an adversarial perspective, this flaw could be leveraged in a denial-of-service attack vector as defined by MITRE ATT&CK technique T1529, where attackers aim to exhaust system resources to disrupt service availability without necessarily compromising confidentiality or integrity directly.
To mitigate this vulnerability and restore proper resource lifecycle management, the kernel logic must ensure that the number of paths allocated during creation matches exactly with those expected during destruction. The recommended remediation involves recomputing npaths only after the final transport assignment has been determined by the connection establishment process. By deferring the calculation of path counts until the loopback substitution is confirmed, the system ensures that c_path is sized appropriately for the actual working transport rather than the initial requestor's protocol. This adjustment guarantees that rds_conn_destroy() will iterate over and properly clean up all allocated workqueues corresponding to the active paths. Additionally, any unused entries in the c_path array resulting from mismatched expectations should be explicitly freed alongside the main path structure to prevent dangling pointers. Implementing this fix aligns with secure coding practices for kernel subsystems that handle dynamic resource allocation based on runtime configuration decisions, ensuring consistency between initialization and termination phases of object lifecycles.