CVE-2026-89807: drm/amdkfd: guard against NULL restore_mqd in CRIU queue restore
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: guard against NULL restoremqd in CRIU queue restore
Both createqueuecpsch() and createqueuenocpsch() unconditionally call mqdmgr->restoremqd() when a CRIU restore is in progress (qd != NULL), with no NULL guard. On any system where restoremqd is not implemented for the given queue type, a user holding CAPCHECKPOINTRESTORE can trigger a kernel NULL pointer dereference and panic the machine by issuing KFDIOCCRIUOPRESTORE with a crafted queue restore object. Note that checkpointmqd is likewise unimplemented on GFX12, so no legitimate CRIU image can reach this path — only a hand-crafted restore payload.
Add a NULL guard for restoremqd immediately after mqdmgr is resolved, unwinding via the existing error labels and returning -EOPNOTSUPP if the callback is not implemented. This mirrors the existing checkpointmqd guard in checkpointmqd().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Implement the fix in drm/amdkfd: add a NULL guard for restore_mqd immediately after mqd_mgr is initialized, mirroring the existing checkpoint_mqd guard in checkpoint_mqd(). This prevents a kernel NULL pointer dereference triggered by CAP_CHECKPOINT_RESTORE during CRIU restore.
Linux kernel drm/amdkfd guard for NULL restore_mqd in CRIU queue restore path = Add a NULL guard for restore_mqd immediately after mqd_mgr is set; also guard checkpoint_mqd similarly
Event History
Frequently Asked Questions
What level of access is required to trigger the failure?
An attacker must hold CAP_CHECKPOINT_RESTORE and be able to issue KFD_IOC_CRIU_OP_RESTORE with a crafted queue restore object. The result can be a kernel NULL pointer dereference that panics the machine.
Are valid CRIU restore images sufficient to reach the vulnerable path?
For GFX12, checkpoint_mqd is also unimplemented, so no legitimate CRIU image can reach this path. Exploitation there requires a hand-crafted restore payload.
What is the practical mitigation if the fix cannot be deployed immediately?
Restrict CAP_CHECKPOINT_RESTORE to trusted users and prevent untrusted users from issuing KFD_IOC_CRIU_OP_RESTORE. The fix makes unsupported restore callbacks fail with -EOPNOTSUPP instead of dereferencing a NULL callback.