From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers
Date: Sat, 16 May 2026 16:05:48 +1000
Message-ID: <review-patch1-20260510203128.2884846-1-ashutoshdesai993@gmail.com>
In-Reply-To: <20260510203128.2884846-1-ashutoshdesai993@gmail.com>
References: <20260510203128.2884846-1-ashutoshdesai993@gmail.com> <20260510203128.2884846-1-ashutoshdesai993@gmail.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Patch Review

**The fix is correct.** Changing `idx > raw->curlen` to `idx + 2 > raw->curlen` before each 2-byte read properly ensures both `msg[idx]` and `msg[idx+1]` fall within the valid message data (indices 0..curlen-1). Since `idx + 2 > curlen` strictly subsumes `idx > curlen`, the v2 simplification (dropping the redundant separate check) is appropriate as Lyude requested.

**Removal of trailing checks is fine.** The deleted trailing `idx += 2; if (idx > raw->curlen) goto fail_len;` blocks only validated that the message had no excess bytes *after* the read had already happened. Since the data was already consumed and idx isn't used afterward, these checks served no safety purpose.

**Issue 1: Missed instance of the same bug.** The same vulnerable 2-byte read pattern exists in `drm_dp_sideband_parse_resource_status_notify()`:

```c
// line 1124-1127: same bug pattern, NOT fixed by this patch
if (idx > raw->curlen)
    goto fail_len;

msg->u.resource_stat.available_pbn = (raw->msg[idx] << 8) | (raw->msg[idx + 1]);
```

This has the identical insufficient bounds check before a 2-byte read. The patch should either include this fix or the commit message should note it as a known remaining instance.

**Issue 2 (minor): Commit message overstates consequences.** The commit message claims the OOB read goes "into the following struct fields (curchunk_len, curchunk_idx, curlen)." Looking at the struct definition:

```c
struct drm_dp_sideband_msg_rx {
    u8 chunk[48];
    u8 msg[256];
    u8 curchunk_len;  // follows msg[]
    ...
};
```

Reading past `msg[]` into `curchunk_len` only happens when `idx+1 >= 256`, i.e., `curlen >= 255`. For these MST sideband reply messages, `idx` reaches at most ~6. The practical outcome is reading stale/uninitialized data *within* the `msg[256]` buffer, not leaking adjacent struct fields. The bug is still real (parsing corrupted data from unvalidated bytes), but the "reads into curchunk_len" framing is misleading.

**Issue 3 (observation): Adjacent pre-existing bug.** In the same `drm_dp_sideband_parse_resource_status_notify()` function, `import_guid()` at line 1122 reads 16 bytes from `&raw->msg[idx]` but the preceding check at line 1119 only validates a single byte (`idx > raw->curlen`). This is outside the scope of this patch but worth noting as a follow-up.

**Summary**: The code changes in the patch are correct and the approach is sound. The patch should be extended to also fix `drm_dp_sideband_parse_resource_status_notify()` (line 1124) which has the identical bug, and the commit message consequence description could be made more precise.

---
Generated by Claude Code Patch Reviewer