CVE-2026-46211

What it actually does

This is a local Linux kernel denial-of-service flaw in the Qualcomm MSM DRM/GPU driver metadata ioctl handling. The vulnerable function, msm_ioctl_gem_info_get_metadata(), incorrectly returns success even when copy_to_user() fails or the caller-provided userspace buffer is too small, causing incorrect userspace state. More importantly, it does not check whether kmemdup() returned NULL after an allocation failure; if allocation fails, the kernel can dereference a NULL pointer during the subsequent copy_to_user() path, triggering a kernel oops or panic. Exploitation requires local access and low privileges, and the expected impact is loss of system availability rather than confidentiality or integrity compromise.

Why it matters to the business

A local user or compromised low-privilege process may be able to crash affected Linux systems that expose the MSM DRM/GPU driver, causing service interruption, device instability, workload disruption, or forced reboots. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity indicated, so urgency is primarily driven by exposure to untrusted local users, shared systems, mobile/embedded deployments, kiosk-style devices, and environments where uptime is critical.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user on a system using the affected Linux kernel DRM MSM driver. They interact with the DRM device node associated with the MSM GPU driver and issue the GEM metadata retrieval ioctl with parameters designed to exercise the faulty error handling path. If the caller supplies an undersized or invalid userspace buffer, the kernel may incorrectly report success to userspace, which can confuse applications but is not the main security impact. To cause a denial of service, the attacker attempts to drive the kmemdup() allocation failure path, for example by repeatedly invoking the ioctl or creating memory pressure until allocation fails. Because the vulnerable code does not validate the allocation result, the kernel can attempt to use a NULL pointer during copy_to_user(), resulting in a kernel oops or panic and a local system crash.

How to fix it

Update to a Linux kernel build that includes the upstream fix for drm/msm/gem: returning the actual error code from msm_ioctl_gem_info_get_metadata() and checking the kmemdup() return value before use. No exact fixed version was provided in the input, so remediation should be based on the vendor, distribution, Android/embedded BSP, or kernel maintainer advisory for the affected kernel branch. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting access to DRM device nodes to trusted users only, disabling or unloading the MSM DRM/GPU driver where operationally feasible, applying device cgroup controls for containers, and using mandatory access controls such as SELinux or AppArmor to prevent untrusted workloads from opening relevant /dev/dri devices. Mitigations should be treated as temporary because they do not correct the faulty kernel code path.

How to confirm the fix worked

Confirm the running kernel package or source tree contains the patched drm/msm/gem change that adds a kmemdup() NULL check and returns ret instead of unconditionally returning 0 from msm_ioctl_gem_info_get_metadata(). Validate through the distribution security advisory, kernel changelog, package version, or by inspecting the patched source. On affected hardware, confirm whether the msm DRM driver is present and loaded using commands such as lsmod, modinfo, dmesg, and checks for /dev/dri device nodes. After patching, run a controlled regression test for the GEM metadata ioctl path using invalid or undersized user buffers and verify that the ioctl returns an error instead of success and does not produce a kernel oops. Also confirm that local access controls prevent untrusted users or containers from accessing DRM device nodes unless required.

Typical attack path

1. Gain local access to an affected Linux system as a low-privilege user or execute code through a compromised local process.
2. Confirm that the system exposes the Qualcomm MSM DRM/GPU driver and accessible DRM device nodes, such as /dev/dri/card* or /dev/dri/renderD*.
3. Open the DRM device and issue the MSM GEM metadata retrieval ioctl from a crafted local program.
4. Use malformed, undersized, or invalid userspace buffers to trigger incorrect ioctl error handling behavior.
5. Create or rely on memory pressure so the kmemdup() allocation in the ioctl path returns NULL.
6. Trigger the NULL pointer dereference in the subsequent copy_to_user() path, causing a kernel oops, panic, or system reboot.

How to detect it

Look for evidence of prior exploitation in kernel logs, crash dumps, audit logs, and endpoint telemetry. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output, pstore/ramoops records, kdump/vmcore artifacts, auditd logs for access to /dev/dri devices, and EDR process telemetry showing unusual local programs repeatedly opening DRM device nodes or invoking DRM ioctls. Exploitation is most likely to appear as a kernel oops, panic, NULL pointer dereference, or general protection fault involving msm_ioctl_gem_info_get_metadata(), drm/msm GEM handling, copy_to_user(), or drm_ioctl(). Correlate crash timestamps with local user sessions, newly executed binaries, memory-pressure events, and repeated access to /dev/dri/card* or /dev/dri/renderD*. Because this is a local denial-of-service flaw, there may be no network indicator; absence of network activity does not rule out exploitation.

• msm_ioctl_gem_info_get_metadata
• drm/msm/gem
• drm/msm
• copy_to_user
• kmemdup
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• drm_ioctl
• /dev/dri/card0
• /dev/dri/card1
• /dev/dri/renderD128
• /sys/module/msm
• msm_drm

What your security team should do

• Inventory Linux systems, embedded devices, Android-derived platforms, and appliances that use Qualcomm MSM DRM/GPU kernel support.
• Prioritize patching systems where untrusted users, containers, sandboxed apps, kiosk users, or third-party workloads can execute local code.
• Obtain fixed kernel packages or BSP updates from the relevant Linux distribution, device vendor, or kernel maintainer because no universal fixed version is provided.
• Restrict access to /dev/dri/card* and /dev/dri/renderD* device nodes to trusted users and service accounts until patched.
• Review container and virtualization policies to ensure untrusted workloads cannot access host DRM devices through device passthrough or overly broad device cgroup permissions.
• Monitor kernel logs for oops, panic, or NULL pointer dereference events referencing msm_ioctl_gem_info_get_metadata, drm/msm, copy_to_user, or GEM metadata ioctl handling.
• Treat unexplained crashes on affected systems as potentially security-relevant and preserve kernel logs, crash dumps, and recent local process execution history for investigation.