CVE-2026-46211: Linux Kernel Information Disclosure Bug

CVE-2026-46211 Overview

CVE-2026-46211 is a Linux kernel vulnerability in the Qualcomm MSM Direct Rendering Manager (DRM) Graphics Execution Manager (GEM) subsystem. The flaw resides in the msm_ioctl_gem_info_get_metadata() function, which unconditionally returns 0 regardless of internal error states. When copy_to_user() fails or the user buffer is undersized, the error value stored in ret is discarded, causing userspace to incorrectly believe the ioctl succeeded.

A secondary defect compounds the issue: kmemdup() can return NULL on allocation failure, but the return value is never validated before being passed to copy_to_user(). This produces a NULL pointer dereference in kernel context.

Critical Impact

A local unprivileged caller of the MSM DRM GEM_INFO ioctl can trigger a kernel NULL pointer dereference under memory pressure, leading to denial of service on affected systems.

Affected Products

• Linux kernel builds containing the drm/msm GEM driver (Qualcomm MSM GPU)
• Distributions shipping vulnerable msm_ioctl_gem_info_get_metadata() revisions prior to the upstream fix
• Android and embedded platforms using Qualcomm Adreno GPUs via the upstream MSM DRM driver

Discovery Timeline

• 2026-05-28 - CVE-2026-46211 published to NVD
• 2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-46211

Vulnerability Analysis

The msm_ioctl_gem_info_get_metadata() function in the drm/msm/gem driver handles the metadata retrieval branch of the GEM_INFO ioctl. The function allocates a kernel buffer through kmemdup(), copies the buffer contents to userspace with copy_to_user(), and reports the result to the caller.

Two defects exist in the error path. First, the function captures error codes from copy_to_user() into the ret variable but then unconditionally executes return 0. Userspace receives a success status even when the copy failed or the supplied buffer was too small to hold the metadata. The companion setter msm_ioctl_gem_info_set_metadata() correctly propagates ret, confirming the asymmetric behavior is a bug.

Second, kmemdup() returns NULL when the slab allocator cannot satisfy the request. The function does not check this return value before dereferencing the pointer in the subsequent copy_to_user() call. The NULL dereference occurs in kernel mode and triggers an oops, terminating the calling task and potentially destabilizing the GPU driver state.

Root Cause

The root cause is missing error propagation and a missing NULL check [CWE-476: NULL Pointer Dereference]. The function hardcodes return 0 instead of return ret, and omits validation of the kmemdup() allocation result before pointer use.

Attack Vector

Local access to the MSM DRM device node (typically /dev/dri/card0 or /dev/dri/renderD128) is required. Any process holding a DRM file descriptor can invoke the GEM_INFO ioctl with the metadata subcommand. Forcing allocation failure through memory pressure or supplying truncated buffers reaches the vulnerable code path. See the Patchwork submission for the upstream patch discussion.

Detection Methods for CVE-2026-46211

Indicators of Compromise

• Kernel oops messages referencing msm_ioctl_gem_info_get_metadata in dmesg or /var/log/kern.log
• NULL pointer dereference call traces originating from the drm/msm module
• Unexpected GPU driver resets or display server crashes on Qualcomm Adreno hardware

Detection Strategies

• Audit running kernel versions against the upstream fix commits 47cbfe26, 697e1a95, b079e85c, and c57c861956 to identify unpatched hosts
• Monitor for repeated invocations of the DRM GEM_INFO ioctl from non-graphics processes, which is anomalous on server and headless workloads
• Correlate kernel oops events with the process and binary that issued the triggering ioctl

Monitoring Recommendations

• Forward kernel ring buffer events to a centralized log pipeline and alert on BUG: or Oops: strings paired with msm_ symbols
• Track DRM device file access on hosts where GPU usage is not expected
• Inventory kernel package versions across the fleet and flag systems running pre-patch releases of the drm/msm driver

How to Mitigate CVE-2026-46211

Immediate Actions Required

• Update affected Linux kernels to a stable release containing the upstream fix that adds the kmemdup() NULL check and returns ret instead of 0
• Apply distribution-provided kernel security updates as soon as they are published for your kernel branch
• Restrict access to /dev/dri/* device nodes to trusted user groups on multi-tenant systems

Patch Information

The fix is committed upstream in the stable kernel tree. Reference commits include 47cbfe2608314b833ad61a65827d8fb363bc2d2d, 697e1a9559f6962f999cc4c748c2ffffcc0a7a7a, b079e85c91f446f29e808d8291189e897f1884ff, and c57c861956b89f2e2528e6384d51e2dedd915809. The patch adds a NULL check after kmemdup() and replaces the unconditional return 0 with return ret.

Workarounds

• Tighten DRM device node permissions using udev rules so only the local console user and the display server can open them
• On headless servers that do not require Qualcomm Adreno graphics, blacklist the msm module via /etc/modprobe.d/ configuration
• Apply seccomp filters in sandboxes to block the DRM ioctl numbers that route to the vulnerable metadata path

# Restrict DRM device access via udev
# /etc/udev/rules.d/99-drm-restrict.rules
SUBSYSTEM=="drm", KERNEL=="card*", MODE="0660", GROUP="video"
SUBSYSTEM=="drm", KERNEL=="renderD*", MODE="0660", GROUP="render"

# Blacklist msm driver on systems that do not need it
echo "blacklist msm" | sudo tee /etc/modprobe.d/blacklist-msm.conf
sudo update-initramfs -u