CVE-2026-98367 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Clear association under lock if siw_qp_modify fails in siw_accept
We need to clear cep before release state_lock as siw_qp_llp_close and siw_qp_modify->siw_qp_llp_close did.
Otherwise if siw_qp_modify() fails in siw_accept(), the QP's state_lock is released before the error path cleanup. A concurrent ibv_modify_qp() transitioning the QP to ERROR can race in this window:
siw_accept() ibv_modify_qp(ERROR) ---------------------- ---------------------- siw_qp_modify() fails up_write(&qp->state_lock) down_write(&qp->state_lock) nextstate_from_idle(): if (qp->cep) siw_cep_put(qp->cep) <- frees cep qp->cep = NULL goto error cep->qp = NULL <- UAF
Clear qp->cep and drop the association reference taken by siw_cep_get(), all under the write lock held from the initial down_write(&qp->state_lock). Thread B therefore sees qp->cep == NULL, skips its own put, and cannot free the cep before siw_accept() is done with it.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel's RDMA over Converged Ethernet (RoCE) implementation via the Software iWARP driver contains a critical race condition vulnerability within the connection establishment logic. Specifically, in the function responsible for accepting incoming connections, there is an improper handling of resource cleanup when state modification operations fail. The core issue arises from the sequence of operations performed after siw_qp_modify fails during the acceptance process. Under normal circumstances, resources must be released while holding specific synchronization locks to prevent concurrent access issues. However, in this flawed implementation, the connection endpoint structure reference is not cleared before releasing the queue pair state lock. This creates a dangerous window where another thread can intervene and manipulate the same resource concurrently.
The technical flaw centers on the interaction between siw_accept and ibv_modify_qp calls operating on the same Queue Pair object. When siw_qp_modify fails within siw_accept, the code path proceeds to release the write lock associated with the queue pair state without first nullifying the connection endpoint pointer or dropping its reference count. This omission violates fundamental concurrency principles required for safe memory management in kernel space. The missing step involves clearing qp->cep and decrementing the association reference that was previously acquired via siw_cep_get. By failing to perform these actions under the protection of state_lock, the driver leaves the system vulnerable to use-after-free scenarios triggered by concurrent modifications initiated through user-space applications or other kernel subsystems interacting with RDMA resources.
The operational impact of this vulnerability is severe, primarily manifesting as a Use-After-Free condition that can lead to arbitrary code execution, denial of service, or data corruption within the affected system. An attacker who can trigger siw_qp_modify failures and simultaneously invoke ibv_modify_qp to transition the Queue Pair into an ERROR state can exploit the race window. During this interval, one thread may free the connection endpoint structure while another still holds a reference to it. Subsequent access to the freed memory results in undefined behavior, potentially allowing malicious actors to execute arbitrary code with kernel privileges or crash the entire system by corrupting critical data structures. This type of vulnerability undermines the reliability and security guarantees expected from high-performance networking stacks used in enterprise environments.
From an industry standards perspective, this flaw aligns closely with CWE-362, which describes concurrent execution using shared resources with insufficient synchronization. The lack of proper locking during resource cleanup allows multiple threads to access and modify shared state inconsistently. Furthermore, the exploitation technique relates to ATT&CK techniques involving memory corruption for privilege escalation or persistence. Attackers leveraging such race conditions often aim to gain higher-level system access by manipulating kernel objects that are typically protected but become exposed due to logical errors in synchronization primitives. The specific pattern of releasing locks before completing cleanup is a classic example of improper resource management under concurrency constraints, highlighting the need for rigorous review of lock ordering and scope in complex drivers like RDMA implementations.
Mitigation strategies must focus on correcting the order of operations within siw_accept to ensure that all necessary cleanup steps are completed while holding the appropriate write locks. Developers should modify the error handling path to explicitly clear qp->cep and drop the association reference before calling up_write on state_lock. This ensures that any concurrent ibv_modify_qp calls will observe a null pointer for cep, thereby skipping their own put operations and preventing premature freeing of the connection endpoint structure. Additionally, implementing static analysis tools focused on lock ordering violations and race conditions during code reviews can help identify similar patterns early in the development lifecycle. Kernel maintainers should also consider adding debug checks or assertions that verify resource states before releasing locks to catch such discrepancies proactively rather than relying solely on runtime detection mechanisms which may not always trigger reliably under stress conditions.