CVE-2026-46312

What it actually does

This is a local Linux kernel denial-of-service class flaw in the videobuf2 scatter-gather DMA mmap path. The vulnerable code fails to set expected VMA flags, specifically VM_DONTEXPAND and VM_DONTDUMP, when mapping buffers through vb2_dma_sg_mmap. When an imported dma-buf is later mapped through DRM GEM paths, the kernel can hit a WARN_ON condition in drm_gem_mmap_obj. On systems configured to panic on kernel warnings, this can turn a user-triggerable media/graphics operation into a kernel panic and system outage. On systems not configured to panic on warnings, the impact is generally limited to kernel warning traces, taint state, possible application failure, and operational instability in affected camera/media pipelines.

Why it matters to the business

The practical risk is localized service disruption on Linux systems that expose affected media, camera, or graphics device paths to local users or applications. Workstations, embedded devices, kiosks, media appliances, and developer systems using V4L2, dma-buf, DRM, or out-of-tree camera drivers may experience crashes or instability if the vulnerable path is triggered. Because EPSS is very low, the issue is not known to be broadly exploited, is not in CISA KEV, and has no reported ransomware association, remediation should be prioritized based on exposure of local users, device access controls, and whether panic_on_warn is enabled.

How an attack unfolds

An attacker needs local code execution or the ability to run an application that can access relevant media and graphics devices, such as V4L2 camera capture and DRM/dma-buf interfaces. The attacker opens an affected video capture device, causes the driver to allocate or import scatter-gather backed videobuf2 buffers, exports or imports those buffers as dma-bufs, and then mmap()s the imported buffer through a DRM GEM mapping path. Because the videobuf2 scatter-gather mmap implementation did not set the same protective VMA flags used by the contiguous DMA implementation, the DRM GEM code observes an unexpected mapping state and triggers a WARN_ON in drm_gem_mmap_obj. If the host is configured with kernel.panic_on_warn=1 or equivalent hardening/debug behavior, the warning escalates into a kernel panic, producing a local denial of service. Without panic-on-warn, the attacker may still generate repeated kernel warnings, taint the kernel, disrupt the affected media application, and create log noise.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for vb2_dma_sg_mmap setting VM_DONTEXPAND and VM_DONTDUMP on the VMA. If consuming vendor kernels, apply the vendor-provided stable kernel update when available. If maintaining a custom kernel, backport the patch to the videobuf2 DMA scatter-gather mmap implementation so its VMA flag behavior matches vb2_dma_contig. As interim mitigation, restrict access to /dev/video*, /dev/media*, /dev/dri/*, and related device nodes to trusted users and service accounts only; remove untrusted users from video/render groups; disable or unload unnecessary camera/media drivers; and review whether panic_on_warn is required in production environments, because it can convert this warning into a full system crash.

How to confirm the fix worked

Confirm the running kernel package or source tree contains the patch that sets VM_DONTEXPAND and VM_DONTDUMP in vb2_dma_sg_mmap. On patched systems, exercise representative camera/media pipelines that import dma-bufs into DRM/GEM mappings and verify that no WARN_ON is emitted from drm_gem_mmap_obj. Check dmesg or journalctl -k after testing for the absence of the vulnerable stack trace. Validate device-node permissions so only intended users can access video, media, and DRM render devices. If panic_on_warn is enabled, confirm the business requirement for that setting and ensure affected systems are patched before allowing untrusted local media workloads.

Typical attack path

1. Obtain local execution on a Linux system or access to an application context allowed to use video/media and graphics device nodes.
2. Open an affected V4L2/media device that uses videobuf2 scatter-gather DMA memory operations.
3. Create, import, or pass dma-buf backed buffers between the media capture path and DRM/GEM mapping path.
4. Call mmap() on the imported dma-buf/GEM object in a way that reaches drm_gem_mmap_obj.
5. Trigger the kernel WARN_ON caused by missing VM_DONTEXPAND/VM_DONTDUMP VMA flags.
6. If panic_on_warn is enabled, crash the kernel; otherwise cause warning traces, kernel taint, and possible application instability.

How to detect it

Look for evidence in kernel logs rather than network telemetry, because exploitation is local and triggered through device and mmap operations. Review dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, and crash/panic logs for WARN_ON traces at drivers/gpu/drm/drm_gem.c in drm_gem_mmap_obj, especially when accompanied by media, V4L2, videobuf2_dma_sg, dma-buf, camera, or DRM modules. Correlate warnings with process names that accessed camera or graphics devices shortly before the event, such as media frameworks, browsers, sandboxed workloads, camera applications, or test tools. On systems with auditd or eBPF telemetry, review accesses to /dev/video*, /dev/media*, /dev/dri/renderD*, and mmap activity by untrusted users around the time of kernel warnings or reboots. If the system rebooted unexpectedly, inspect pstore, kdump, vmcore, systemd journal boot boundaries, and panic records to determine whether a WARN_ON escalated to a panic. There are no known public exploit tools or threat actors associated with this issue in the provided data.

• WARN_ON(!(vma->vm_flags & VM_DONTEXPAND))
• drm_gem_mmap_obj
• drivers/gpu/drm/drm_gem.c
• vb2_dma_sg_mmap
• vb2_dma_sg_memops
• videobuf2_dma_sg
• videobuf2_memops
• dma-buf
• __mmap_region
• mmap_region
• do_mmap
• vm_mmap_pgoff
• ksys_mmap_pgoff
• /dev/video
• /dev/media
• /dev/dri/renderD
• gst-launch-1.0 v4l2src
• v4l2src ! gtk4paintablesink
• Tainted: G W
• kernel.panic_on_warn

What your security team should do

• Inventory Linux systems that expose V4L2/media devices, camera drivers, DRM render nodes, or dma-buf based media pipelines to local users or containerized workloads.
• Prioritize patching systems where untrusted users can access /dev/video*, /dev/media*, or /dev/dri/*, and systems configured with panic_on_warn enabled.
• Apply vendor kernel updates or backport the upstream videobuf2_dma_sg mmap VMA flag fix to custom kernels.
• Tighten permissions on video, media, and DRM device nodes; limit membership in video, render, and similar hardware-access groups.
• Search kernel logs for prior WARN_ON traces involving drm_gem_mmap_obj, videobuf2_dma_sg, vb2_dma_sg_memops, or dma-buf import/mmap activity.
• For high-availability production systems, review kernel warning panic policy and avoid exposing affected device paths to untrusted workloads until patched.