CVE-2026-74446 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: hold event_mutex while checkpointing CRIU events
kfd_criu_checkpoint_events() counts the entries in p->event_idr via kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it. Neither the count nor the walk holds p->event_mutex.
The CRIU checkpoint caller holds only p->mutex. Event create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex, so a second thread in the same process can insert or remove events between the count and the walk. If an event is inserted, the walk iterates more entries than were counted and writes past the end of the ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed.
Hold p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted and no deadlock is introduced.
(cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's AMD Kernel Driver Framework component, specifically in the CRIU (Checkpoint/Restore in Userspace) event handling mechanism. The flaw resides in the kfd_criu_checkpoint_events() function which performs a two-step process to handle event checkpointing operations. The function first determines the number of events using kfd_get_num_events() and then iterates through the same event identifier registry (IDR) structure to populate an array with event information. Both operations occur without proper synchronization mechanisms, creating a race condition that can lead to critical memory corruption issues.
The technical implementation demonstrates a classic race condition scenario where concurrent access to shared data structures occurs without appropriate locking protocols. The function kfd_criu_checkpoint_events() operates under the assumption that the event_idr structure will remain stable between the counting phase and the iteration phase, but this assumption fails when multiple threads within the same process attempt to modify the event registry simultaneously. The event creation and destruction functions kfd_event_create() and kfd_event_destroy() utilize p->event_mutex for protection, while the checkpointing caller only holds p->mutex, creating a mismatch in locking granularity that allows for concurrent modifications during the critical window.
This vulnerability directly maps to CWE-362, which describes a race condition where two or more threads access shared data concurrently, and one thread can modify the data while another is reading or writing it. The operational impact of this flaw is severe as it can result in memory corruption that manifests as buffer overflows or use-after-free conditions. When an event is inserted between the counting and iteration phases, the function writes beyond allocated memory boundaries, potentially corrupting adjacent memory regions and leading to system instability or privilege escalation. Conversely, when events are removed during this window, the function attempts to dereference freed memory locations, causing potential crashes or data corruption.
The security implications extend beyond simple memory corruption as this vulnerability could be exploited by malicious processes to achieve privilege escalation within the kernel space. Attackers could potentially craft specific sequences of event creation and destruction operations that would reliably trigger either buffer overflow conditions or use-after-free scenarios. The flaw affects systems running Linux kernels with AMD GPU support, particularly those utilizing CRIU for checkpointing operations and process migration capabilities. Based on ATT&CK framework categorization, this vulnerability aligns with T1068 (Exploitation for Privilege Escalation) and T1547.001 (Registry Run Keys/Startup Folder), as it provides a kernel-level attack surface that could be leveraged to gain elevated privileges.
The recommended mitigation strategy involves implementing proper locking mechanisms to ensure atomicity of the counting and iteration operations within kfd_criu_checkpoint_events(). The solution requires holding p->event_mutex across both operations, ensuring that any modifications to the event_idr structure during the checkpoint process are properly synchronized. This approach maintains consistency in the event registry view while preserving the existing lock ordering that prevents deadlocks. The fix ensures that all operations accessing shared data structures maintain proper synchronization, with locks acquired in a consistent order and released before potentially dangerous user-space copy operations. The implementation follows established kernel security practices for concurrent access control and memory safety.