CVE-2026-98404

What it actually does

The function virtio_gpu_user_framebuffer_create returns NULL on error instead of an ERR_PTR, allowing a subsequent NULL pointer dereference in drm_mode_addfb2 when handling virtio GPU framebuffer creation.

Why it matters to the business

Virtualized Linux systems using virtio GPU may experience kernel crashes or instability in graphics initialization paths, potentially disrupting workloads with low but non-zero remote exploitation risk given the recent disclosure.

How an attack unfolds

An attacker with local or guest access crafts inputs that reach the framebuffer creation error path in the virtio DRM driver, causing the NULL return to propagate and trigger a dereference crash in the mode-setting code.

How to fix it

Apply the upstream kernel commit that replaces the NULL return with an ERR_PTR in virtio_gpu_user_framebuffer_create and rebuild or upgrade to a kernel containing the resolution.

How to confirm the fix worked

Review the virtio_gpu_user_framebuffer_create function in the DRM source to confirm ERR_PTR usage on error paths and test framebuffer creation error scenarios to ensure no NULL dereference occurs.

Typical attack path

1. Identify a system exposing virtio GPU DRM interfaces
2. Trigger error conditions during user framebuffer creation via DRM ioctls
3. Force the NULL return path to induce dereference in drm_mode_addfb2

How to detect it

Search kernel logs for oops or panic messages referencing drm_mode_addfb2 or virtio_gpu_user_framebuffer_create around the time of recent updates or unusual DRM ioctl activity.

What your security team should do

• Prioritize kernel updates for systems using virtio GPU within the next patching cycle
• Monitor for related static analysis findings in other DRM drivers
• Limit untrusted guest access to GPU acceleration features where feasible