Answer in brief
CVE-2026-89530 records a Unknown severity vulnerability in svcrdma: Reject inline replies that overflow the pull-up buffer. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=e248aa7be86e8179f20ac0931774ecd746f3f5bf <fcd91b9957462d398792201c239dffaeff1cc8b2 || >=e248aa7be86e8179f20ac0931774ecd746f3f5bf <1949dd1576f7a8aa161b1330c6125df9d53046d5 || >=e248aa7be86e8179f20ac0931774ecd746f3f5bf <8ec60eb51fae37cd3d334ff26e4a7d6fb21ff7cf || >=e248aa7be86e8179f20ac0931774ecd746f3f5bf <0fbe20dfe74b783d255bf389a6ea77aa25dc7860 || 9b65b18f817d9ada2bf67351f24bdcce6789a0bb || d564356e1919d1178568c19af410cfc1a9076663 || >=4.19.22 <4.20 || >=4.20.9 <4.21 | fcd91b9957462d398792201c239dffaeff1cc8b2, 1949dd1576f7a8aa161b1330c6125df9d53046d5, 8ec60eb51fae37cd3d334ff26e4a7d6fb21ff7cf, 0fbe20dfe74b783d255bf389a6ea77aa25dc7860, 4.20, 4.21 |
| Linux/Linuxgeneric | 5.0 | Not reported |
Published upstream
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 11, 2026
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.
Quoted source text, attributed separately from HOL analysis.