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.