CVE-2026-31603: staging: sm750fb: fix division by zero in ps_to_hz()
In the Linux kernel, the following vulnerability has been resolved:
staging: sm750fb: fix division by zero in pstohz()
pstohz() is called from hwsm750crtcsetmode() without validating that pixclock is non-zero. A zero pixclock passed via FBIOPUTVSCREENINFO causes a division by zero.
Fix by rejecting zero pixclock in lynxfbopscheckvar(), consistent with other framebuffer drivers.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.137.1-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Compensating control
Reject zero pixclock values in lynxfb_ops_check_var() before processing FBIOPUT_VSCREENINFO, and validate that pixclock is non-zero before calling ps_to_hz() from hw_sm750_crtc_set_mode().
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems running the Linux kernel with the sm750fb staging framebuffer driver are exposed. The affected software list also includes Microsoft azl3 kernel 6.6.134.1-2 and debian/linux.
What does an attacker need to trigger the failure?
An attacker needs local access and low privileges to submit an FBIOPUT_VSCREENINFO request with pixclock set to zero. No user interaction is required.
What is the impact of successful exploitation?
A zero pixclock reaches ps_to_hz() and causes a division by zero, resulting in a denial of service.
What validation addresses the issue?
The fix rejects framebuffer mode settings with a zero pixclock in lynxfb_ops_check_var(), preventing the value from reaching the vulnerable division.