CVE-2024-40924

What it actually does

Use-after-free in the i915 DPT object: shrinking the DPT while the framebuffer remains on the vm->bound_list leaves a stale CPU mapping; subsequent PTE rewrite then dereferences the freed object and triggers kernel panic.

Why it matters to the business

Unprivileged local users can trigger a kernel panic on affected Linux systems that use Intel i915 graphics, causing immediate denial of service and loss of availability until the system is rebooted.

How an attack unfolds

An attacker with local access triggers memory-pressure conditions that cause the DPT object to be shrunk by the shrinker while the framebuffer is still bound; the next operation that walks the bound_list attempts to rewrite PTEs through the now-stale mapping, resulting in a use-after-free panic.

How to fix it

Update the Linux kernel to a version containing commit 327280149066f0e5f2e50356b5823f76dabfe86e or later; rebuild and reboot with the patched kernel. Where immediate patching is not possible, restrict unprivileged local access or disable i915 DPT usage if supported by the driver configuration.

How to confirm the fix worked

Verify the running kernel contains commit 327280149066f0e5f2e50356b5823f76dabfe86e (or equivalent backport); confirm the DPT shrinker path no longer allows the object to be reclaimed while entries remain on the bound list by reviewing dmesg after memory-pressure tests.

Typical attack path

1. Obtain local unprivileged shell on target Linux system with i915 GPU
2. Induce memory pressure or trigger DPT allocation paths that invoke the shrinker
3. Force the DPT object to be reclaimed while its framebuffer entry remains on vm->bound_list
4. Trigger subsequent PTE update that dereferences the freed mapping
5. Kernel panics

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for panic messages containing drm/i915, DPT, bound_list, or stale CPU mapping references around the time of unexpected reboots; correlate with user activity that could induce memory pressure.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all systems exposing i915 graphics to untrusted local users
• Monitor for kernel panics referencing drm/i915/dpt and vm->bound_list
• Apply defense-in-depth by limiting local user access on multi-user or shared systems until patched