From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/vkms: sanitize display mode to prevent hrtimer livelock Date: Wed, 27 May 2026 13:52:39 +1000 Message-ID: In-Reply-To: <20260527034733.701705-1-w15303746062@163.com> References: <20260527034733.701705-1-w15303746062@163.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 dis= play mode with an extremely high refresh rate can cause the vkms hrtimer to= fire so rapidly it livelocks the CPU. The fix approach =E2=80=94 rejecting= pathological modes in `atomic_check` =E2=80=94 is reasonable and addresses= the right layer (the driver that accepts arbitrary modes). However, the pa= tch 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_consta= nts()`), but the patch's manual frame duration check uses `htotal`/`vtotal`= (not the `crtc_` variants). While these are often the same after mode adju= stment, they can differ =E2=80=94 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_mod= e_vrefresh()` uses `mode->clock` / `mode->htotal` / `mode->vtotal`, while t= he timer uses `mode->crtc_clock` / `mode->crtc_htotal` / `mode->crtc_vtotal= `. A mode could pass the `drm_mode_vrefresh()` check but still produce a ne= ar-zero `framedur_ns`. 3. **Ordering issue with `vrefresh` check and zero-field check.** If `htota= l` or `vtotal` is zero, `drm_mode_vrefresh()` returns 0, which passes the `= > 1000` check. The subsequent zero-field check catches `htotal =3D=3D 0` or= `vtotal =3D=3D 0`, but calling `drm_mode_vrefresh()` first with potentiall= y degenerate fields is unnecessary =E2=80=94 the zero check should come fir= st. 4. **Interlace modes are not accounted for.** `drm_calc_timestamping_consta= nts()` halves `framedur_ns` for interlaced modes (`DRM_MODE_FLAG_INTERLACE`= ), but the patch's manual frame duration calculation does not. An interlace= d mode at 600 Hz effective would produce `framedur_ns` below 1 ms after hal= ving, but the patch would compute ~1.67 ms and let it through. --- Generated by Claude Code Patch Reviewer