# DF-4183 — Verification Verdict (amdgpu twin of DF-4181)

**Status:** inconclusive (hardware-gated: no AMD/ATI 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,
   width/height within mode_config limits (:288-298),
   `height*pitches[i] + offsets[i] <= UINT_MAX` (:208),
   `pitches[i] >= width*cpp` (:211), block alignment for some formats.
   **It never looks at the buffer object** (it cannot — GEM handles are
   resolved by the driver's `fb_create`, dispatched at :310).
2. `amdgpu_display_user_framebuffer_create()` (amdgpu_display.c:523-558):
   `drm_gem_object_lookup()` (:531), rejects imported dma-bufs (:539 — the
   DF-1717 neighborhood), `kzalloc` (:544), calls
   `amdgpu_display_framebuffer_init()` (:550). **No comparison of required
   image size vs BO size.** It is registered as `.fb_create` for **both**
   display stacks in this tree:
   - legacy: `amdgpu_mode_funcs` (amdgpu_display.c:560-561) — used by
     DCE8/DCE10/DCE11 ASICs;
   - DC (DAL): `amdgpu_dm_funcs` (amdgpu_dm.c:945) — used by DCE12/DCN.
   So the gap is ASIC-uniform: every amdgpu chip this driver supports.
3. `amdgpu_display_framebuffer_init()` (amdgpu_display.c:506-520):
   `drm_helper_mode_fill_fb_struct()` (:513) fills pitches/format from
   `mode_cmd`; then straight to `drm_framebuffer_init()` (:514) — again no
   size check and no other content validation (the DRM core owns the format
   check). Same helper is reused by the kernel-internal fbdev path
   (amdgpu_fb.c:248) whose sizes are kernel-computed (not attacker-chosen),
   so the fix belongs in this helper and covers both callers harmlessly.
4. Scanout paths pin and program **without re-checking** fb dimensions vs
   `amdgpu_bo_size()`:
   - legacy DCE11: `dce_v11_0_crtc_do_set_base` — `amdgpu_bo_pin(abo,
     AMDGPU_GEM_DOMAIN_VRAM)` (dce_v11_0.c:1904), `fb_location =
     amdgpu_bo_gpu_offset(abo)` (:1910), then programs `GRPH_X_END =
     fb->width` / `GRPH_Y_END = fb->height` (:2073-2074), `GRPH_PITCH =
     pitches[0]/cpp` (:2076-2077) and `VIEWPORT_SIZE = crtc mode`
     (:2088-2091): the display engine fetches `pitch * height` bytes from
     the pinned base address regardless of the object's true size.
     Same shape: dce_v10_0.c:1862, dce_v8_0.c:1791.
   - DC: `dm_plane_helper_prepare_fb` (amdgpu_dm.c:3484) →
     `amdgpu_bo_pin(rbo, domain)` (:3518); plane attributes consume fb
     pitches/dims downstream — no size gate.
   - page flip: `amdgpu_display_crtc_page_flip_target`
     (amdgpu_display.c:146) → `amdgpu_bo_pin(new_abo, …)` (:191) — the
     flip work then swaps the scanout base to the undersized pinned BO
     (amdgpu_display.c:109).

Impact: an unprivileged user with DRM master/modeset rights (any desktop
session via logind) creates a 16 KiB VRAM BO (64x64x32 dumb buffer),
registers a 1920x1080 XRGB8888 fb on it (8,294,400 B required), and
modesets/flips: the panel then displays the contents of VRAM immediately
following the BO — other applications' buffers.  The disclosure is to the
physical display, so the ceiling is visual; no kernel memory involved, no
write primitive.  Rating: Medium (info leak, default desktop configs,
needs amdgpu KMS) — identical to DF-4181 (radeon).

Upstream context: this DRM vintage predates `drm_gem_fb_create()` with its
per-plane BO-size checks; upstream later moved amdgpu fb creation onto
that helper, closing the gap there.

## Why it cannot be reproduced on this guest

The QEMU guest has no ATI/AMD GPU: no PCI vendor-0x1002 device
(pciconf), no `/dev/dri` at all, and no drm modules loaded (env.txt).
`amdgpu_fb_oob` builds and runs; `open("/dev/dri/card0")` fails ENOENT
(run.log, exit 2).  The gate is hardware absence — without a PCI AMD GPU
the amdgpu drm device node cannot exist — so the finding is
source-certain but runtime-untestable here (same classification as
DF-4181 for radeon).

## Fix validation

`fix.diff` adds the per-plane
`offsets[i] + pitches[i] * DIV_ROUND_UP(height, vsub) <= amdgpu_bo_size()`
check in `amdgpu_display_framebuffer_init()` (amdgpu_display.c:506), i.e.
exactly the DF-4181 radeon fix transplanted to the amdgpu helper — covering
the user path for both the legacy (amdgpu_mode_funcs) and DC
(amdgpu_dm.c:945) fb_create registrations.  Applied cleanly to the guest
/usr/src (md5 21c72601… → f68f1ac9…), **amdgpu.ko built standalone with
`-Werror -DKLD_MODULE`** (`make -j6` in sys/dev/drm/amd/amdgpu: rc=0,
28.7 s, zero error/warning lines, `--- amdgpu.ko ---` linked with the
patched amdgpu_display.o — fix_build.log:90).  Source reverted to pristine
after the build.  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.