Claude review: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Correctness: Good.** The patch addresses two distinct but related issues:

1. **`drm_dp_sideband_parse_remote_dpcd_read()`** — Already had `idx > raw->curlen` bounds checks after each `idx++`, but was missing validation that the `memcpy` length (`num_bytes`) wouldn't cause a read past the received data. The added check:
   ```c
   if (idx + repmsg->u.remote_dpcd_read_ack.num_bytes > raw->curlen)
       goto fail_len;
   ```
   is correct. At this point `idx` is an `int` (value 3), `num_bytes` is `u8` (max 255), so no integer overflow risk. `curlen` is `u8` and the comparison promotes to `int`.

2. **`drm_dp_sideband_parse_remote_i2c_read_ack()`** — Was missing *both* the post-increment `idx > raw->curlen` check *and* the `idx + num_bytes > raw->curlen` check before the `memcpy`. The `/* TODO check */` comment had been there since the code was introduced, so this resolves a known gap. The patch correctly adds both checks and removes the TODO.

**Destination buffer safety:** Both `remote_dpcd_read_ack.bytes` and `remote_i2c_read_ack.bytes` are `u8 bytes[255]` (verified in `drm_dp_mst_helper.h:284,300`), and `num_bytes` is `u8` (max 255), so the destination buffer can never overflow.

**Source buffer safety:** `raw->msg` is 256 bytes (`drm_dp_mst_helper.h:172`), `curlen` is `u8` (max 255). The new checks ensure `idx + num_bytes <= curlen <= 255`, so the `memcpy` stays within bounds of both the valid data and the buffer itself.

**Nits / suggestions:**

- **Missing `Fixes:` tag.** This is a security-relevant fix and should reference the original commit that introduced the code (likely `ad7f8a1f9ced` or similar from the initial MST sideband parser). Kernel maintainers will likely request this before applying.

- **Missing `Cc: stable@vger.kernel.org`.** An OOB read from external input is a security issue that should be backported to stable kernels.

- The commit message says *"reads past the received data into whatever follows in raw->msg[]"* — this is slightly imprecise. With `idx` at 3 and `num_bytes` up to 255, the memcpy could read up to `msg[258]`, which is 2 bytes past the end of `msg[256]` into adjacent struct fields (`curchunk_len`, `curchunk_idx`). So it's not only reading uninitialized *within* `msg[]` but potentially a small struct-bounded OOB. The practical impact is the same (info leak of kernel memory), but the description could be more precise.

- No functional concerns with the code itself — it follows the exact same validation pattern as the rest of the file (e.g., `drm_dp_sideband_parse_enum_path_resources_ack` at line 924).

---
Generated by Claude Code Patch Reviewer