CVE-2024-39497

What it actually does

Missing check for copy-on-write mappings in drm_gem_shmem_mmap permits mmap(PROT_WRITE, MAP_PRIVATE) on DRM GEM shmem objects, triggering BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)) inside vmf_insert_pfn_prot and causing an immediate kernel panic. The flaw exists in the default shmem helpers used by all DRM drivers.

Why it matters to the business

Unprivileged users with access to a DRM device can crash the entire system on demand, resulting in denial of service, loss of graphics workloads, and potential data corruption for any application relying on the kernel's DRM subsystem.

How an attack unfolds

An attacker opens a DRM device file descriptor, calculates a valid mmap offset for a GEM object, then invokes mmap with PROT_WRITE and MAP_PRIVATE flags. The shmem helper proceeds without rejecting the COW request, vmf_insert_pfn_prot is called, the BUG_ON fires, and the kernel panics. No special privileges beyond device access are required.

How to fix it

Upgrade the Linux kernel to a version containing commit a508a102edf8735adc9bb73d37dd13c38d1a1b10 or later stable release that includes the early -EINVAL return for COW mappings in drm_gem_shmem_mmap. Reboot after installing the updated kernel package.

How to confirm the fix worked

Confirm the running kernel contains commit a508a102edf8735adc9bb73d37dd13c38d1a1b10 or the equivalent backport. Reproduce the original mmap call and verify it now returns -EINVAL instead of triggering a BUG_ON panic. Review dmesg for absence of the vmf_insert_pfn_prot BUG_ON string after the update.

Typical attack path

1. Obtain a file descriptor to a DRM device (e.g., /dev/dri/card0 or render node)
2. Locate a valid GEM object mmap offset via DRM ioctl
3. Call mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset)
4. Write to the returned pointer to trigger page fault handling
5. Kernel executes BUG_ON and panics

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for the exact BUG_ON string containing vmf_insert_pfn_prot and is_cow_mapping, or for drm_gem_shmem_mmap in stack traces around the time of unexpected panics. Correlate with process activity that opens DRM device nodes and performs mmap with MAP_PRIVATE.

• BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags))
• drm_gem_shmem_mmap
• vmf_insert_pfn_prot

What your security team should do

• Apply the kernel update containing the referenced commit as soon as packages are available
• Restrict unprivileged access to DRM devices via device permissions or SELinux/AppArmor policies where feasible
• Monitor for kernel oops/panic reports referencing drm_gem_shmem_mmap or vmf_insert_pfn_prot
• Include the updated kernel in the next maintenance window for all systems exposing DRM interfaces