Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-06T09:18:30.970Z",
  "pubdate": "2026-10-06T09:18:30.970Z",
  "executiveSummary": "This vulnerability involves a Use-After-Free (UAF) condition within the Linux kernel RDMA Software iWARP (siw) component.\nThe flaw occurs during the connection acceptance process, specifically when siw_qp_modify fails while handling a Queue Pair (QP).\nAn improper locking sequence during an error path allows for a race condition with concurrent ibv_modify_qp operations.\nAn attacker capable of triggering concurrent QP state transitions during a failed accept operation could potentially exploit this race to access freed memory.\nThe impact is a local kernel-level memory corruption or potential system instability, depending on the kernel's ability to handle the UAF.\nSuccessful exploitation requires the ability to interact with the RDMA subsystem, typically restricted to users with permissions to open RDMA devices.",
  "technicalDetails": "The vulnerability resides in the siw_accept function within the Linux kernel RDMA stack. The root cause is an inadequate synchronization window regarding the cleanup of the Connection Endpoint (CEP) association for a Queue Pair (QP).\nIn the original implementation, siw_accept would release the QP's state_lock before completing the full error path cleanup if siw_qp_modify returned an error. This premature release of the write lock opens a race window where concurrent kernel threads can intervene.\nSpecifically, if a user-space process initiates an ibv_modify_qp system call simultaneously to transition the QP state to ERROR, that thread acquires the same state_lock after it is dropped by the failing siw_accept thread.\nDuring this race, the concurrent process executes nextstate_from_idle, which checks if qp->cep exists. Finding it active, the racing thread proceeds to call siw_cep_put(qp->cep) and sets qp->cep to NULL, effectively freeing the memory associated with the CEP.\nSubsequently, the original siw_accept thread resumes execution in the error path, attempting to access cep->qp = NULL. Because the memory formerly pointed to by cep has already been deallocated by the racing thread, the system triggers a Use-After-Free (UAF) condition.\nTo exploit this, an attacker must time the failure of an RDMA connection establishment precisely with an ibv_modify_qp transition to the error state. By ensuring the CEP is released by the racing thread while the failing thread still holds a reference pointer in the error handling logic, the attacker induces access to the invalidated memory address.\nThe vulnerability is localized to the state management logic of the siw driver, specifically how it manages the lifecycle of connection endpoints during QP teardown or modification failures. The lack of atomic cleanup inside the initial write-lock critical section is the primary driver of this concurrency flaw."
}