{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-98367", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-98367" ], "published": "2026-10-06T08:47:10Z", "summary": "RDMA/siw: Clear association under lock if siw_qp_modify fails in siw_accept", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: Clear association under lock if siw_qp_modify fails in siw_accept\n\nWe need to clear cep before release state_lock as siw_qp_llp_close and\nsiw_qp_modify->siw_qp_llp_close did.\n\nOtherwise if siw_qp_modify() fails in siw_accept(), the QP's state_lock\nis released before the error path cleanup. A concurrent ibv_modify_qp()\ntransitioning the QP to ERROR can race in this window:\n\n siw_accept() ibv_modify_qp(ERROR)\n ---------------------- ----------------------\n siw_qp_modify() fails\n up_write(&qp->state_lock)\n down_write(&qp->state_lock)\n nextstate_from_idle():\n\t\t\t\t if (qp->cep)\n siw_cep_put(qp->cep) <- frees cep\n qp->cep = NULL\n goto error\n cep->qp = NULL <- UAF\n\nClear qp->cep and drop the association reference taken by siw_cep_get(),\nall under the write lock held from the initial down_write(&qp->state_lock).\nThread B therefore sees qp->cep == NULL, skips its own put, and cannot free\nthe cep before siw_accept() is done with it.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.189", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-98367" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f11e09fe2fc3a11ccdf8f932b68181b0bb1d2078" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e3f039082856adab7e195dea1af45d93dd6a3f1c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ad50d19f3d1ce052b3a146143581e930a1efb33e" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/030306bbb9273af80f14d7af20129661964cd9a7" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/df2584750314336edcbcc21fb388e04b260f35b7" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/9dcc0f4e488b70cff81e0e5717a498c929cf5de3" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/bfdc744bf20ae4c3ef2e470298de5237c5c9a13c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/32cd87f54dd1070020e664ccb0312a9f0fea79b4" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-10-07T06:50:27Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - siw_accept() is called through the ops.iw_accept hook from iw_cm_accept(), which a local process reaches with the RDMA_USER_CM_CMD_ACCEPT command on /dev/infiniband/rdma_cm. The racing side is the uverbs MODIFY_QP command (ibv_modify_qp to ERROR), also local. No wire message carries data that causes the siw_qp_modify() failure, so the attack is local.\nAC:L - The attacker does control both racing threads, since it owns the QP and issues the accept and modify_qp calls itself. Even so, AC is High: in siw_accept the only way siw_qp_modify() can fail is siw_qp_readq_init() hitting a vcalloc() ENOMEM, and IRD/ORD are capped at 128, so the allocations are small. That failure depends on system-wide memory exhaustion, which the attacker cannot produce on demand.\nPR:L - Running rdma_accept and ibv_modify_qp on a QP the user created on an existing siw device needs only ordinary access to the rdma_cm and uverbs device nodes. Creating the siw link through RDMA_NLDEV_CMD_NEWLINK is admin-only, but no privilege is needed to use a device that already exists.\nUI:N - The attacker drives both siw_accept() and the concurrent ibv_modify_qp(ERROR) through their own rdma_cm and verbs calls, and the connecting peer can be the attacker over loopback. No other user has to do anything.\nS:U - The freed siw_cep and the writes into it both stay inside the kernel's own security authority. No VM, IOMMU or sandbox boundary is crossed.\nC:H - siw_qp_nextstate_from_idle() frees the siw_cep by calling siw_cep_put(qp->cep). The error path in siw_accept() then keeps using that freed object: it writes cep->qp = NULL, runs siw_free_cm_id, and calls siw_cep_set_free_and_put. A reclaimed object in that slot gives the attacker a use-after-free primitive that can be built into a kernel memory leak.\nI:H - After the free, the error path writes cep->qp = NULL and does kref and lock operations on the dead siw_cep. That corrupts whatever object has taken over the slot, and this kind of UAF write can be used to corrupt kernel data or hijack control flow.\nA:H - A kref_put or lock operation on the freed siw_cep in siw_cep_set_free_and_put can corrupt the slab or oops the kernel, and that crashes the host." } } }