CVE-2026-46197

What it actually does

This is a local Linux kernel memory-corruption vulnerability in the AMD KFD/AMDGPU driver path handling Shared Virtual Memory ioctl requests. A privileged local user with access to the relevant GPU device node can supply a user-controlled attribute count that is not properly validated against the provided buffer size, causing out-of-bounds kernel memory access. Depending on memory layout and exploit reliability, this can lead to kernel crash, information disclosure, or local privilege escalation with kernel-level code execution.

Why it matters to the business

Systems using affected Linux kernels with AMD GPU/KFD functionality may allow a low-privileged local user or compromised application account to escalate privileges, disrupt workloads, or potentially take full control of the host. The risk is most relevant on GPU-enabled Linux servers, workstations, VDI hosts, compute clusters, and container platforms where untrusted or semi-trusted users can run code and access GPU devices. Although no public exploit or known exploitation is reported and EPSS is currently low, the high CVSS impact means exposed multi-user or shared-compute systems should be prioritized for kernel updates.

How an attack unfolds

An attacker first obtains the ability to execute code as a low-privileged local user on a Linux system using an affected kernel and accessible AMD GPU/KFD device interface. The attacker then opens the relevant DRM/KFD device node and submits a crafted SVM ioctl request with a manipulated attribute count that exceeds what the backing user buffer can safely contain. Because the vulnerable kernel path trusts the count insufficiently, the driver performs an out-of-bounds access while processing the attributes. A simple exploit may trigger a kernel fault and denial of service; a more advanced exploit may shape kernel memory and use the out-of-bounds behavior to disclose memory or corrupt kernel state, potentially escalating to root or kernel execution.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the upstream fix validating the SVM ioctl attribute count against the supplied buffer size. No fixed package versions were provided in the input, so use the security advisory from the relevant Linux distribution or kernel vendor and ensure the patch corresponding to the drm/amdkfd SVM ioctl nattr validation fix is included. After installing the patched kernel, reboot into the updated kernel; merely installing the package is insufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by restricting access to AMD GPU/KFD device nodes, removing untrusted users from GPU-access groups, disabling AMD KFD/ROCm access for untrusted workloads, or temporarily disabling/unloading affected GPU functionality where operationally feasible.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, is updated to a vendor build containing the fix. Validate with `uname -a`, distribution package tooling, and the vendor advisory for the relevant kernel package. On source-built kernels, verify that the amdkfd SVM ioctl handling includes validation that the user-supplied attribute count cannot exceed the available buffer size. Confirm untrusted users cannot access relevant GPU device nodes such as DRM render nodes or KFD devices unless explicitly required. Review boot configuration to ensure the system actually restarted into the patched kernel, and verify no older vulnerable kernel remains the default boot entry.

Typical attack path

1. Gain local code execution as a non-root user on an affected Linux system.
2. Confirm AMDGPU/KFD functionality is present and the user can access the relevant GPU device nodes.
3. Craft an SVM ioctl request with an attribute count inconsistent with the supplied buffer size.
4. Trigger the vulnerable kernel driver path through the DRM/KFD interface.
5. Use the out-of-bounds access to crash the kernel, leak kernel memory, or corrupt kernel memory.
6. If reliable exploitation is achieved, escalate privileges or execute code with kernel-level authority.

How to detect it

Look for evidence of local attempts to exercise the AMD KFD/AMDGPU ioctl path, especially followed by kernel instability. Useful sources include kernel logs, `dmesg`, journald, syslog, audit logs for device-node access, EDR telemetry for suspicious local exploit binaries, and container runtime logs showing GPU device pass-through. Search for kernel oops, BUG, page fault, general protection fault, slab corruption, or panic messages involving `amdkfd`, `amdgpu`, `kfd_ioctl`, or SVM handling. Investigate low-privileged processes opening `/dev/kfd` or `/dev/dri/renderD*` immediately before a crash. Because memory-corruption exploitation may leave few durable artifacts, absence of logs does not prove absence of exploitation. If crash dumps are available, inspect them for faults in amdkfd SVM ioctl processing paths and correlate with user sessions, recently executed binaries, and GPU workload submissions.

• /dev/kfd
• /dev/dri/renderD
• amdkfd
• amdgpu
• kfd_ioctl
• svm_ioctl
• svm_ioctl_set_attr
• kfd_ioctl_svm
• general protection fault
• kernel BUG
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• Oops:
• kernel panic
• slab-out-of-bounds
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• use-after-free
• invalid opcode: 0000
• drm/amdkfd

What your security team should do

• Prioritize patching GPU-enabled Linux systems, shared compute platforms, developer workstations, and multi-user servers where local users or workloads can access AMD GPU devices.
• Reboot after applying kernel updates and verify the running kernel version is the patched version.
• Inventory systems exposing AMDGPU/KFD or ROCm functionality, including bare-metal GPU servers and container hosts passing GPU devices into workloads.
• Restrict access to GPU device nodes to trusted users and workloads until patching is complete.
• Monitor for kernel crashes, oops messages, or abnormal amdkfd/amdgpu errors that may indicate attempted exploitation or fuzzing.
• For containerized environments, review device pass-through policies and avoid granting untrusted containers access to `/dev/kfd` or DRM render nodes unless required.
• Because there is no known exploitation and EPSS is low, treat this as high-impact local-risk remediation rather than an internet-facing emergency, unless the environment provides shared local shell or GPU workload access.