In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs-srv: Fix integer underflow in process_read and process_write
usr_len is read from a network-supplied message field (le16_to_cpu)
and used to compute data_len = off - usr_len without validating that
usr_len <= off. A malicious RDMA client can send usr_len > off causing
an integer underflow, resulting in data_len wrapping to a huge size_t
value which is then passed to the rdma_ev callback as a memory length,
leading to out-of-bounds memory access.
Fix by reading and validating usr_len <= off before rtrs_srv_get_ops_ids()
in both process_read() and process_write(), ensuring the early return
path acquires no reference and has no resource leak.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - A remote peer RDMA-WRITE-WITH-IMM's a RTRS_MSG_READ or RTRS_MSG_WRITE carrying attacker-controlled usr_len; rtrs_srv_rdma_done() hands that buffer to process_io_req() then process_read()/process_write(). rtrs_srv_cm_init() listens with RDMA_PS_TCP on IPv6 port 1234 (RoCEv2/iWARP), which is IP-routable.
AC:L - The peer sets le16 usr_len in the RTRS_MSG_READ/WRITE at chunk+off and the IMM payload that rtrs_srv_rdma_done() splits into msg_id and off. Choosing usr_len > off makes size_t data_len = off - usr_len wrap on every call; there is no race and no victim-held state.
PR:N - rtrs_rdma_connect() admits the RDMA_CM CONNECT_REQUEST after checking only RTRS_MAGIC, protocol major version, and cid/uuid; process_info_req() then publishes chunk rkeys and moves to RTRS_SRV_CONNECTED with no credentials, so process_read()/process_write() run unauthenticated.
UI:N - The attacker posts the RDMA-WRITE-WITH-IMM that rtrs_srv_rdma_done() delivers to process_read()/process_write(); no local user must mount a volume, open a file, or otherwise interact.
S:U - process_read()/process_write() invoke rnbd_srv_rdma_ev() in the same host kernel that owns the chunk pages; the OOB access stays inside that kernel and does not escape a VM, guest, or IOMMU domain.
C:H - Underflowed data_len makes usr = page_address(chunk)+off-usr_len point before the chunk. rnbd_srv_rdma_ev() reads the RNBD header there; a sprayed RNBD_MSG_OPEN does unbounded strlen(dev_name), and process_rdma() bio_add_virt_nofail()s a ~4GiB WRITE bvec that copies following linear-map pages onto a device the peer can read back.
I:H - process_rdma() truncates the wrapped size_t to u32 and bio_add_virt_nofail() installs a ~4GiB bvec from the chunk page; submit_bio() of an RNBD_OP_READ therefore writes device data through that bvec into subsequent kernel linear-map pages, an out-of-bounds kernel write.
A:H - rnbd_srv_rdma_ev() immediately loads hdr->type from the wrapped usr pointer, process_msg_open() strlen()s that OOB name, and the ~4GiB bio_add_virt_nofail() bvec walks into holes or MMIO in the linear map; any of those oops/panic the completion path and can be repeated at will.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - A remote peer RDMA-WRITE-WITH-IMM's a RTRS_MSG_READ or RTRS_MSG_WRITE carrying attacker-controlled usr_len; rtrs_srv_rdma_done() hands that buffer to process_io_req() then process_read()/process_write(). rtrs_srv_cm_init() listens with RDMA_PS_TCP on IPv6 port 1234 (RoCEv2/iWARP), which is IP-routable.
AC:L - The peer sets le16 usr_len in the RTRS_MSG_READ/WRITE at chunk+off and the IMM payload that rtrs_srv_rdma_done() splits into msg_id and off. Choosing usr_len > off makes size_t data_len = off - usr_len wrap on every call; there is no race and no victim-held state.
PR:N - rtrs_rdma_connect() admits the RDMA_CM CONNECT_REQUEST after checking only RTRS_MAGIC, protocol major version, and cid/uuid; process_info_req() then publishes chunk rkeys and moves to RTRS_SRV_CONNECTED with no credentials, so process_read()/process_write() run unauthenticated.
UI:N - The attacker posts the RDMA-WRITE-WITH-IMM that rtrs_srv_rdma_done() delivers to process_read()/process_write(); no local user must mount a volume, open a file, or otherwise interact.
S:U - process_read()/process_write() invoke rnbd_srv_rdma_ev() in the same host kernel that owns the chunk pages; the OOB access stays inside that kernel and does not escape a VM, guest, or IOMMU domain.
C:H - Underflowed data_len makes usr = page_address(chunk)+off-usr_len point before the chunk. rnbd_srv_rdma_ev() reads the RNBD header there; a sprayed RNBD_MSG_OPEN does unbounded strlen(dev_name), and process_rdma() bio_add_virt_nofail()s a ~4GiB WRITE bvec that copies following linear-map pages onto a device the peer can read back.
I:H - process_rdma() truncates the wrapped size_t to u32 and bio_add_virt_nofail() installs a ~4GiB bvec from the chunk page; submit_bio() of an RNBD_OP_READ therefore writes device data through that bvec into subsequent kernel linear-map pages, an out-of-bounds kernel write.
A:H - rnbd_srv_rdma_ev() immediately loads hdr->type from the wrapped usr pointer, process_msg_open() strlen()s that OOB name, and the ~4GiB bio_add_virt_nofail() bvec walks into holes or MMIO in the linear map; any of those oops/panic the completion path and can be repeated at will.
CVSS 3.1