CVE-2024-26777

What it actually does

Unvalidated pixclock value from userspace ioctl reaches sisfb_check_var as a divisor before a zero check, triggering a kernel divide-by-zero fault.

Why it matters to the business

Local denial-of-service that can crash or reboot affected Linux systems using the sis framebuffer driver, interrupting workloads and requiring manual recovery.

How an attack unfolds

An attacker with local access crafts an ioctl call to the sis framebuffer device, supplying a pixclock of zero; the driver performs division before validation, causing an immediate kernel panic.

How to fix it

Upgrade to a kernel containing commit 84246c35ca34207114055a87552a1c4289c8fd7e or later; apply the vendor-provided stable update that adds an early zero check for pixclock in sisfb_check_var.

How to confirm the fix worked

Confirm the running kernel includes commit 84246c35ca34207114055a87552a1c4289c8fd7e; test by attempting the zero-pixclock ioctl and verifying the driver now returns an error instead of crashing.

Typical attack path

1. Obtain local shell or process execution on target system
2. Open /dev/fb* or equivalent sis framebuffer device
3. Invoke FBIOPUT_VSCREENINFO ioctl with var.pixclock set to zero
4. Trigger divide-by-zero fault resulting in kernel panic or oops

How to detect it

Review kernel logs for divide-by-zero faults referencing sisfb_check_var or sis framebuffer code; look for unusual ioctl activity on /dev/fb devices from untrusted processes.

What your security team should do

• Prioritize patching production kernels that expose the sis framebuffer driver
• Restrict unprivileged access to framebuffer devices via device permissions or SELinux/AppArmor policies until patched
• Monitor kernel logs for divide-by-zero oops in sisfb_check_var after applying updates