GHSA-VJ46-79MQ-HRMQ
Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-14 15:32In the Linux kernel, the following vulnerability has been resolved:
svcrdma: Fix pcl_for_each_segment for empty chunks
When a parsed chunk list contains a chunk whose ch_segcount is zero, pcl_for_each_segment computes its inclusive upper bound as &chunk->ch_segments[ch_segcount - 1]. ch_segcount is u32, so the subtraction wraps to 0xFFFFFFFF and the bound lands far past the ch_segments flex array. The loop body then walks unrelated memory at sizeof(struct svc_rdma_segment) stride until it faults.
A zero-segcount chunk is reachable from the wire: xdr_check_write_chunk() only rejects segcount values greater than rc_maxpages, and pcl_alloc_write() links a freshly allocated chunk onto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs, so a Write or Reply chunk advertising zero segments leaves ch_segcount == 0 on the list. When the transport has negotiated Send-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four PCLs with pcl_for_each_segment and dereferences segment->rs_handle on each iteration, turning the underflow into an out-of-bounds read and a general protection fault.
xdr_check_write_list / xdr_check_reply_chunk
pcl_alloc_write()
chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */
list_add_tail(&chunk->ch_list, &pcl->cl_chunks)
/* fill loop iterates zero times for wire segcount 0 */
svc_rdma_get_inv_rkey()
pcl_for_each_chunk(rc_write_pcl)
pcl_for_each_segment(segment, chunk)
pos <= &ch_segments[0u - 1u] /* 0xFFFFFFFF */
segment->rs_handle /* OOB read -> GPF */
Fix by switching the macro to a half-open upper bound that uses ch_segcount directly. For ch_segcount == 0 the loop start equals the loop end and the body is skipped; for ch_segcount > 0 the iteration range is unchanged. All six existing call sites in net/sunrpc/xprtrdma/svc_rdma_recvfrom.c and net/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound, so no caller changes are needed.
{
"affected": [],
"aliases": [
"CVE-2026-89532"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T20:19:36Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: Fix pcl_for_each_segment for empty chunks\n\nWhen a parsed chunk list contains a chunk whose ch_segcount is zero,\npcl_for_each_segment computes its inclusive upper bound as\n\u0026chunk-\u003ech_segments[ch_segcount - 1]. ch_segcount is u32, so the\nsubtraction wraps to 0xFFFFFFFF and the bound lands far past the\nch_segments flex array. The loop body then walks unrelated memory at\nsizeof(struct svc_rdma_segment) stride until it faults.\n\nA zero-segcount chunk is reachable from the wire:\nxdr_check_write_chunk() only rejects segcount values greater than\nrc_maxpages, and pcl_alloc_write() links a freshly allocated chunk\nonto rc_write_pcl/rc_reply_pcl before its segment-fill loop runs,\nso a Write or Reply chunk advertising zero segments leaves\nch_segcount == 0 on the list. When the transport has negotiated\nSend-With-Invalidate, svc_rdma_get_inv_rkey() iterates all four\nPCLs with pcl_for_each_segment and dereferences segment-\u003ers_handle\non each iteration, turning the underflow into an out-of-bounds read\nand a general protection fault.\n\n xdr_check_write_list / xdr_check_reply_chunk\n pcl_alloc_write()\n chunk = pcl_alloc_chunk(...) /* ch_segcount = 0 */\n list_add_tail(\u0026chunk-\u003ech_list, \u0026pcl-\u003ecl_chunks)\n /* fill loop iterates zero times for wire segcount 0 */\n\n svc_rdma_get_inv_rkey()\n pcl_for_each_chunk(rc_write_pcl)\n pcl_for_each_segment(segment, chunk)\n pos \u003c= \u0026ch_segments[0u - 1u] /* 0xFFFFFFFF */\n segment-\u003ers_handle /* OOB read -\u003e GPF */\n\nFix by switching the macro to a half-open upper bound that uses\nch_segcount directly. For ch_segcount == 0 the loop start equals the\nloop end and the body is skipped; for ch_segcount \u003e 0 the iteration\nrange is unchanged. All six existing call sites in\nnet/sunrpc/xprtrdma/svc_rdma_recvfrom.c and\nnet/sunrpc/xprtrdma/svc_rdma_rw.c remain correct under the new bound,\nso no caller changes are needed.",
"id": "GHSA-vj46-79mq-hrmq",
"modified": "2026-09-14T15:32:27Z",
"published": "2026-09-11T21:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89532"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06d0390c37fa6714624af771bd72bbf1a7ed9bb1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e2e3481e39103a386b86be1c33eaef97cbdf16e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3a78b841879c2a3243f74edc514236fb2907167f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d33a7e6bf6c6b293a266a617201285a1ad32c56"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9c5a03c3dc505c0295339b0a1b9e4fe36447e482"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1c954ca4977a4e6ec73ef92fe48073ec54f9fc8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7713a784c59515d0aba558c8f5df6a0164dd3a9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.