CVE-2026-43302

What it actually does

This issue affects the Linux kernel V3D DRM graphics driver. The driver does not set an appropriate DMA maximum segment size for V3D buffer mappings, so DMA scatter-gather mappings can exceed the kernel's default 64 KB segment limit. On systems built with CONFIG_DMA_API_DEBUG, this causes DMA API debug warnings during V3D rendering or buffer-object creation. In configurations where kernel warnings are treated as fatal, such as panic_on_warn, a local user able to exercise the V3D render interface can trigger a kernel panic and denial of service. The practical impact is availability loss rather than confidentiality or integrity compromise.

Why it matters to the business

Affected Linux systems using the V3D graphics driver, especially Raspberry Pi-class platforms and embedded or desktop systems with DMA API debugging or panic-on-warning policies enabled, may become unstable or crash when local graphics workloads are run. The risk is primarily operational disruption: device reboot, service interruption, kiosk or edge-device downtime, and potential loss of unsaved work. EPSS is very low and there is no known KEV listing or ransomware association, so broad internet-scale exploitation is unlikely; however, local multi-user, kiosk, lab, CI, and embedded deployments should still prioritize remediation where untrusted users or workloads can access GPU rendering.

How an attack unfolds

An attacker first needs local code execution or an account that can access the V3D DRM render device. They then run or craft a graphics workload that causes the V3D driver to create and map a sufficiently large buffer object through the DRM ioctl path. Because the driver has not advertised a large enough DMA segment size, the DMA debug subsystem detects a scatter-gather segment larger than the device claims to support and emits a kernel warning. On systems configured to continue after warnings, this may produce repeated kernel log noise and degraded reliability. On systems configured to panic on warnings, the same trigger can crash the kernel, causing an immediate denial of service and reboot or outage. No remote network access path or privilege escalation primitive is indicated by the available details.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the V3D DRM driver fix to set the DMA maximum segment size appropriately. No exact fixed package versions were provided, so use the latest stable kernel or distribution kernel containing the upstream drm/v3d change described as setting the DMA segment size to avoid DMA API debug warnings. Where immediate patching is not possible, reduce exposure by restricting access to DRM render devices to trusted users only, disabling untrusted local graphics workloads, and avoiding panic_on_warn on systems where availability is more important than fail-fast debugging. Do not treat disabling CONFIG_DMA_API_DEBUG as a complete security fix; it may suppress the warning but does not apply the driver correctness change.

How to confirm the fix worked

Confirm the running kernel includes the V3D driver update from the distribution or upstream stable tree. Validate by checking the installed kernel package changelog or source for the V3D change that sets the DMA segment size. On test systems, run representative V3D rendering workloads or buffer-allocation tests and verify that dmesg, journalctl -k, and kern.log no longer show DMA API warnings for v3d. Also verify that /proc/sys/kernel/panic_on_warn is set according to the organization's availability and debugging policy, and that access permissions for DRM render nodes are limited to intended local users and service accounts.

Typical attack path

1. Obtain local execution on an affected Linux system with the V3D DRM driver enabled.
2. Confirm access to the graphics render interface, typically through a DRM render node used by Xorg, Wayland, Mesa, or GPU workloads.
3. Run or craft a V3D rendering or buffer-allocation workload that creates a large GEM buffer object.
4. Trigger the V3D DRM ioctl path that maps scatter-gather DMA memory for the buffer.
5. Cause the DMA API debug subsystem to emit a warning about a mapped segment exceeding the default 64 KB maximum segment size.
6. If kernel panic-on-warning is enabled, force a kernel panic and deny service to the host; otherwise, cause recurring warnings and possible instability or log flooding.

How to detect it

Look for evidence in kernel logs rather than network telemetry. Useful sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, crash dumps, pstore, kdump artifacts, and system reboot records. Search for DMA API debug warnings naming the v3d device, especially messages stating that an sg segment is longer than the device claims to support. Correlate warning timestamps with local user sessions, Xorg or Wayland activity, Mesa/V3D workloads, GPU-accelerated applications, container jobs with GPU access, and unexpected reboots. If panic_on_warn is enabled, also look for kernel panic records immediately following the DMA warning. There are no known public exploit-specific payload strings or threat actor indicators from the provided data, so detection should focus on the kernel warning, V3D DRM ioctl activity, and unexplained availability events.

• DMA-API: v3d
• mapping sg segment longer than device claims to support
• max=65536
• debug_dma_map_sg
• WARNING: CPU:
• v3d_bo_create_finish
• v3d_create_bo_ioctl
• drm_ioctl_kernel
• drm_ioctl
• drm_gem_shmem_get_pages_sgt
• Comm: Xorg
• 1002000000.v3d
• /proc/sys/kernel/panic_on_warn

What your security team should do

• Inventory Linux systems using the V3D DRM driver, particularly Raspberry Pi 5 and other Broadcom V3D-based platforms.
• Prioritize patching systems that allow untrusted local users, kiosk workloads, CI jobs, containers with GPU access, or remote desktop sessions to use local GPU rendering.
• Upgrade to the latest vendor-supported kernel containing the drm/v3d DMA segment size fix.
• Search historical kernel logs for DMA API warnings involving v3d to identify systems that have already encountered the condition.
• Review panic_on_warn settings; avoid enabling it on production systems where this warning could create unnecessary outages unless required by policy.
• Restrict permissions to DRM render nodes so only trusted users and processes can access V3D rendering interfaces.
• Monitor for repeated V3D DMA API warnings as a potential sign of attempted local denial-of-service triggering or unstable graphics workloads.