# DF-4224 — VERDICT

**Status: untested (kernel path) / arithmetic PROVEN on guest — see below.**
Impact ceiling: kernel panic (DoS). No memory-corruption primitive.

## Reproduced how far, and why no further

The QEMU guest has **no DRM device**: `pciconf -l` shows only
`vgapci0 chip=0x11111234` (Bochs std VGA) and `/dev/dri` does not exist. The
vulnerable code runs inside `drm_connector_get_cmdline_mode()`
(sys/dev/drm/drm_connector.c:131-132) which is only called when a DRM driver
registers connectors — never on this guest. Booting the guest with
`video=640x480M@2147483648` would therefore exercise nothing, so a
boot-param test on this VM is impossible (not merely inconvenient).

What *was* verified, on the guest itself (DF `cc 8.3 [DragonFly]`, x86-64,
identical integer ABI to the guest kernel):

1. **Intake semantics** — `strtol("2147483648")` → long 2147483648 →
   `(unsigned int)` 0x80000000 → `(int)` −2147483648 exactly mirrors
   drm_modes.c:1442/1465 + drm_connector.h:813 (`run.log` "parse simulation"
   line).
2. **Verbatim function arithmetic** — `harness.c` embeds the untouched
   arithmetic of `drm_cvt_mode()` (drm_modes.c:143-341) and
   `drm_gtf_mode_complex()` (drm_modes.c:365-529). With the attack values:
   - case 1 (`video=640x480M@2147483648`): SIGFPE exit=136 immediately after
     the `drm_modes.c:243` marker (both -O2, -O0).
   - case 2 (`video=640x480MR@2147483648`): SIGFPE exit=136 at `:302`
     (-O2).
   - case 3 (`video=640x479@2147483648`): SIGFPE exit=136 at `:459` (-O0;
     at -O2 GCC reschedules the two independent divisions and the trap
     surfaces at :481 — both divisors are 0, see `dbg.c` output).
   - case 4 (`video=640x601@134217728`, refresh in int range!):
     SIGFPE exit=136 at `:481` (hfreq_est wrapped to 0).
   - `dbg` prints the actual divisors: `den243=0`, `den459=0`,
     `hfreq_est=0`.
   A userspace SIGFPE is the same #DE exception the kernel takes at the same
   instruction; in-kernel it is an unhandled divide error → panic.
3. **Fix behaviour** — `fixdemo` shows layer (a) of fix.diff rejecting
   2147483648/4294967295/-5 and layer (b) rejecting 134217728, while 60/500
   pass.

## Chain (on real hardware)

`video=640x480M@2147483648` (kernel cmdline / `fb_mode_option`) →
fb_get_options → drm_connector.c:132 drm_mode_parse_command_line_for_connector
(drm_modes.c:1465 refresh=2^31 unvalidated) → connector probe →
drm_probe_helper.c:162 drm_mode_create_from_cmdline_mode → drm_modes.c:1600
drm_cvt_mode(vrefresh=INT_MIN) → drm_modes.c:243 `hperiod = tmp1*2 /
(tmp2*vfieldrate)` with `tmp2*vfieldrate == 0 mod 2^32` → #DE → **panic
during early boot**, before console takeover.

## Notes

- The `@134217728` variant (case 4) defeats any "just cap at INT_MAX" fix
  because the value is in range; that is why fix.diff adds the
  vfieldrate sanity bound in cvt/gtf themselves.
- `-<bpp>` intake (drm_modes.c:1474) has the same missing range check; huge
  bpp flows into fbdev allocation math (out of scope for this finding, noted
  in the audit result).
- Attempts: 2 (first harness iteration compiled the inputs as constants, and
  GCC legitimately deleted the always-UB divisions; inputs were moved to argv
  so the compiler cannot fold them, exactly as in the kernel where the value
  is parsed at runtime).

## 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.