Look up another CVE · open CVE-2026-89530 in the interactive tracker
CVE-2026-89530
svcrdma: Reject inline replies that overflow the pull-up buffer
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem net/sunrpc. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89530 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/sunrpc/xprtrdma/svc_rdma_sendto.c
- What this is
- KERNEL NFSD, SUNRPC, AND LOCKD SERVERSMAINTAINERS section matched on net/sunrpc/ · linux-nfs@vger.kernel.org · Supported
- Kernel module
- rpcrdma
Check it on the machine
grep -wE 'CONFIG_SUNRPC|CONFIG_SUNRPC_XPRT_RDMA' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w rpcrdmaPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switches
- CONFIG_SUNRPC, CONFIG_SUNRPC_XPRT_RDMA
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.46%, higher than 38.2% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/sunrpc
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.0 | 6.12.109 | fcd91b995746 |
| 5.0 | 6.18.50 | 1949dd1576f7 |
| 5.0 | 7.2.4 | 8ec60eb51fae |
| 5.0 | 7.3 | 0fbe20dfe74b |
| 4.19.22 | 0 | 0 |
| 4.20.9 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- svcrdma is nfsd's RPC-over-RDMA server transport; a remote NFS/RDMA client reaches svc_rdma_sendto over InfiniBand, RoCE, or iWARP, including IP-routable RoCEv2/iWARP and Soft-RoCE, so this is a network attack.
- AC:LAttack complexity, low
- The attacker fully controls omitting the Write list and Reply chunk and the NFS READ size; with the default 4096-byte pull-up buffer and ~5 Send SGEs, a multi-page inline READ deterministically takes the SGE-exhaustion pull-up path and overflows, with no race or uncontrollable layout.
- PR:NPrivileges required, none
- RDMA-CM accept has no credential check, and AUTH_NULL/AUTH_UNIX need no real account; default NFS exports accept those flavors, so a fabric peer can drive a large READ reply without local or init-namespace privileges.
- UI:NUser interaction, none
- Exploitation requires only attacker-sent RPC-over-RDMA Calls that elicit a large inline reply; no victim mount, click, or other user action is needed beyond nfsd already listening on RDMA.
- S:UScope, unchanged
- The kmalloc overflow and oversized RDMA Send stay inside the host kernel's security authority; this is not a VM, IOMMU, or sandbox escape.
- C:HConfidentiality impact, high
- svc_rdma_xb_linearize() copies past kmalloc sc_xprt_buf, then the inflated sc_sges[0].length is posted with the PD local DMA lkey, so the device reads adjacent kernel memory onto the wire; the heap smash is also leveragable for disclosure.
- I:HIntegrity impact, high
- The unbounded memcpy is a heap out-of-bounds write of attacker-influenced NFS READ payload into adjacent slab objects, enabling corruption of neighboring kernel state and control-flow hijacking.
- A:HAvailability impact, high
- Overflowing a 4KB send buffer by up to the NFS/RDMA max payload smashes adjacent slab and can oops or panic, and posting an SGE longer than the DMA mapping can also fault the device or kernel.