[PATCH AUTOSEL 6.19-5.10] rnbd-srv: Zero the rsp buffer before using it

[Sasha Levin <sashal@kernel.org>]

From: Md Haris Iqbal <haris.iqbal@ionos.com>

[ Upstream commit 69d26698e4fd44935510553809007151b2fe4db5 ]

Before using the data buffer to send back the response message, zero it
completely. This prevents any stray bytes to be picked up by the client
side when there the message is exchanged between different protocol
versions.

Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com>
Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The entire data path is now clear. Here is my complete analysis:

---

## Complete Analysis

### 1. COMMIT MESSAGE ANALYSIS

The commit message states: "Before using the data buffer to send back
the response message, zero it completely. This prevents any stray bytes
to be picked up by the client side when there the message is exchanged
between different protocol versions."

While the commit message frames this as a protocol compatibility
concern, the underlying issue is actually an **information leak
vulnerability** — stale kernel memory data is sent over the network to a
remote client.

### 2. CODE CHANGE ANALYSIS

The fix adds two `memset(rsp, 0, sizeof(*rsp))` calls:

**First:** In `rnbd_srv_fill_msg_open_rsp()` before filling the
`rnbd_msg_open_rsp` structure (56 bytes total). Without the memset, 13
bytes are **never explicitly set**:
- `hdr.__padding` (2 bytes) — struct padding field
- `obsolete_rotational` (1 byte) — deprecated field, never written
- `reserved[10]` (10 bytes) — explicitly reserved for future use

**Second:** In `process_msg_sess_info()` before filling the
`rnbd_msg_sess_info_rsp` structure (36 bytes total). Without the memset,
33 bytes are **never explicitly set**:
- `hdr.__padding` (2 bytes) — struct padding field
- `reserved[31]` (31 bytes) — reserved bytes

### 3. THE BUG MECHANISM — CONFIRMED INFORMATION LEAK

Tracing the complete data path reveals this is a real information leak
over the network:

1. **Buffer allocation**: The RDMA chunk pages are allocated via
   `alloc_pages(GFP_KERNEL, ...)` in `get_or_create_srv()` (`rtrs-
   srv.c:1435`). `alloc_pages` does **not** zero memory (unlike
   `__GFP_ZERO` or `get_zeroed_page()`).

2. **Buffer reuse**: The chunk pages (`srv->chunks[buf_id]`) are
   allocated once at server initialization and **reused** across all
   RDMA operations. Each chunk may contain leftover data from previous
   block I/O operations (data read from block devices being served to
   other clients).

3. **Response buffer**: The `data` pointer in `rnbd_srv_rdma_ev()` is
   `page_address(srv->chunks[buf_id])`, pointing directly into these
   non-zeroed, reused RDMA pages.

4. **Client request direction**: Both `send_msg_open()` and
   `send_msg_sess_info()` on the client side use the `READ` direction
   for RTRS. This means the server processes these via `process_read()`,
   setting `id->dir = READ`.

5. **Response sent via RDMA WRITE**: In `rtrs_srv_resp_rdma()`, because
   `id->dir == READ` and `sg_cnt != 0`, the `rdma_write_sg()` function
   is called. This performs an `IB_WR_RDMA_WRITE` operation, sending the
   contents of the server's chunk buffer directly to the client's memory
   via RDMA. The DMA mapping is `DMA_BIDIRECTIONAL`, and
   `ib_dma_sync_single_for_device()` syncs the full response before
   transmission.

6. **What leaks**: The 13 uninitialized bytes in `rnbd_msg_open_rsp` and
   33 uninitialized bytes in `rnbd_msg_sess_info_rsp` contain whatever
   was previously stored in the reused RDMA chunk page. This could
   include **block device data from previous I/O operations** —
   potentially data belonging to other clients or other block devices.

### 4. SECURITY IMPACT

This is a **cross-client kernel memory information leak over the
network**:
- The server leaks up to 46 bytes of stale data per control message
  exchange
- The stale data can include block device content from other clients'
  I/O operations
- The data is transmitted over RDMA (network), reaching a potentially
  different machine
- This has been present since RNBD was introduced in Linux 5.8 (commit
  `2de6c8de192b9`)

### 5. FIX QUALITY

- **Size**: 2 lines added (`memset` calls), no lines removed
- **Correctness**: Obviously correct — zeroing a buffer before partially
  filling it is a standard, well-understood pattern
- **Risk**: Zero regression risk. The memset zeroes the entire
  structure, then the code overwrites the relevant fields. This is
  strictly safer than the original code.
- **Self-contained**: No dependencies on other commits
- **Tested in mainline**: Authored and reviewed by RNBD maintainers
  (IONOS team), merged by Jens Axboe (block layer maintainer)

### 6. APPLICABILITY

RNBD has been present since kernel 5.8. This fix applies to all stable
trees that include RNBD (5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y, etc.).
The patch should apply cleanly since the affected functions haven't
changed structurally.

### 7. CONCLUSION

This is a small, surgical fix for a confirmed information leak
vulnerability where stale kernel memory (potentially containing other
clients' block device data) is sent over the network via RDMA to remote
clients. It meets all stable kernel criteria:
- Fixes a real security/data-integrity bug (information leak over
  network)
- Obviously correct (memset before partial initialization)
- Small and contained (2 lines, 1 file)
- No new features or APIs
- Zero regression risk
- Has been in mainline; authored by subsystem developers

**YES**

 drivers/block/rnbd/rnbd-srv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/block/rnbd/rnbd-srv.c b/drivers/block/rnbd/rnbd-srv.c
index 2df8941a6b146..6afac85c110f2 100644
--- a/drivers/block/rnbd/rnbd-srv.c
+++ b/drivers/block/rnbd/rnbd-srv.c
@@ -538,6 +538,8 @@ static void rnbd_srv_fill_msg_open_rsp(struct rnbd_msg_open_rsp *rsp,
 {
 	struct block_device *bdev = file_bdev(sess_dev->bdev_file);
 
+	memset(rsp, 0, sizeof(*rsp));
+
 	rsp->hdr.type = cpu_to_le16(RNBD_MSG_OPEN_RSP);
 	rsp->device_id = cpu_to_le32(sess_dev->device_id);
 	rsp->nsectors = cpu_to_le64(bdev_nr_sectors(bdev));
@@ -644,6 +646,7 @@ static void process_msg_sess_info(struct rnbd_srv_session *srv_sess,
 
 	trace_process_msg_sess_info(srv_sess, sess_info_msg);
 
+	memset(rsp, 0, sizeof(*rsp));
 	rsp->hdr.type = cpu_to_le16(RNBD_MSG_SESS_INFO_RSP);
 	rsp->ver = srv_sess->ver;
 }
-- 
2.51.0