Re:[PATCH v2] drm/vblank: Reject 0-period timers to prevent hrtimer storm

[w15303746062 <w15303746062@163.com>]

Hi Maarten, Maxime, Thomas, and all,

A gentle ping on this v2 patch.

It has been about two weeks since submission. As a quick reminder, this v2 
addresses the previous feedback by moving the zero-period validation 
directly into the DRM core (`drm_vblank.c`). This protects all virtual 
drivers relying on the software vblank timer from the hrtimer storm DoS. 
It also drops the WARN_ON_ONCE() to prevent unprivileged userspace from 
triggering panics.

Could anyone please take a look when you have a moment, or let me know 
if any further adjustments are needed?

Best regards,
Mingyu

At 2026-05-23 10:54:47, w15303746062@163.com wrote:
>From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>
>Fuzzers like Syzkaller can submit extremely malicious display modes
>through DRM_IOCTL_MODE_SETCRTC. If userspace passes a mode with a
>massive pixel clock (crtc_clock) and small resolution (htotal/vtotal),
>the integer division in drm_calc_timestamping_constants() truncates
>the resulting frame duration (vblank->framedur_ns) to 0.
>
>When virtual display drivers (such as vmwgfx or vkms) rely on the DRM
>core's software vblank simulation, drm_crtc_vblank_start_timer() is
>called. It blindly converts this 0-ns framedur_ns into a ktime interval
>and starts the hrtimer. An hrtimer with a 0-period fires instantly and
>continuously. Since hrtimer_forward_now() cannot advance time for a
>0-period, the CPU gets locked in an infinite hard-IRQ loop, starving
>the system and causing massive RCU stalls.
>
>Fix this DoS vulnerability by adding a defensive sanity check in
>drm_crtc_vblank_start_timer() to reject a 0-ns frame duration, allowing
>the DRM core to gracefully reject the malicious mode.
>
>Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
>---
>Changes in v2:
>- Moved the defensive check from vmwgfx to drm_vblank.c. The timer
>  logic was refactored into the DRM core, so placing the check here
>  protects all drivers relying on the core software vblank timer.
>- Dropped WARN_ON_ONCE() to prevent unprivileged userspace from easily
>  triggering kernel panics on systems with panic_on_warn enabled.
>
> drivers/gpu/drm/drm_vblank.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
>diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
>index f90fb2d13e42..b38d0b30a651 100644
>--- a/drivers/gpu/drm/drm_vblank.c
>+++ b/drivers/gpu/drm/drm_vblank.c
>@@ -2241,6 +2241,16 @@ int drm_crtc_vblank_start_timer(struct drm_crtc *crtc)
> 
> 	drm_calc_timestamping_constants(crtc, &crtc->mode);
> 
>+	/*
>+	 * DEFENSIVE CHECK:
>+	 * drm_calc_timestamping_constants() truncates framedur_ns to 0 if
>+	 * userspace provides a malicious mode with a huge crtc_clock and
>+	 * small htotal/vtotal. Prevent an infinite hard-IRQ loop from a
>+	 * 0-period hrtimer by rejecting such modes.
>+	 */
>+	if (unlikely(vblank->framedur_ns == 0))
>+		return -EINVAL;
>+
> 	spin_lock_irqsave(&vtimer->interval_lock, flags);
> 	vtimer->interval = ns_to_ktime(vblank->framedur_ns);
> 	spin_unlock_irqrestore(&vtimer->interval_lock, flags);
>-- 
>2.34.1