CVE-2026-89530

LOWCVSS 9.8 · CRITICAL

Signal is active with 1 mentions in latest observed window

Immediate actions

  • Track advisory updates for patch or workaround availability

Recommended action window: Monitor and triage in normal cycle

NVD 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.

0.0/ 10 priority

Sources & remediation

Priority

LOW

Exploitation

NONE

PoC

NONE

Patch

NONE

Momentum

NONE

Threat summary

  • 1 mentions across 1 observed day

What's happening

  • 1 total mentions across 1 day

Deep dive

Activity timeline1 mentions / 1d
00111Mentions · 2026-10-02: 110-02
Full discourse1 post
  • Keith Adler@keithadler

    Reviewed with Claude: About 1 in 5 credit AI help in the commit trailers. What AI was good at: spotting a missing bounds check, a missing lock or a refcount slip in old, rarely audited code. The standouts: - A 2005 IPv6 AH bug (CVE-2026-80844). An unchecked segments_left=255 makes the kernel memmove 4,064 bytes from before its buffer. A code comment claimed it was already verified. Raw packets bypass that check. Sat there ~20 years. - A 2006 RPC GSS client bug (CVE-2026-89541). offset + opaque_len > len can wrap around, so a hostile NFS server gets past the bounds check. - Five BPF verifier fixes credited to Nicholas Carlini. The best one lets a plain allocation into a per-CPU pointer field, which the commit says gives arbitrary kernel read/write. (He has an Anthropic address, so weigh that.) - An NFS-over-RDMA heap overflow (CVE-2026-89530). Replies bigger than a fixed buffer were copied in with no size check. - nfsd refcount bugs a remote NFSv4 client can race, plus SMB client heap overflow and out-of-bounds read bugs that need a malicious server. The caveat: five qdisc fixes look impressive but are one MTU-overflow pattern. One reporter found it, a human maintainer fixed it as a single patch series, and the fixes are only clamps. Not five findings. Reality check: nothing here is unauthenticated remote code execution on a default install. Many of the 1,313 are cosmetic, like a debugfs log message. Recommendation: Good tools, modest findings. Patch anyway.

    00000581
    113 followersView on X

Explore more