CVE-2026-46215 is a race-condition use-after-free in the Linux kernel Direct Rendering Manager (DRM) GEM handle-change path. During a PRIME handle swap, a GEM object can temporarily be represented by two IDR handle entries. A concurrent GEM close operation can free the object after removing the old handle while the replacement handle still references the freed object. A later dereference of that dangling handle results in use-after-free. The upstream correction replaces the old handle with NULL before the PRIME swap and closes it only after successful PRIME operations, preventing concurrent close operations from retaining a stale reference.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
3 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos.
Repository is a small standalone local privilege-escalation exploit project consisting of a Makefile, a README, and one large C source file. It is not part of a common exploit framework. The Makefile statically builds exploit.c into a single binary linked with pthread and util libraries. The README describes the exploit as targeting CVE-2026-46215, a Linux kernel use-after-free in the DRM GEM/virtgpu area, adapted for Linux kernel 7.0 and claimed vulnerable through 7.0.8. It emphasizes environmental constraints: text mode only, Ubuntu/Lubuntu 26 test environment, and membership in the video group so the exploit can access DRM device nodes under /dev/dri. It also provides a QEMU example using virtio/virtgpu-related devices, which aligns with the exploit’s dependency on DRM/virtgpu functionality. The main exploit logic is in exploit.c. From the visible code and symbols, it performs a local kernel heap/UAF exploitation workflow using DRM ioctls and heavy pipe-based heap shaping/reclamation. It appears to create a dangling DRM object handle, query DRM_IOCTL_VIRTGPU_RESOURCE_INFO to leak or validate reclaimed object contents, and use DRM_IOCTL_GEM_FLINK as an additional state check. The code then writes a hardcoded payload through many pipes, likely leveraging pipe-buffer state/cross-cache behavior to corrupt or overwrite a target file. Success is verified by opening TARGET_FILE, reading it back, and checking for the marker string "dirty". On success it prints a confirmation and calls root("root"), indicating the final goal is root privilege escalation. Operationally, this is more than a bare PoC: it includes retry logic, progress output, heap grooming/reclamation helpers, and a built-in post-exploitation path. However, the payload appears hardcoded rather than modular, so OPERATIONAL is the best fit rather than WEAPONIZED.
This repository is a small standalone local privilege escalation exploit project consisting of a Makefile, a README, and a single C source file (exploit.c). It is not part of a larger exploit framework. The Makefile statically builds the binary with pthread support, indicating the exploit relies on concurrency/race behavior. The README identifies the target as CVE-2026-46215, described as a Linux kernel use-after-free caused by an old handle not being nulled, leaving a dangling pointer. The exploit is explicitly presented as unstable and tuned for Linux kernel 7.0, though the README claims the vulnerable range includes 7.0 through 7.0.8 and 7.0-rc series. It also documents environmental constraints: text mode only, tested on Lubuntu/Ubuntu 26, and requiring membership in the video group so the process can access DRM devices under /dev/dri. The exploit.c file contains the actual exploit logic. From the visible code, it interacts directly with DRM/virtio GPU ioctls, including GEM close/flink/change-handle, dumb buffer creation, version queries, and virtgpu resource info queries. The helper function open_drm() enumerates /dev/dri/card* devices and selects one whose DRM version string contains "virtio", showing that the exploit specifically depends on a virtio GPU-backed DRM device. The code also includes CPU pinning/unpinning, nanosecond spinning, pipe spraying, and large object-grooming constants, all consistent with a race-driven kernel heap manipulation strategy. The exploit appears to perform heap grooming and cross-cache spraying using many pipes and DRM objects to reclaim a freed kernel object and turn the dangling handle into a useful primitive. It then probes leaked values via DRM_IOCTL_VIRTGPU_RESOURCE_INFO, treating anomalous values as a KASLR-related leak. After a favorable state is reached, it writes a hardcoded payload through sprayed pipes and attempts to overwrite /etc/passwd. Success is verified by reopening /etc/passwd and checking for the string "dirty"; on success it prints a confirmation and calls a root("root") routine, indicating final privilege escalation. Overall, this is a real standalone local kernel exploit PoC with an embedded operational payload rather than a mere detector. It does not contact remote network infrastructure. Its main capabilities are: locating a virtio DRM device, racing a kernel UAF, grooming kernel heap state, obtaining a likely kernel leak, using a write primitive to overwrite /etc/passwd, and escalating to root. The code is operational but brittle, with repeated retries and explicit warnings about crashes and unreliability.
Repository contains a complete local privilege escalation exploit for CVE-2026-46215, a Linux kernel DRM GEM use-after-free in drm_gem_change_handle_ioctl. Structure is minimal: README.md documents the bug, affected/fixed versions, exploit chain, prerequisites, and expected output; poc.c implements the exploit in C; run_exploit.sh builds a static PoC plus a tiny initramfs and boots a vulnerable kernel in QEMU for reproduction. The exploit is not a scanner or detection script. It is an operational end-to-end LPE chain. In poc.c, two threads race DRM_IOCTL_GEM_CHANGE_HANDLE against DRM_IOCTL_GEM_CLOSE on a GEM object to create a dangling handle. The freed slab slot is reclaimed with sprayed pipe_buffer objects. A driver-specific info ioctl (virtio_gpu or nouveau) is then used to leak a kernel pointer from overlapped pipe_buf_ops, giving a KASLR bypass. Next, DRM_IOCTL_GEM_FLINK is used so the GEM object's name field overlaps pipe_buf flags, setting PIPE_BUF_FLAG_CAN_MERGE. Finally, writes to the prepared pipes are merged into the page cache of /etc/passwd, overwriting the root entry and removing its password field, yielding passwordless root. The code then verifies the file modification and spawns a shell. The bash wrapper is a reproducibility harness rather than the exploit itself. It compiles the PoC statically, creates a helper that drops to uid/gid 1000, builds an initramfs with busybox, creates a read-only /etc/passwd, and boots QEMU with virtio-gpu-pci, KVM, and nokaslr. Inside the guest it waits for /dev/dri/card0, chmods /dev/dri/* to make the device accessible, runs the exploit as an unprivileged user, and prints /etc/passwd before and after. Overall purpose: demonstrate reliable exploitation of the DRM GEM handle UAF to achieve unprivileged root on vulnerable Linux kernels with compatible DRM drivers.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
29 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Mentioned only as a recent search term; no vulnerability details are provided in the content.
A Linux kernel DRM vulnerability involving setting the old handle to NULL before prime swap in change_handle.
A Linux kernel DRM vulnerability caused by a race condition in change_handle that could leave a dangling handle and lead to a use-after-free.
A Linux kernel DRM vulnerability related to handle management during prime swap in change_handle.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.