[PATCH v2] drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers

[PATCH v2] drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers

[Ashutosh Desai]

Three sideband reply parsers read 16-bit fields as:

  val = (raw->msg[idx] << 8) | (raw->msg[idx+1]);

and check bounds only after the fact. When idx == raw->curlen,
raw->msg[idx+1] reads one byte past the received message data into
the following struct fields (curchunk_len, curchunk_idx, curlen).

Affected functions:
 - drm_dp_sideband_parse_enum_path_resources_ack()
   full_payload_bw_number and avail_payload_bw_number fields
 - drm_dp_sideband_parse_allocate_payload_ack()
   allocated_pbn field
 - drm_dp_sideband_parse_query_payload_ack()
   allocated_pbn field

Fix by using a single combined check (idx + 2 > curlen) before each
2-byte read. Since the check is strictly tighter than idx > curlen,
no separate step is needed.

Cc: stable@vger.kernel.org
Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
---
Changes in v2:
- Drop separate idx > curlen check immediately before idx + 2 > curlen;
  the combined check strictly subsumes it (Lyude Paul)

 drivers/gpu/drm/display/drm_dp_mst_topology.c | 17 ++++-------------
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 9416a48804c8..6e7896193772 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -925,16 +925,13 @@ static bool drm_dp_sideband_parse_enum_path_resources_ack(struct drm_dp_sideband
 	repmsg->u.path_resources.port_number = (raw->msg[idx] >> 4) & 0xf;
 	repmsg->u.path_resources.fec_capable = raw->msg[idx] & 0x1;
 	idx++;
-	if (idx > raw->curlen)
+	if (idx + 2 > raw->curlen)
 		goto fail_len;
 	repmsg->u.path_resources.full_payload_bw_number = (raw->msg[idx] << 8) | (raw->msg[idx+1]);
 	idx += 2;
-	if (idx > raw->curlen)
+	if (idx + 2 > raw->curlen)
 		goto fail_len;
 	repmsg->u.path_resources.avail_payload_bw_number = (raw->msg[idx] << 8) | (raw->msg[idx+1]);
-	idx += 2;
-	if (idx > raw->curlen)
-		goto fail_len;
 	return true;
 fail_len:
 	DRM_DEBUG_KMS("enum resource parse length fail %d %d\n", idx, raw->curlen);
@@ -952,12 +949,9 @@ static bool drm_dp_sideband_parse_allocate_payload_ack(struct drm_dp_sideband_ms
 		goto fail_len;
 	repmsg->u.allocate_payload.vcpi = raw->msg[idx];
 	idx++;
-	if (idx > raw->curlen)
+	if (idx + 2 > raw->curlen)
 		goto fail_len;
 	repmsg->u.allocate_payload.allocated_pbn = (raw->msg[idx] << 8) | (raw->msg[idx+1]);
-	idx += 2;
-	if (idx > raw->curlen)
-		goto fail_len;
 	return true;
 fail_len:
 	DRM_DEBUG_KMS("allocate payload parse length fail %d %d\n", idx, raw->curlen);
@@ -971,12 +965,9 @@ static bool drm_dp_sideband_parse_query_payload_ack(struct drm_dp_sideband_msg_r
 
 	repmsg->u.query_payload.port_number = (raw->msg[idx] >> 4) & 0xf;
 	idx++;
-	if (idx > raw->curlen)
+	if (idx + 2 > raw->curlen)
 		goto fail_len;
 	repmsg->u.query_payload.allocated_pbn = (raw->msg[idx] << 8) | (raw->msg[idx + 1]);
-	idx += 2;
-	if (idx > raw->curlen)
-		goto fail_len;
 	return true;
 fail_len:
 	DRM_DEBUG_KMS("query payload parse length fail %d %d\n", idx, raw->curlen);
-- 
2.34.1

Claude review: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers

[Claude Code Review Bot]

Overall Series Review

Subject: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers
Author: Ashutosh Desai <ashutoshdesai993@gmail.com>
Patches: 1
Reviewed: 2026-05-16T16:05:47.888904

---

This is a single-patch fix for out-of-bounds reads in three DP MST sideband reply parsers. The core problem is real: when reading 16-bit fields as `(raw->msg[idx] << 8) | raw->msg[idx+1]`, the preceding bounds check `idx > raw->curlen` only validates the first byte, not the second. The fix — changing to `idx + 2 > raw->curlen` — is correct and minimal.

However, the patch misses the **same bug** in a fourth function in the same file, and the commit message slightly overstates the practical consequence of the OOB read.

**Verdict**: The fix itself is correct but incomplete. The same 2-byte read pattern with insufficient bounds checking exists in `drm_dp_sideband_parse_resource_status_notify()` at line 1127, which should be fixed in the same patch (or a follow-up mentioned in the cover letter).

---

---
Generated by Claude Code Patch Reviewer

Claude review: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers

[Claude Code Review Bot]

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

[PATCH] drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers

[Ashutosh Desai]

Three sideband reply parsers read 16-bit fields as:

  val = (raw->msg[idx] << 8) | (raw->msg[idx+1]);

and only check bounds after the fact (idx += 2, then
if (idx > raw->curlen)).  When idx == raw->curlen at the
point of the read, raw->msg[idx+1] is one byte past the
received message data, reading into the following struct
fields (curchunk_len, curchunk_idx, curlen).

Affected functions:
 - drm_dp_sideband_parse_enum_path_resources_ack()
   full_payload_bw_number and avail_payload_bw_number fields
 - drm_dp_sideband_parse_allocate_payload_ack()
   allocated_pbn field
 - drm_dp_sideband_parse_query_payload_ack()
   allocated_pbn field

Move the bounds check to immediately before each 2-byte read,
using idx + 2 > raw->curlen, consistent with the fix pattern
used elsewhere in this file.

Signed-off-by: Ashutosh Desai <ashutoshdesai993@gmail.com>
---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 9cef6c576..f2a7dbc5e 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -931,14 +931,13 @@ static bool drm_dp_sideband_parse_enum_path_resources_ack(struct drm_dp_sideband
 	idx++;
 	if (idx > raw->curlen)
 		goto fail_len;
+	if (idx + 2 > raw->curlen)
+		goto fail_len;
 	repmsg->u.path_resources.full_payload_bw_number = (raw->msg[idx] << 8) | (raw->msg[idx+1]);
 	idx += 2;
-	if (idx > raw->curlen)
+	if (idx + 2 > raw->curlen)
 		goto fail_len;
 	repmsg->u.path_resources.avail_payload_bw_number = (raw->msg[idx] << 8) | (raw->msg[idx+1]);
-	idx += 2;
-	if (idx > raw->curlen)
-		goto fail_len;
 	return true;
 fail_len:
 	DRM_DEBUG_KMS("enum resource parse length fail %d %d\n", idx, raw->curlen);
@@ -958,10 +957,9 @@ static bool drm_dp_sideband_parse_allocate_payload_ack(struct drm_dp_sideband_ms
 	idx++;
 	if (idx > raw->curlen)
 		goto fail_len;
-	repmsg->u.allocate_payload.allocated_pbn = (raw->msg[idx] << 8) | (raw->msg[idx+1]);
-	idx += 2;
-	if (idx > raw->curlen)
+	if (idx + 2 > raw->curlen)
 		goto fail_len;
+	repmsg->u.allocate_payload.allocated_pbn = (raw->msg[idx] << 8) | (raw->msg[idx+1]);
 	return true;
 fail_len:
 	DRM_DEBUG_KMS("allocate payload parse length fail %d %d\n", idx, raw->curlen);
@@ -977,10 +975,9 @@ static bool drm_dp_sideband_parse_query_payload_ack(struct drm_dp_sideband_msg_r
 	idx++;
 	if (idx > raw->curlen)
 		goto fail_len;
-	repmsg->u.query_payload.allocated_pbn = (raw->msg[idx] << 8) | (raw->msg[idx + 1]);
-	idx += 2;
-	if (idx > raw->curlen)
+	if (idx + 2 > raw->curlen)
 		goto fail_len;
+	repmsg->u.query_payload.allocated_pbn = (raw->msg[idx] << 8) | (raw->msg[idx + 1]);
 	return true;
 fail_len:
 	DRM_DEBUG_KMS("query payload parse length fail %d %d\n", idx, raw->curlen);
-- 
2.34.1

Claude review: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers

[Claude Code Review Bot]

Overall Series Review

Subject: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers
Author: Ashutosh Desai <ashutoshdesai993@gmail.com>
Patches: 1
Reviewed: 2026-04-12T10:31:51.646390

---

This is a single-patch series that fixes out-of-bounds reads in three DP MST sideband reply parsers. The bug is real: 16-bit field reads access `raw->msg[idx]` and `raw->msg[idx+1]` but only validate bounds *after* incrementing `idx`, meaning the second byte can read past valid message data when `idx == raw->curlen - 1`, or both bytes when `idx == raw->curlen`.

The fix is **correct in approach** — it moves bounds checks before the 2-byte reads using `idx + 2 > raw->curlen`, which is the right pattern. However, there are several issues worth addressing before the patch is merged: missing `Fixes:` and `Cc: stable` tags, some redundant checks introduced by the patch, and a slightly misleading commit message.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers

[Claude Code Review Bot]

Patch Review

**Correctness: The fix is sound.** Each of the three functions now validates that 2 bytes are available before performing the 2-byte read. The removal of the post-read `idx += 2` and trailing bounds check on the last field in each function is correct — nothing uses `idx` afterward, and the pre-check is sufficient.

**Issue 1: Missing `Fixes:` tag and `Cc: stable`.**
This is a bug fix for an OOB read. It should identify the commit that introduced the vulnerable code and include:
```
Fixes: <sha> ("<original commit subject>")
Cc: stable@vger.kernel.org
```
The vulnerable pattern has existed since at least the original MST topology code introduction. A `Fixes:` tag is important for stable kernel backports.

**Issue 2: Redundant bounds checks in `enum_path_resources_ack` and `query_payload_ack`.**

In `drm_dp_sideband_parse_enum_path_resources_ack`, the patch produces:
```c
idx++;
if (idx > raw->curlen)
    goto fail_len;
if (idx + 2 > raw->curlen)
    goto fail_len;
```
The check `idx + 2 > raw->curlen` strictly subsumes `idx > raw->curlen` (if `idx > curlen`, then `idx + 2 > curlen` is trivially true). The first check is now redundant. The same pattern appears in `drm_dp_sideband_parse_query_payload_ack`.

In `drm_dp_sideband_parse_allocate_payload_ack`, the situation is slightly different — the `idx > raw->curlen` check validates the prior single-byte `vcpi` read, so it's arguably more defensible to keep, though it's still technically subsumed.

Consider collapsing the adjacent checks into a single `idx + 2 > raw->curlen` check in each function, or at minimum acknowledge this is intentional for readability.

**Issue 3: Commit message overstates the OOB consequence.**

The commit message states:
> raw->msg[idx+1] is one byte past the received message data, reading into the following struct fields (curchunk_len, curchunk_idx, curlen).

Since `msg` is a 256-byte array (`u8 msg[256]`) and `curlen` is `u8` (max 255), in the common case where `curlen < 255`, the OOB read stays within the `msg` array — it reads stale/uninitialized bytes from the buffer, not the subsequent struct fields. Reading into `curchunk_len` et al. would only happen in the edge case where `curlen == 255` and `idx+1 == 256`, which overruns the array. The commit message should say "reading past the valid message data" rather than implying it always reads into the struct fields that follow `msg[]`.

**Issue 4 (pre-existing, not introduced by this patch):** All three functions read `raw->msg[1]` at `idx = 1` before any bounds check. If `curlen < 2`, this is also an OOB read (within the buffer, reading stale data). This is a pre-existing issue and outside the scope of this patch, but worth noting for a follow-up.

**Summary:** The fix is correct and addresses a real problem. Please add `Fixes:`/`Cc: stable` tags and consider cleaning up the redundant adjacent checks before merging.

---
Generated by Claude Code Patch Reviewer