CVE-2026-63881

What it actually does

This is a local Linux kernel memory-safety vulnerability in the AMD Kernel Fusion Driver debugger path. The vulnerable code calculates an allocation size as num_queues * sizeof(uint32_t); on builds where size_t is 32-bit, a large attacker-controlled queue count can overflow the multiplication, producing an undersized allocation. Subsequent use of the larger logical queue count can then corrupt adjacent kernel memory. Depending on kernel configuration, allocator behavior, and reachable code paths, this can lead to local privilege escalation, kernel memory disclosure, data corruption, or a denial of service through a kernel crash.

Why it matters to the business

Successful exploitation requires local access, but the impact can be severe: a low-privileged user or compromised local process may be able to gain kernel-level control or crash affected Linux systems. Systems using AMD GPU compute/debugging functionality are the primary concern. The low EPSS and absence from CISA KEV indicate no known broad exploitation at this time, but the high CVSS impact means exposed multi-user Linux workstations, GPU compute nodes, VDI hosts, and shared research or build systems should be prioritized for kernel updates.

How an attack unfolds

An attacker first obtains the ability to run code locally as an unprivileged or low-privileged user on a Linux system with the affected AMD KFD/AMDGPU kernel functionality available. The attacker then interacts with the KFD debugger interface and supplies a crafted queue count large enough that the kernel's allocation-size calculation wraps on a 32-bit size_t build. The kernel allocates a buffer that is smaller than the code expects, then processes queue identifiers as though the full attacker-supplied count were valid. This mismatch can overwrite or expose adjacent kernel memory. With a reliable exploit, the attacker attempts to shape heap layout, corrupt security-sensitive kernel objects, and escalate privileges; less controlled attempts may simply trigger an oops, panic, or GPU driver instability.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the AMD KFD debugger integer-overflow issue, specifically the change that replaces the unsafe multiplication with overflow-safe array sizing in get_queue_ids(). Because no product-specific fixed versions were provided, use the latest security kernel from the operating-system vendor or a kernel version that contains the upstream/cherry-picked fix for commit 2d57a0475f085c08b49312dfd8edcb461845f285. Reboot into the patched kernel after installation. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting access to GPU/KFD device nodes to trusted users only, disabling unused AMDGPU/KFD functionality, or booting a kernel configuration that does not include the vulnerable driver path. Mitigations should be treated as temporary because this is kernel memory corruption with high impact.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated and the system has rebooted. Validate with uname -a and the distribution package manager to ensure the active kernel includes the vendor security fix. If maintaining a custom kernel, inspect the source or patch set for the AMD KFD debugger change in get_queue_ids() that uses overflow-safe allocation sizing, such as array_size(), instead of num_queues * sizeof(uint32_t). On systems that do not require AMD KFD functionality, verify that relevant device nodes are absent or restricted and that untrusted users cannot access them. Review dmesg or journal logs after reboot to ensure the AMDGPU/KFD driver loads cleanly and there are no recurring kernel oops, KASAN, slab, or GPU driver faults.

Typical attack path

1. Gain local code execution on an affected Linux system, such as through a shell, compromised application, or low-privileged account.
2. Confirm that the AMDGPU/KFD kernel driver and debugger-related interfaces are present and reachable.
3. Invoke the relevant KFD debugger path with a maliciously large queue count that causes integer overflow in the queue ID array-size calculation on vulnerable builds.
4. Trigger the kernel to operate on the undersized allocation, causing out-of-bounds memory access or corruption.
5. Use the resulting kernel memory corruption to attempt privilege escalation, information disclosure, or denial of service.
6. Clean up user-space artifacts where possible; kernel crashes or oops traces may remain in system logs if exploitation is unstable.

How to detect it

This vulnerability is difficult to detect after the fact because successful exploitation occurs through local kernel driver interactions that are not normally logged at the syscall or ioctl argument level. Focus on evidence of failed or unstable exploitation and on suspicious local activity around AMDGPU/KFD interfaces. Review kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, and crash dumps for amdgpu or amdkfd faults, kernel oopses, panics, KASAN reports, slab allocator corruption, or traces referencing get_queue_ids or KFD debugger code. Correlate these with local user sessions, recently executed binaries, unexpected access to GPU device nodes, and privilege changes. On systems with auditd or eBPF telemetry, look for unusual repeated opens or ioctl-heavy activity against AMD GPU/KFD character devices by nonstandard users or processes. If a crash dump is available, inspect stack traces for AMD KFD debugger functions and memory-corruption signatures. Absence of these artifacts does not prove non-exploitation, particularly if the attacker achieved reliable privilege escalation without crashing the kernel.

• get_queue_ids
• amdkfd
• kfd debugger
• drm/amdkfd
• amdgpu
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• BUG: unable to handle kernel paging request
• kernel BUG at
• general protection fault
• slab corruption
• kernel panic
• /dev/kfd
• /dev/dri/renderD

What your security team should do

• Prioritize patching shared Linux systems, GPU compute nodes, developer workstations, VDI hosts, and any multi-user environments where local users can access AMD GPU/KFD functionality.
• Verify that systems have rebooted into the patched kernel; installed-but-not-running kernel updates do not remediate this issue.
• Restrict access to AMD GPU/KFD device nodes to trusted users and groups until patching is complete.
• Harden local access controls: remove unnecessary shell access, review sudoers and GPU-access groups, and monitor for unexpected users running GPU/debugger tooling.
• Search kernel logs for recent oops, panic, KASAN, slab corruption, or amdgpu/amdkfd fault messages that could indicate failed exploitation or driver instability.
• For custom kernels, confirm the exact upstream fix or equivalent overflow-safe allocation pattern is present in the AMD KFD debugger code.
• Because there is no known KEV listing, ransomware association, or mature public exploit signal in the provided data, treat this as high-impact local privilege-escalation risk rather than active internet-wide exploitation.