CVE-2026-93059 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix task_struct reference leak in recover_worker
get_pid_task() increments the task reference count, but the corresponding put_task_struct() was missing in the else branch, leaking a reference on every GPU hang recovery.
Patchwork: https://patchwork.freedesktop.org/patch/730662/
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel driver for Qualcomm Adreno GPUs, specifically within the msm subsystem, contained a resource management flaw in its error handling logic during GPU hang recovery operations. The function recover_worker is responsible for detecting and resolving situations where the Graphics Processing Unit has become unresponsive or hung. During this process, the code utilizes get_pid_task to retrieve a pointer to the task_struct associated with the current process context. This kernel API call inherently increments the reference count of the target task structure to ensure that the object remains valid in memory while it is being accessed by multiple parts of the system. However, the implementation failed to balance this increment operation with a corresponding decrement when an error condition was encountered or when execution diverged into specific conditional branches.
The technical flaw lies specifically in the else branch of the recovery logic where get_pid_task returns a valid task pointer but subsequent operations fail or take an alternative path that does not involve normal completion. In such scenarios, the reference count acquired by get_pid_task is never released via put_task_struct. This omission results in a persistent memory leak within the kernel space. Each time a GPU hang occurs and triggers this recovery routine, one additional task structure reference remains allocated indefinitely. While individual leaks may appear negligible during isolated events, they accumulate over time as long as the system experiences intermittent or frequent GPU hangs, which are not uncommon in graphics-intensive workloads or under heavy load conditions on mobile devices utilizing these drivers.
From an operational impact perspective, this vulnerability leads to a gradual depletion of kernel memory resources. Since task_struct objects consume significant amounts of contiguous physical memory and hold various internal data structures, their unchecked accumulation can eventually exhaust available system memory. This exhaustion manifests as increased latency in process scheduling, potential failure to spawn new processes due to lack of memory for task control blocks, and ultimately system instability or a complete kernel panic requiring a reboot. The issue is particularly insidious because it does not cause immediate crashes but rather degrades system performance over extended periods of usage involving GPU activity, making root-cause analysis difficult without detailed memory profiling tools.
This vulnerability aligns with CWE-401, which describes the failure to release memory after it has been successfully allocated, leading to resource consumption that can degrade service availability. In terms of attack classification under MITRE ATT&CK for Enterprise or Mobile, this falls under Resource Hijacking, specifically T1496, where an attacker could potentially induce GPU hangs through crafted graphics commands or shader programs to accelerate the memory leak and cause a Denial of Service condition against the host system. The vulnerability is primarily exploitable locally by any user with access to the DRM subsystem devices, allowing them to trigger the hang recovery path repeatedly to exhaust kernel memory.
The resolution involves modifying the recover_worker function in the drm/msm driver codebase to ensure that put_task_struct is called appropriately whenever get_pid_task succeeds but the subsequent logic does not consume or transfer ownership of the reference. This patchwork update ensures proper lifecycle management for task structures, maintaining balance between acquisition and release operations. System administrators should apply kernel updates containing this fix as soon as they become available in their distribution repositories to prevent potential denial-of-service conditions resulting from memory exhaustion on affected devices. Regular monitoring of system logs for GPU hang events can also help identify systems that may be experiencing frequent occurrences requiring mitigation through driver updates or workload adjustments until the patch is deployed.