DF-1165 PoC verification — source-level trace of drm_parse_tiled_block OOB read past EDID extension.

drm is not in X86_64_GENERIC; it exists only as a kld module. Loading drm on the QEMU guest succeeds but attaches to no device (no GPU), so no connector → no EDID read → drm_parse_tiled_block is never invoked. Verification is by source-level trace + build-validation of the fix.

Bug location

• sys/dev/drm/drm_edid.c:5103 — drm_parse_tiled_block entry
• sys/dev/drm/drm_edid.c:5112-5135 — reads up to topology_id[7] (offset 23)
• sys/dev/drm/drm_edid.c:5174-5177 — caller loop only checks num_bytes vs length, not vs struct size
• sys/dev/drm/include/drm/drm_displayid.h:67-74 — displayid_tiled_block layout (24B)

Mechanism

Caller guarantees idx + 3 + num_bytes <= length but not num_bytes >= 21 (the tiled-block body size). A DATA_BLOCK_TILED_DISPLAY block at idx near the end of a 128-byte EDID extension with small num_bytes (e.g. 4) causes drm_parse_tiled_block to read offsets up to 23 from the block start, walking past the extension into adjacent kernel heap. Leaked bytes flow to connector->tile_h/v_size and tile->topology_id (IDR-persisted).

Reproduce

1. Apply fix.diff to /usr/src.
2. cd /usr/src/sys/dev/drm/drm && make KMOD=drm → drm.ko builds clean.
3. Runtime test requires DRM-attached GPU + malicious monitor/adapter/VM display with crafted DisplayID (not present on this guest).

See VERDICT.md for the full analysis.

DF-1165 — drm_parse_tiled_block: heap OOB read of EDID extension (source-only verification)

Verdict: REPRODUCED at source level (drm is a kld module, not in GENERIC; not runtime-triggerable here without a DRM-attached GPU + crafted EDID)

Mechanism

drm is not in X86_64_GENERIC (no device drm in sys/config/X86_64_GENERIC). It exists only as the loadable module /boot/kernel/drm.ko and is parent to amdgpu.ko/radeon.ko/i915.ko.

drm_parse_display_id walks the DisplayID blocks of an EDID extension (sys/dev/drm/drm_edid.c:5174-5177):

while (block = (struct displayid_block *)&displayid[idx],
       idx + sizeof(struct displayid_block) <= length &&
       idx + sizeof(struct displayid_block) + block->num_bytes <= length &&
       block->num_bytes > 0) {

This guarantees idx + 3 + num_bytes <= length (length is typically 128 — one EDID extension block). It does not guarantee that num_bytes is large enough to cover the specific block type being parsed.

When the block tag is DATA_BLOCK_TILED_DISPLAY (0x12), control enters drm_parse_tiled_block (sys/dev/drm/drm_edid.c:5103-5155), which casts the block to struct displayid_tiled_block and reads fields out to offset 23 from the block start (sys/dev/drm/include/drm/drm_displayid.h:67-74):

/* drm_edid.c:5106 */
struct displayid_tiled_block *tile = (struct displayid_tiled_block *)block;
/* 5112 */ w = tile->tile_size[0] | tile->tile_size[1] << 8;       /* offsets 7..10 */
/* 5113 */ h = tile->tile_size[2] | tile->tile_size[3] << 8;
/* 5115 */ num_v_tile = (tile->topo[0] & 0xf) | (tile->topo[2] & 0x30); /* offsets 4..6 */
/* 5117 */ tile_v_loc = (tile->topo[1] & 0xf) | ...;
/* 5128 */ connector->tile_h_size = w + 1;
/* 5135 */ DRM_DEBUG_KMS("vend %c%c%c\n", tile->topology_id[0..2]);    /* offsets 16..18 */
/* 5137 */ tg = drm_mode_get_tile_group(connector->dev, tile->topology_id); /* offsets 16..23 */

struct displayid_tiled_block is 24 bytes (3-byte base + 21-byte body). The function reads up to topology_id[7] at offset 23 from the block start. The caller only guaranteed idx + 3 + num_bytes <= length — it never checked num_bytes >= 21.

Worked example. EDID extension length = 128. A DATA_BLOCK_TILED_DISPLAY block placed at idx = 120 with num_bytes = 4 passes the caller's loop (120 + 3 + 4 = 127 <= 128) but drm_parse_tiled_block then reads bytes at absolute offsets 120 + {4..23} = {124..143}. Bytes 128..143 (up to 16 bytes) lie past the EDID extension in kernel heap. The finding's claim of "11 bytes past 128-byte EDID extension" corresponds to a slightly different placement but is the same class — read past the declared extension into adjacent heap.

The leaked bytes flow into: - connector->tile_h_size / tile_v_size (settable via DRM ioctls after the fact, but originally populated from this OOB read), - tile->topology_id (8-byte buffer) used to allocate/create a drm_tile_group IDR entry — so the OOB heap bytes get persisted in a kernel IDR and indirectly influence connector state.

Trigger reachability on this guest

• The QEMU guest has no GPU. drm.ko does load, but with no DRM device attached there is no connector → no EDID read → drm_parse_tiled_block is never invoked.
• A malicious monitor / DP-HDMI adapter / VM virtual display is the realistic threat model. None is present here.

Fix

fix.diff adds the missing struct-size check at the entry of drm_parse_tiled_block:

if (block->num_bytes < sizeof(struct displayid_tiled_block) -
    sizeof(struct displayid_block))
    return -EINVAL;

(= num_bytes < 21). On a malformed block the function now returns early instead of reading off the end of the EDID extension.

Build verification of the fix

drm.ko built successfully from the patched source on the guest (cc 8.3 [DragonFly], full module build with -j6):

=== DRM_BUILD_DONE rc=0 ===

Full output captured to /root/drm_build.log on the guest; key tail in build.log. The fix is build-clean (placed after all declarations to avoid the -Wold-style-declaration / C90 declaration-after-statement warning).

Fix-validation status

not_testable — runtime trigger requires a DRM-attached GPU whose connector EDID (or a hot-plugged malicious monitor / DP-HDMI adapter / VM virtual display) carries a crafted DisplayID tiled block with num_bytes < 21. The guest has no GPU. We confirmed the fix applies cleanly and the patched full drm.ko module compiles; the change adds a single comparison.