From: w15303746062@163.com
To: zack.rusin@broadcom.com, maarten.lankhorst@linux.intel.com,
mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
simona@ffwll.ch
Cc: bcm-kernel-feedback-list@broadcom.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org,
Mingyu Wang <25181214217@stu.xidian.edu.cn>
Subject: [PATCH] drm/vmwgfx: Fix hrtimer interrupt storm due to 0-period vblank
Date: Mon, 18 May 2026 15:17:41 +0800 [thread overview]
Message-ID: <20260518071741.441794-1-w15303746062@163.com> (raw)
From: Mingyu Wang <25181214217@stu.xidian.edu.cn>
When vmwgfx is configured to use VKMS for vblank simulation, it relies
on drm_calc_timestamping_constants() to calculate the frame duration
(vblank->framedur_ns).
However, Fuzzers (like Syzkaller) can submit extremely malicious
display modes through DRM_IOCTL_MODE_SETCRTC. If the user-space 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 result to 0.
Consequently, vmw_vkms_enable_vblank() blindly sets the hrtimer period
to 0. When the timer is started, it fires instantly and continuously.
Because hrtimer_forward_now() cannot advance time for a 0-period,
the overrun value skyrockets, locking the CPU in an infinite hard-IRQ
loop (vkms_vblank_simulate() -> HRTIMER_RESTART).
This completely starves the CPU, leading to massive RCU stalls and
blocking other essential tasks (like jbd2 and writeback workers)
indefinitely:
[ C1] vkms_vblank_simulate: vblank timer overrun
...
INFO: task kworker/u18:2:50 blocked for more than 143 seconds.
Workqueue: writeback wb_workfn (flush-8:0)
Call Trace:
<TASK>
__schedule+0x1044/0x5bb0
wbt_wait+0x1c8/0x3b0
blk_mq_submit_bio+0x29fa/0x31f0
submit_bio_noacct+0xca7/0x1f90
ext4_bio_write_folio+0x95a/0x1d10
...
NMI backtrace for cpu 1
Call Trace:
<IRQ>
vkms_vblank_simulate+0x8f/0x390
__hrtimer_run_queues+0x1f5/0xb30
hrtimer_interrupt+0x39a/0x880
Fix this DoS vulnerability by adding a defensive sanity check in
vmw_vkms_enable_vblank() to reject a 0-ns frame duration, allowing
DRM core to gracefully fallback/reject the mode without crashing.
Fixes: cd2eb57df1b8 ("drm/vmwgfx: Implement virtual kms")
Cc: stable@vger.kernel.org
Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
---
drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c
index 5abd7f5ad2db..b3950ae424f3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c
@@ -288,6 +288,16 @@ vmw_vkms_enable_vblank(struct drm_crtc *crtc)
drm_calc_timestamping_constants(crtc, &crtc->mode);
+ /*
+ * DEFENSIVE CHECK:
+ * drm_calc_timestamping_constants() can calculate a framedur_ns
+ * of 0 if user-space provides a malicious mode with a huge
+ * crtc_clock and small htotal/vtotal due to integer division
+ * truncation. Prevent hrtimer interrupt storms by refusing such modes.
+ */
+ if (WARN_ON_ONCE(vblank->framedur_ns == 0))
+ return -EINVAL;
+
hrtimer_setup(&du->vkms.timer, &vmw_vkms_vblank_simulate, CLOCK_MONOTONIC,
HRTIMER_MODE_REL);
du->vkms.period_ns = ktime_set(0, vblank->framedur_ns);
--
2.34.1
next reply other threads:[~2026-05-18 7:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 7:17 w15303746062 [this message]
2026-05-22 8:22 ` [PATCH] drm/vmwgfx: Fix hrtimer interrupt storm due to 0-period vblank Thomas Zimmermann
2026-05-23 2:54 ` [PATCH v2] drm/vblank: Reject 0-period timers to prevent hrtimer storm w15303746062
2026-05-25 8:01 ` Claude review: Re: [PATCH] drm/vmwgfx: Fix hrtimer interrupt storm due to 0-period vblank Claude Code Review Bot
2026-05-25 8:01 ` Claude review: " Claude Code Review Bot
2026-05-25 8:01 ` Claude Code Review Bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260518071741.441794-1-w15303746062@163.com \
--to=w15303746062@163.com \
--cc=25181214217@stu.xidian.edu.cn \
--cc=airlied@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=stable@vger.kernel.org \
--cc=tzimmermann@suse.de \
--cc=zack.rusin@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox