CVE-2024-26778

What it actually does

Unchecked userspace ioctl input allows pixclock value of zero to reach savagefb_check_var as a divisor, triggering a kernel divide-by-zero fault in the savage framebuffer driver.

Why it matters to the business

Systems using the savage fbdev driver may experience kernel crashes or denial of service from local unprivileged processes, increasing operational downtime on affected Linux deployments though exploitability remains low.

How an attack unfolds

An attacker with local access invokes the framebuffer ioctl interface to supply a zero pixclock value; the driver fails to validate it in savagefb_probe path before using it as a divisor in savagefb_check_var, causing an immediate kernel oops.

How to fix it

Upgrade the Linux kernel to a version containing commit 224453de8505aede1890f007be973925a3edf6a1 or later; rebuild and reboot with the patched kernel image.

How to confirm the fix worked

Inspect kernel source for the pixclock zero check inside savagefb_check_var and confirm the running kernel was built after commit 224453de8505aede1890f007be973925a3edf6a1.

Typical attack path

1. Obtain local unprivileged shell on target Linux system
2. Open /dev/fb0 or equivalent framebuffer device
3. Craft and issue FBIOGET_VSCREENINFO or related ioctl with pixclock set to zero
4. Trigger savagefb_check_var execution path leading to divide-by-zero

How to detect it

Review kernel logs for divide-by-zero oops messages referencing savagefb_check_var or savagefb_probe; correlate with recent ioctl activity on framebuffer devices.

What your security team should do

• Prioritize kernel updates on systems exposing framebuffer devices to untrusted users
• Audit custom or embedded kernels for the missing pixclock validation
• Monitor EPSS and KEV status for any future changes despite current low scores