CVE-2026-31603: Linux Kernel DOS Vulnerability

CVE-2026-31603 Overview

CVE-2026-31603 is a division-by-zero vulnerability in the Linux kernel's sm750fb staging framebuffer driver. The flaw resides in the ps_to_hz() helper, which is invoked from hw_sm750_crtc_set_mode() without validating that the pixclock value is non-zero. A local user with access to the framebuffer device can supply a zero pixclock through the FBIOPUT_VSCREENINFO ioctl, triggering a kernel-side division by zero and a denial of service. The issue is tracked as [CWE-369] Divide By Zero and affects multiple stable branches of the Linux kernel.

Critical Impact
A local, low-privileged user with access to the sm750fb framebuffer device can crash the kernel through a crafted FBIOPUT_VSCREENINFO ioctl, resulting in a high-availability impact denial of service.

Affected Products

Linux kernel staging driver sm750fb across multiple stable branches
Distributions shipping the upstream sm750fb staging framebuffer driver
Systems exposing /dev/fb* devices backed by sm750fb to local users

Discovery Timeline

2026-04-24 - CVE-2026-31603 published to NVD
2026-04-29 - Last updated in NVD database

Technical Details for CVE-2026-31603

Vulnerability Analysis

The sm750fb staging framebuffer driver implements a ps_to_hz() conversion routine that translates a pixel clock period in picoseconds into a frequency in hertz. The conversion performs a division using the caller-supplied pixclock value as the divisor. The driver calls ps_to_hz() from hw_sm750_crtc_set_mode() during mode setting, which is reached when userspace updates the variable screen information through the FBIOPUT_VSCREENINFO ioctl.

The driver does not reject a pixclock of zero in its lynxfb_ops_check_var() validation callback. When a local process submits a fb_var_screeninfo structure with pixclock = 0, the value propagates into ps_to_hz() and produces a divide-by-zero fault in kernel context. The result is a kernel oops and loss of availability for the running system.

The upstream fix rejects a zero pixclock inside lynxfb_ops_check_var(), aligning the driver with the input validation behavior found in other framebuffer drivers.

Root Cause

The root cause is missing input validation [CWE-369] in lynxfb_ops_check_var(). The driver trusts the userspace-supplied pixclock value and forwards it to an arithmetic routine that uses it as a divisor without a non-zero check.

Attack Vector

Exploitation requires local access and the ability to open the affected framebuffer device node, then issue FBIOPUT_VSCREENINFO with pixclock = 0. No user interaction is required, and the attack does not yield code execution or information disclosure. The impact is limited to denial of service through a kernel fault.

Verified patch commits are published in the kernel stable tree, including Kernel Git Commit 1412ba3 and Kernel Git Commit daf6733.

Detection Methods for CVE-2026-31603

Indicators of Compromise

Kernel oops or panic messages referencing ps_to_hz, hw_sm750_crtc_set_mode, or lynxfb_ops_check_var in dmesg or /var/log/kern.log.
Divide-error exceptions logged with a call trace that includes the sm750fb module.
Unexpected framebuffer device resets or display subsystem failures correlated with local process activity.

Detection Strategies

Monitor kernel logs for divide-by-zero traps originating from staging framebuffer drivers, especially sm750fb.
Audit local processes that open /dev/fb* device nodes and issue FBIOPUT_VSCREENINFO ioctls, particularly from non-graphical user sessions.
Track loaded kernel modules and confirm whether sm750fb is present on systems that do not require the Silicon Motion SM750 hardware.

Monitoring Recommendations

Collect and centralize kernel ring buffer output for analysis in your SIEM or log platform.
Alert on repeated kernel faults from the same user or process to surface attempts at local denial of service.
Inventory systems with the sm750fb driver loaded and prioritize them for patch deployment tracking.

How to Mitigate CVE-2026-31603

Immediate Actions Required

Apply the upstream kernel patches referenced in the stable tree commits to all systems running the sm750fb driver.
Restrict access to /dev/fb* device nodes so that only trusted users or the display server can issue framebuffer ioctls.
If the SM750 hardware is not in use, unload and blacklist the sm750fb module to remove the attack surface entirely.

Patch Information

The fix rejects a zero pixclock value in lynxfb_ops_check_var(), preventing the invalid value from reaching ps_to_hz(). Backports are available in the following stable commits: Kernel Git Commit 1412ba3, Kernel Git Commit 2f640c6, Kernel Git Commit 6144895, Kernel Git Commit 75a1621, Kernel Git Commit 779412e, and Kernel Git Commit daf6733. Install the kernel update from your distribution vendor that incorporates these commits.

Workarounds

Blacklist the sm750fb kernel module on systems that do not require the driver to eliminate the vulnerable code path.
Tighten permissions on /dev/fb* devices and remove unnecessary users from the video group to limit who can call FBIOPUT_VSCREENINFO.
Disable or remove framebuffer console access on servers that operate headlessly and have no need for direct framebuffer I/O.

bash

# Blacklist the sm750fb staging driver and rebuild initramfs
echo 'blacklist sm750fb' | sudo tee /etc/modprobe.d/blacklist-sm750fb.conf
sudo update-initramfs -u

# Verify the module is no longer loaded after reboot
lsmod | grep sm750fb || echo 'sm750fb not loaded'

# Restrict framebuffer device access to root only
sudo chmod 600 /dev/fb*