CVE-2024-46694

What it actually does

Null pointer dereference in drm/amd/display when state->fb->obj[0] is accessed directly without validation, instead of using drm_gem_fb_get_obj() which safely returns an error on null framebuffer object.

Why it matters to the business

Kernel-level display driver crashes or memory corruption on affected Linux systems can cause system instability, denial of service, or potential privilege escalation in graphics workloads, with moderate urgency due to kernel exposure in many distributions despite low exploitation probability.

How an attack unfolds

An attacker with local access crafts or triggers a display state update involving a framebuffer lacking a valid GEM object, causing the driver to dereference a null pointer during AMD display handling; listed threat actors in zero-day and Linux kernel campaigns could chain this with other primitives for escalation.

How to fix it

Update the Linux kernel to a version containing commit 093ee72ed35c2338c87c26b6ba6f0b7789c9e14e or later; for goreleaser/nfpm/v2 update to 2.29.0 or newer if applicable in build pipelines.

How to confirm the fix worked

Confirm kernel source contains the drm_gem_fb_get_obj() call with null check in amd/display code; test by attempting framebuffer operations that previously triggered null access and verify no oops occurs.

Typical attack path

1. Obtain local code execution or user context on a Linux system with AMD display hardware
2. Trigger display mode or framebuffer operations that produce a state with null obj[0]
3. Invoke drm/amd/display code path that directly accesses the null object without prior check
4. Cause kernel panic, oops, or memory corruption leading to crash or further exploitation

How to detect it

Search kernel logs and dmesg for AMD display driver null pointer dereference messages or oops involving drm_gem_fb_get_obj paths; review audit logs for unusual local display or graphics API calls around crash times.

What your security team should do

• Prioritize kernel updates on systems with AMD GPUs within standard patch windows given moderate CVSS and stable EPSS
• Monitor kernel logs for display-related null pointer oops as part of routine stability checks
• Review downstream package dependencies for affected kernel versions in container or embedded builds