On Sat, Jul 11, 2026 at 4:20 PM <[email protected]> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s)
> to consider:
>
> Pre-existing issues:
> - [Medium] Unchecked `vrefresh` parameter from kernel command line can cause
> multiple divide-by-zero panics.
> --
>
> --- Patch [1]: [PATCH] drm/modes: reject out-of-range GTF blanking duty cycle
> ---
> commit c78fc29b3d453bf33d5cd88746572b5f1e9a5c60
> Author: Xiang Mei <[email protected]>
>
> drm/modes: reject out-of-range GTF blanking duty cycle
>
> This commit rejects GTF blanking duty cycles of 100% or more to prevent a
> divide-by-zero error that occurs when the divisor (100000 - ideal_duty_cycle)
> evaluates to 0.
>
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index e1eed13a8e94f..291037706b587 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -966,6 +966,10 @@ drm_gtf_mode_complex(struct drm_device *dev, int
> > hdisplay, int vdisplay,
> > /* 18.Find the ideal blanking duty cycle from blanking duty cycle */
> > ideal_duty_cycle = GTF_C_PRIME * 1000 -
> > (GTF_M_PRIME * 1000000 / hfreq_est);
>
> [Severity: Medium]
> This is a pre-existing issue, but while fixing divide-by-zero crashes here,
> could an unvalidated vrefresh parameter cause other divide-by-zero panics
> in this function?
>
> For example, if an administrator provides a kernel command line parameter
> with a refresh rate of @0 (e.g., video=1024x768@0), vfieldrate_rqd
> evaluates to 0. This would cause a panic earlier in drm_gtf_mode_complex():
>
> hperiod = 1000000 / (vfieldrate_rqd * vtotal_lines);
>
> Also, if the refresh rate is @1818, tmp1 evaluates to 0:
>
> tmp1 = (1000000 - MIN_VSYNC_PLUS_BP * vfieldrate_rqd) / 500;
> // (1000000 - 550 * 1818) / 500 = 0
>
> This leads to another direct division by zero:
>
> hfreq_est = (tmp2 * 1000 * vfieldrate_rqd) / tmp1;
>
> And if hfreq_est evaluates to 0, it causes a third divide-by-zero on the
> ideal_duty_cycle assignment above.
>
> Should drm_gtf_mode_complex() validate the vrefresh parameter before
> performing these calculations?
>
Good catch that those divisions can trap too, but they're on a different
reachability tier than the bug this patch fixes, so I'd keep them out of
this change.
The @0 and @1818 cases you describe are only reachable via
drm_mode_create_from_cmdline_mode() (drm_modes.c:2557), i.e. a
`video=...@0` kernel command-line argument. That's root/admin-at-boot,
not a crafted-input boundary.
Xiang
> > + if (ideal_duty_cycle >= 100000) {
> > + drm_mode_destroy(dev, drm_mode);
> > + return NULL;
> > + }
> > /* 19.Find the number of pixels in the blanking time to the nearest
> > * double character cell: */
> > hblank = total_active_pixels * ideal_duty_cycle /
>
> --
> Sashiko AI review ·
> https://sashiko.dev/#/patchset/[email protected]?part=1
