CVE-2026-74446

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: hold event_mutex while checkpointing CRIU events<br /> <br /> kfd_criu_checkpoint_events() counts the entries in p-&gt;event_idr via<br /> kfd_get_num_events(), allocates an array sized to that count, and then<br /> walks the same IDR to fill it. Neither the count nor the walk holds<br /> p-&gt;event_mutex.<br /> <br /> The CRIU checkpoint caller holds only p-&gt;mutex. Event create and destroy<br /> (kfd_event_create()/kfd_event_destroy()) take p-&gt;event_mutex and do not<br /> take p-&gt;mutex, so a second thread in the same process can insert or remove<br /> events between the count and the walk. If an event is inserted, the walk<br /> iterates more entries than were counted and writes past the end of the<br /> ev_privs allocation; if an event is removed, the walk dereferences an<br /> entry that is being freed.<br /> <br /> Hold p-&gt;event_mutex across the count and the walk so both observe a<br /> consistent view of p-&gt;event_idr. The lock is released before<br /> copy_to_user(), which only touches the local buffer. The caller already<br /> holds p-&gt;mutex and the create/destroy paths never take p-&gt;mutex, so the<br /> p-&gt;mutex -&gt; p-&gt;event_mutex order is not inverted and no deadlock is<br /> introduced.<br /> <br /> (cherry picked from commit ff57e223ab105795b05d3ef3f3c35a5a441bcbaa)