CVE-2024-46866

What it actually does

Missing lock acquisition around bo state inspection in show_meminfo() allows concurrent modification of tt and ttm resource pointers, resulting in null pointer dereference or use-after-free.

Why it matters to the business

Local users on affected Linux systems can trigger kernel crashes or memory corruption, leading to denial of service and potential privilege escalation on graphics-enabled workloads.

How an attack unfolds

An attacker with local access triggers concurrent operations on a DRM object while show_meminfo() inspects unlocked state, racing the tt/ttm resource to cause a crash or controlled memory corruption.

How to fix it

Upgrade to a kernel containing commit abc8feacacf8fae10eecf6fea7865e8c1fee419c or later; rebuild and reboot with the patched drm/xe code.

How to confirm the fix worked

Confirm the presence of xe_bo_assert_held() calls and lock acquisition before bo_meminfo() in the source; verify the fixed commit is included in the running kernel via git log or package version.

Typical attack path

1. Obtain local shell access on a system running the vulnerable kernel
2. Create or reference a DRM buffer object via userspace graphics APIs
3. Trigger show_meminfo() while concurrently mutating the object state
4. Exploit resulting UAF or NPD for kernel memory corruption or DoS

How to detect it

Review kernel logs for oops/panics mentioning drm/xe, bo_meminfo, or null pointer dereferences in client memory inspection paths; correlate with process activity creating DRM objects.

What your security team should do

• Apply the referenced upstream commit or distribution kernel update immediately on all systems exposing the xe driver
• Restrict unprivileged local access where feasible until patches are deployed
• Monitor for kernel oops or panic logs referencing bo_meminfo or drm/xe