Claude review: drm/vkms: sanitize display mode to prevent hrtimer livelock

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: drm/vkms: sanitize display mode to prevent hrtimer livelock
Author: w15303746062@163.com
Patches: 1
Reviewed: 2026-05-27T13:52:39.566549

---

This is a single patch addressing a real syzbot-reported bug: a crafted display mode with an extremely high refresh rate can cause the vkms hrtimer to fire so rapidly it livelocks the CPU. The fix approach — rejecting pathological modes in `atomic_check` — is reasonable and addresses the right layer (the driver that accepts arbitrary modes). However, the patch has several correctness issues that would prevent it from fully closing the vulnerability.

**Key concerns:**

1. **Wrong mode fields validated.** The vblank timer period is derived from `crtc_clock`/`crtc_htotal`/`crtc_vtotal` (in `drm_calc_timestamping_constants()`), but the patch's manual frame duration check uses `htotal`/`vtotal` (not the `crtc_` variants). While these are often the same after mode adjustment, they can differ — and the `adjusted_mode` should have the `crtc_` prefixed fields validated to match what the timer actually uses.

2. **`drm_mode_vrefresh()` uses different fields than the timer.** `drm_mode_vrefresh()` uses `mode->clock` / `mode->htotal` / `mode->vtotal`, while the timer uses `mode->crtc_clock` / `mode->crtc_htotal` / `mode->crtc_vtotal`. A mode could pass the `drm_mode_vrefresh()` check but still produce a near-zero `framedur_ns`.

3. **Ordering issue with `vrefresh` check and zero-field check.** If `htotal` or `vtotal` is zero, `drm_mode_vrefresh()` returns 0, which passes the `> 1000` check. The subsequent zero-field check catches `htotal == 0` or `vtotal == 0`, but calling `drm_mode_vrefresh()` first with potentially degenerate fields is unnecessary — the zero check should come first.

4. **Interlace modes are not accounted for.** `drm_calc_timestamping_constants()` halves `framedur_ns` for interlaced modes (`DRM_MODE_FLAG_INTERLACE`), but the patch's manual frame duration calculation does not. An interlaced mode at 600 Hz effective would produce `framedur_ns` below 1 ms after halving, but the patch would compute ~1.67 ms and let it through.

---
Generated by Claude Code Patch Reviewer