CVE-2026-23266: Linux Kernel rivafb DOS Vulnerability

CVE-2026-23266 Overview

A divide-by-zero vulnerability exists in the Linux kernel's RIVA NV3 framebuffer driver (rivafb) within the nv3_arb() function. A userspace program can trigger this vulnerability by calling the FBIOPUT_VSCREENINFO ioctl on /dev/fb* devices, causing the driver to recompute FIFO arbitration parameters using an unvalidated divisor. When state->mclk_khz (derived from the PRAMDAC MCLK PLL) is zero due to a malicious or misconfigured PCI device, the subsequent division operation causes a kernel crash.

Critical Impact
An attacker with local access can crash the Linux kernel by triggering a divide-by-zero error in the RIVA framebuffer driver, causing a complete system denial of service.

Affected Products

Linux kernel with rivafb driver enabled
Systems using NVIDIA RIVA NV3 graphics hardware
Virtualized environments with emulated PCI devices exposing bogus PLL configurations

Discovery Timeline

2026-03-18 - CVE CVE-2026-23266 published to NVD
2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-23266

Vulnerability Analysis

The vulnerability resides in the nv3_arb() function located at drivers/video/fbdev/riva/riva_hw.c. When a userspace application invokes the FBIOPUT_VSCREENINFO ioctl on a framebuffer device, the driver recalculates FIFO arbitration settings. During this process, the gns calculation divides by state->mclk_khz, which is derived from the memory clock PLL configuration read from the graphics hardware.

In legitimate hardware configurations, this value is always non-zero. However, an attacker can construct a malicious or emulated PCI device that returns a bogus PLL configuration, setting state->mclk_khz to zero. When nv3_get_param() subsequently calls nv3_arb(), the division by zero triggers a CPU exception, immediately crashing the kernel.

The crash trace shows the execution path: fb_ioctl → do_fb_ioctl → fb_set_var → rivafb_set_par → riva_load_video_mode → CalcStateExt → nv3UpdateArbitrationSettings → nv3CalcArbitration → nv3_get_param → nv3_arb.

Root Cause

The root cause is missing input validation on the state->mclk_khz variable before it is used as a divisor in arithmetic operations. The driver implicitly trusts hardware-provided values without verifying they are within safe bounds. This represents a violation of the security principle that kernel code should never trust data from potentially untrusted sources, including emulated or malicious hardware.

Attack Vector

The attack requires local access to the system with permissions to interact with framebuffer devices (typically /dev/fb*). An attacker must either:

Have access to a system with a crafted or emulated PCI graphics device presenting a malicious PLL configuration
Use a compromised hypervisor or emulation environment (such as QEMU) to expose a fake RIVA graphics device with zero MCLK values

Once these conditions are met, the attacker simply needs to call the FBIOPUT_VSCREENINFO ioctl on the framebuffer device to trigger the kernel crash.

The vulnerability follows the execution path through the ioctl handler to the nv3_arb() function where the unvalidated division occurs at line 439 in riva_hw.c, causing a divide error exception (trap 0000) and immediate kernel panic.

Detection Methods for CVE-2026-23266

Indicators of Compromise

Kernel panic messages containing "divide error" with RIP pointing to nv3_arb or nv3_get_param functions
System logs showing unexpected crashes during framebuffer ioctl operations
Stack traces referencing drivers/video/fbdev/riva/riva_hw.c in crash dumps

Detection Strategies

Monitor system logs for divide error kernel panics originating from the rivafb driver subsystem
Implement kernel module auditing to detect loading of the rivafb driver on systems without legitimate RIVA hardware
Use hardware inventory tools to identify unexpected or emulated PCI graphics devices

Monitoring Recommendations

Configure kernel crash dump collection (kdump) to capture divide-by-zero exceptions for forensic analysis
Set up alerts for kernel OOPS messages containing references to riva_hw.c or fbdev subsystem crashes
Monitor for suspicious patterns of framebuffer device access from untrusted processes

How to Mitigate CVE-2026-23266

Immediate Actions Required

Apply the kernel patches from the stable branch to all affected systems immediately
If patching is not immediately possible, blacklist or unload the rivafb kernel module on systems without RIVA hardware
Restrict access to /dev/fb* devices to only trusted users and processes

Patch Information

The Linux kernel maintainers have released patches across multiple stable branches. The fix adds validation to check whether state->mclk_khz is zero before performing the division, bailing out early to prevent the crash.

The following commits address this vulnerability:

Workarounds

Blacklist the rivafb module by adding blacklist rivafb to /etc/modprobe.d/blacklist.conf
Remove the rivafb module from running systems using rmmod rivafb if not required for display
Restrict framebuffer device permissions using udev rules to limit access to trusted users only

bash

# Configuration example
# Blacklist rivafb module to prevent loading
echo "blacklist rivafb" >> /etc/modprobe.d/blacklist-rivafb.conf

# Remove the module if currently loaded
rmmod rivafb 2>/dev/null || true

# Restrict framebuffer device permissions via udev
echo 'KERNEL=="fb[0-9]*", MODE="0600", GROUP="video"' > /etc/udev/rules.d/99-framebuffer-restrict.rules
udevadm control --reload-rules