Description

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)

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:17:49.180Z",
  "pubdate": "2026-08-15T13:17:49.180Z",
  "executiveSummary": "A race condition vulnerability exists within the Linux kernel drm/amdkfd subsystem during the Checkpoint/Restore in Userspace (CRIU) event checkpointing process. The vulnerability is classified as a concurrency and synchronization flaw due to inadequate locking mechanisms protecting process event data structures. Specifically, the function kfd_criu_checkpoint_events() accesses the event identifier registry p->event_idr without holding the required p->event_mutex lock.\nThe primary impact of this vulnerability includes potential heap-based buffer overflows and use-after-free conditions. These memory corruption scenarios can lead to kernel crashes, denial of service, or potentially arbitrary code execution within the kernel context. The affected systems are any running Linux kernel utilizing the AMD KFD (Kernel Fusion Driver) subsystem supporting GPU process checkpointing operations.\nExploitation of this flaw requires an attacker to possess local access to the target system with the ability to execute code that interacts with the AMD KFD interface. An attacker can leverage multi-threaded execution within a process to concurrently create or destroy events while a checkpoint operation is underway, manipulating the state of p->event_idr between the entry counting phase and the data collection phase.",
  "technicalDetails": "The root cause of the vulnerability is a missing synchronization lock around shared data structure access within the Linux kernel drm/amdkfd driver. In kfd_criu_checkpoint_events(), the kernel first counts the number of entries present in the process event identifier registry p->event_idr by invoking kfd_get_num_events(). It then allocates a dynamic array based on this count and subsequently walks the IDR a second time to populate the allocated array.\nCrucially, neither the initial counting phase nor the subsequent walk holds the p->event_mutex lock. While the outer CRIU checkpoint caller holds p->mutex, event creation and destruction paths—handled by kfd_event_create() and kfd_event_destroy() respectively—acquire p->event_mutex but do not acquire p->mutex. Consequently, a secondary thread running within the same process can asynchronously insert or remove events from p->event_idr during the window between the initial count and the subsequent IDR traversal.\nThis design flaw permits two distinct race condition scenarios. First, if an adversarial or concurrently executing thread inserts a new event after the count has been established, the subsequent walk will iterate over a greater number of entries than anticipated. This results in a heap-based buffer overflow by writing past the allocated boundaries of the ev_privs buffer. Second, if a thread removes an existing event during this window, the IDR walk will attempt to dereference a memory address that is concurrently being freed, triggering a use-after-free vulnerability.\nThe attack flow proceeds as follows: 1) The primary thread initiates a CRIU checkpoint operation, triggering kfd_criu_checkpoint_events() which calculates the size of p->event_idr without holding p->event_mutex. 2) A concurrent secondary thread invokes event creation or destruction routines, modifying the state of p->event_idr. 3) The kernel resumes the IDR walk, encountering mismatched entry counts. 4) Memory corruption occurs via out-of-bounds writes or use-after-free dereferences, destabilizing the kernel and potentially allowing local privilege escalation or denial of service."
}