CVE-2026-80870 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Validate CRIU-restored IDs before idr_alloc
The KFD CRIU restore flow restores previously saved object IDs from userspace.
For event restore:
kfd_criu_restore_event() -> create_signal_event() / create_other_event() -> allocate_event_notification_slot() -> idr_alloc(..., *restore_id, *restore_id + 1, ...)
For BO restore:
criu_restore_memory_of_gpu() -> idr_alloc(..., bo_priv->idr_handle, ...)
In both cases, the restored ID comes from userspace-provided CRIU data.
idr_alloc() expects the ID range values to fit within signed int limits. If a restored ID is larger than INT_MAX, it can trigger a WARN in the IDR layer.
A kernel WARN is undesirable because it prints a warning trace and may cause a panic or reboot on systems with panic_on_warn enabled.
Smatch reported these paths as allowing unchecked userspace values to reach idr_alloc().
Add INT_MAX validation before using restored IDs in:
- kfd_criu_restore_event() - criu_restore_memory_of_gpu()
If the restored ID is invalid, return -EINVAL.
This prevents invalid restore data from reaching the IDR layer and avoids WARN-triggering paths, while keeping valid restore behavior unchanged.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/05/2026
The Linux kernel's DRM AMD KFD subsystem contains a critical input validation flaw within its Checkpoint/Restore in Userspace implementation flow that allows untrusted userspace values to trigger internal kernel warnings or potential system instability. This vulnerability arises because the kfd_criu_restore_event and criu_restore_memory_of_gpu functions accept object identifiers directly from userspace-provided CRIU data without performing sufficient range checks before passing them to the IDR allocation layer. The idr_alloc function, which is responsible for managing integer ID resources within the kernel, expects input values to remain within signed 32-bit integer limits. When a restored identifier exceeds INT_MAX, it violates this assumption and triggers a WARN condition in the IDR subsystem.
From an operational perspective, while a kernel warning itself does not always constitute a full denial of service, its impact is significant on systems configured with panic_on_warn enabled or those running under strict debugging conditions. The generation of a warning trace can lead to system panics, unexpected reboots, or instability in production environments where such warnings are treated as fatal errors. This behavior effectively allows a local unprivileged user to cause a denial of service by crafting malicious CRIU restore data that contains excessively large identifiers. The flaw represents a classic case of improper input validation where external data is trusted without adequate sanitization before being used for critical resource management operations.
This vulnerability aligns with CWE-20, which describes Improper Input Validation, as the kernel fails to verify whether the restored ID values fall within acceptable bounds prior to their use in allocation routines. Furthermore, it relates to CWE-787, an Out-of-bounds Write or Access scenario, because passing a value larger than INT_MAX can lead to undefined behavior or memory corruption issues depending on how the IDR layer handles overflow conditions internally. In terms of attack vectors and techniques, this flaw is relevant to MITRE ATT&CK technique T1059, Command and Scripting Interpreter, specifically in contexts where an attacker might leverage kernel instability for privilege escalation attempts or system disruption through local exploitation paths that trigger these warning states.
The resolution involves adding explicit validation checks within the kfd_criu_restore_event and criu_restore_memory_of_gpu functions to ensure that any restored ID is less than INT_MAX before it is passed to idr_alloc. If a value exceeds this threshold, the function now returns -EINVAL, effectively rejecting invalid restore data at the earliest possible point in the execution path. This mitigation prevents malicious or corrupted CRIU archives from reaching the IDR layer and avoids triggering kernel warnings while maintaining backward compatibility with valid restore operations. System administrators should ensure that their kernels are updated to include this patch, particularly if they utilize checkpoint-restore functionality for application migration or debugging purposes. Additionally, reviewing system configurations regarding panic_on_warn settings can help mitigate the severity of such vulnerabilities in environments where immediate rebooting upon warning generation is enabled.