CVE-2026-89530: Linux kernel · svcrdma: Reject inline replies that overflow the pull-up buffer
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 9.8 Critical · fixed in fcd91b9957462d398792201c239dffaeff1cc8b2 : patch Linux kernel as a priority.
Data as of 26 Oct 2026, 13:07 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 39% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers can reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in fcd91b9957462d398792201c239dffaeff1cc8b2, 8068358f445a11296328ffa7c524701596814a17, 1949dd1576f7a8aa161b1330c6125df9d53046d5 +4
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 11 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: svcrdma: Reject inline replies that overflow the pull-up buffer An RPC-over-RDMA client can request a reply, such as an NFS READ payload, without providing a Write list or a Reply chunk to carry it. When such a reply needs more scatter/gather entries than the device's Send Queue supports, svc_rdma_pull_up_needed() selects pull-up and svc_rdma_pull_up_reply_msg() linearizes the whole reply into sctxt->sc_xprt_buf. That buffer is only sc_max_req_size bytes, while the reply on this path is bounded only by the client's request, so svc_rdma_xb_linearize() copies past the end of the buffer and corrupts adjacent slab memory. The oversized length is then stored in sc_sges[0].length and posted, so the device also reads beyond the mapped region. The SGE-exhaustion branch is the only pull-up path that can exceed the buffer: the threshold branch pulls up only replies smaller than RPCRDMA_PULLUP_THRESH, and replies that fit the device's SGE budget are sent directly without linearization. Make svc_rdma_pull_up_needed() report -E2BIG when the reply it would pull up cannot fit sc_max_req_size, and fail the request with ERR_CHUNK as RFC 8166 Section 4.5.3 directs rather than dropping the connection. The helper no longer answers a simple yes/no question: it now reports pull-up, no pull-up, or -E2BIG for a reply too large to linearize. Rename svc_rdma_pull_up_needed() to svc_rdma_check_pull_up() so its name no longer implies a boolean predicate.
References
- git.kernel.org/stable/c/8068358f445a11296328ffa7c524701596814a17 (opens in a new tab)
- git.kernel.org/stable/c/fcd91b9957462d398792201c239dffaeff1cc8b2 (opens in a new tab)
- git.kernel.org/stable/c/1949dd1576f7a8aa161b1330c6125df9d53046d5 (opens in a new tab)
- git.kernel.org/stable/c/8ec60eb51fae37cd3d334ff26e4a7d6fb21ff7cf (opens in a new tab)
- git.kernel.org/stable/c/0fbe20dfe74b783d255bf389a6ea77aa25dc7860 (opens in a new tab)