DF-4181 — Verification Verdict

Status: inconclusive (hardware-gated: no radeon GPU in the QEMU guest) Impact: none on this guest (display-engine OOB read past a GEM object on affected hardware — info disclosure of adjacent VRAM to the physical display) Confidence: certain (absence of any size validation provable from source)

Mechanism (source trace)

1. DRM_IOCTL_MODE_ADDFB2 → drm_mode_addfb2 → drm_internal_framebuffer_create (drm_framebuffer.c:277). framebuffer_check() (drm_framebuffer.c:165-275) validates: format known (via __drm_format_info), width/height within mode_config min/max, width*cpp <= UINT_MAX, height*pitches[i] + offsets[i] <= UINT_MAX (:208), pitches[i] >= width*cpp (:211). It never looks at the buffer object at all (it doesn't have it — handles are resolved by the driver's fb_create).
2. radeon_user_framebuffer_create() (radeon_display.c:1311-1348): drm_gem_object_lookup() on handles[0] (:1320), rejects imported dma-bufs (:1328), allocates the fb (:1334) and calls radeon_framebuffer_init() (:1340). No comparison of required image size vs BO size.
3. radeon_framebuffer_init() (radeon_display.c:1294-1309): drm_helper_mode_fill_fb_struct() fills pitches/format; then straight to drm_framebuffer_init() — again no size check.
4. Scanout path: set_config/page_flip pin the BO (radeon_bo_pin(..., RADEON_GEM_DOMAIN_VRAM, ...) — pinning does not check fb dimensions either) and program the display base address + pitch; the display engine then fetches pitch * crtc_vdisplay bytes starting at the BO — reading far past its end when the fb is larger than the BO. The flip path repeats this (radeon_display.c:524-539, radeon_crtc_page_flip_target pins new_rbo and computes pitch_pixels = fb->pitches[0] / fb->format->cpp[0]).
5. Same gap exists in amdgpu_display_user_framebuffer_create (amd/amdgpu/amdgpu_display.c:523) — this DRM vintage predates the drm_gem_fb size checks; upstream later moved radeon/amdgpu to drm_gem_fb_create which checks per-plane min-size vs BO size.

Impact: an unprivileged user with DRM master/modeset rights (any desktop session via logind) creates a small VRAM BO, registers an oversized fb on it, and modesets: the panel then displays the contents of VRAM immediately following the BO — other applications' buffers. The leak is to the physical display (photo/screen-capture by a second GPU path is not available), so the ceiling is visual disclosure; no kernel memory is involved and no write primitive exists. Rating: Medium (info leak, default desktop configs, needs radeon KMS).

Why it cannot be reproduced on this guest

QEMU guest has no ATI/AMD GPU: no /dev/dri, radeon.ko not loaded. rfb_oob builds and runs; open("/dev/dri/card0") fails ENOENT (run.log).

Fix validation

fix.diff adds the per-plane offsets[i] + pitches[i] * DIV_ROUND_UP(height, vsub) <= radeon_bo_size() check in radeon_framebuffer_init(). Applies cleanly; radeon.ko module built with the patch (fix_build.log — module build, since radeon is not part of X86_64_GENERIC). Expected behavioral change on hardware: the PoC ADDFB2 returns -EINVAL.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.