MANUALLY_VERIFIED_REPORT
package: kernel-6.19.11-200.fc43
------
Summary: Heap out-of-bounds write in the Linux kernel RPC-over-RDMA server reply path (`net/sunrpc/xprtrdma/svc_rdma_sendto.c`). A crafted RPC-over-RDMA client can send a large NFS READ request with an empty Write list and no Reply chunk, causing the server to linearize the entire multi-page reply (up to 4 MB) into a fixed-size 4096-byte heap buffer (`sc_xprt_buf`) without bounds checking, resulting in a kernel heap overflow. This can crash the server (denial of service) or, with a carefully crafted payload, corrupt adjacent kernel heap objects for potential code execution.
The vulnerable code path:
1. The buffer is allocated at 4096 bytes (`svc_rdma_sendto.c`, `svc_rdma_send_ctxt_alloc()`):
```c
buffer = kmalloc_node(rdma->sc_max_req_size, GFP_KERNEL, node); /* 4096 */
xdr_buf_init(&ctxt->sc_hdrbuf, ctxt->sc_xprt_buf, rdma->sc_max_req_size);
```
2. With no Write chunk from the client, payload marking is skipped (`svc_rdma_sendto.c`, `svc_rdma_result_payload()`):
```c
chunk = rctxt->rc_cur_result_payload;
if (!length || !chunk) /* chunk is NULL when Write list is empty */
return 0;
```
3. So `pcl_process_nonpayloads()` passes the entire reply to the actor (`svc_rdma_pcl.c`):
```c
chunk = pcl_first_chunk(pcl);
if (!chunk || !chunk->ch_payload_length)
return actor(xdr, data); /* whole reply treated as non-payload */
```
4. The pull-up decision checks SGE count but never checks buffer capacity (`svc_rdma_sendto.c`, `svc_rdma_pull_up_needed()`):
```c
if (args.pd_length < RPCRDMA_PULLUP_THRESH)
return true;
return args.pd_num_sges >= rdma->sc_max_send_sges; /* no size-vs-buffer check */
```
5. The linearizer copies without bounds checking (`svc_rdma_sendto.c`, `svc_rdma_xb_linearize()`):
```c
memcpy(args->pd_dest, xdr->head[0].iov_base, xdr->head[0].iov_len);
/* ... */
memcpy(args->pd_dest, page_address(ppages) + pageoff, len); / OVERFLOW HERE */
```
Requirements to exploit: The attacker needs network access to an NFS/RDMA service (InfiniBand or RoCE fabric) and valid NFS credentials (AUTH_SYS or Kerberos) sufficient to issue a READ request against an exported file. AUTH_SYS only requires being on an allowed IP/subnet with a valid UID claim. The NFS/RDMA server must be running with default configuration (`sunrpc.svc_rdma.max_req_size=4096`). The attacker must use a crafted RPC-over-RDMA client that omits Write and Reply chunks on a large READ request — stock Linux NFS clients do not produce this malformed pattern. No special privileges or user interaction are required beyond the initial NFS access.
Component affected: kernel (net/sunrpc/xprtrdma/svc_rdma_sendto.c)
Version affected: Needs further investigation. The vulnerable pull-up linearization path has been present since the `pcl_process_nonpayloads` / `svc_rdma_xb_linearize` architecture was introduced. Likely affects all currently supported stable kernels with `CONFIG_SUNRPC_XPRT_RDMA` + `CONFIG_NFSD` enabled.
Patch available: no
Version fixed (if any already): N/A
Upstream coordination: Not yet notified. Reporter submitted directly. Upstream notification should be coordinated via security.
CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — 8.8 (HIGH)
Metric 
Value 
Rationale 
--------
-------
-----------
AV 
N 
NFS/RDMA listens on a network port; RoCEv2 deployments are IP-routable. 
AC 
L 
Default `max_req_size` (4096) and `sc_max_send_sges` (5) are the vulnerable values; no special conditions beyond a deployed NFS/RDMA service. 
PR 
L 
Requires valid NFS credentials (AUTH_SYS or Kerberos) to issue a READ against an export. 
UI 
N 
No user interaction required. 
S 
U 
Impact confined to the kernel hosting the NFS/RDMA service. 
C 
H 
Kernel heap corruption can expose adjacent kernel memory contents. 
I 
H 
Heap out-of-bounds write can corrupt arbitrary adjacent kernel objects; potential for code execution. 
A 
H 
Reliable kernel crash/panic on overflow. 
Impact: Important. While the attacker requires low-privilege NFS credentials (AUTH_SYS), the vulnerability escalates from constrained NFS file access to a kernel heap overflow on the server. This enables denial of service (reliable kernel crash) and potential arbitrary kernel code execution — a privilege boundary that AUTH_SYS alone does not cross. The practical impact depends on deployment: NFS/RDMA requires RDMA hardware and explicit configuration, so exposure is limited to HPC, storage, and datacenter environments rather than general-purpose servers.
Steps to reproduce if available:
1. Build a kernel with `CONFIG_SUNRPC_XPRT_RDMA`, `CONFIG_NFSD`, and `CONFIG_KASAN`. Leave `sunrpc.svc_rdma.max_req_size` at the default (4096).
2. Start NFSd over RDMA on a device with standard default send-SGE budget. Export a readable file larger than 12288 bytes.
3. From a crafted RPC-over-RDMA client, send an NFSv3 READ request via `rdma_msg` with an empty Write list and no Reply chunk. Request at least 12288 bytes so the reply payload occupies three pages.
4. The server generates a multi-page reply. Because no Write chunk exists, `svc_rdma_result_payload()` is a no-op (`rc_cur_result_payload` is NULL). `pcl_process_nonpayloads()` treats the full reply as non-payload. `svc_rdma_pull_up_needed()` forces linearization because `pd_num_sges` (5) matches `sc_max_send_sges` (5). `svc_rdma_xb_linearize()` copies ~12 KB into the 4096-byte `sc_xprt_buf`.
5. With KASAN enabled, expect a heap out-of-bounds write report in `svc_rdma_xb_linearize()` / `svc_rdma_pull_up_reply_msg()` during the `memcpy()` sequence.
------
This report was generated using AI technology. Always review AI-generated content prior to use