CVE-2026-89978 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: return early from a zero-length flush
SYNC_BO does not constrain its size, so a request for zero bytes reaches drm_clflush_virt_range(), which ends with an unconditional clflushopt(end - 1). For an empty range that is the byte before the mapping, and abo->mem.kva comes from vmap(), so the access lands in the guard page below the vmalloc area and faults:
BUG: unable to handle page fault for address: ffffd16fbbc70fff #PF: supervisor read access in kernel mode Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 7 UID: 1000 Comm: sync_bo_probe RIP: 0010:drm_clflush_virt_range+0x3c/0x70 Call Trace: amdxdna_drm_sync_bo_ioctl+0x124/0x430 [amdxdna]
drm_ioctl+0x301/0x4c0 __x64_sys_ioctl+0x115/0x2f0 do_syscall_64+0xa6/0x3d0
Any process that can open the render node can do this. Reproduced 3 of 3 times on a Strix Point NPU (1022:17f0), by calling SYNC_BO with size 0 on an AMDXDNA_BO_SHARE object. The import arm takes the same request but flushes the whole scatterlist, so it survives it.
Nothing needs flushing for an empty range, so answer before choosing a path.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel driver for AMD XDNA accelerators contains a critical flaw in its handling of buffer synchronization operations that can lead to a local denial of service condition. The vulnerability resides within the SYNC_BO ioctl implementation, specifically when processing requests with zero-length buffers. Under normal circumstances, cache flushing mechanisms are designed to ensure data consistency between CPU and accelerator memory views. However, the current logic fails to validate the size parameter before proceeding to execute hardware-specific flush operations. This oversight allows a user-space process to trigger an invalid memory access sequence by submitting a synchronization request for an empty buffer range.
The technical root cause involves the interaction between the driver's ioctl handler and the kernel's virtual memory management subsystem. When a zero-byte flush is requested, the code path proceeds directly to drm_clflush_virt_range without checking if the length is non-zero. This function calculates the end address of the range by subtracting one from the start pointer for optimization purposes using clflushopt instructions. For an empty range where the start and end pointers are identical or effectively adjacent in a way that results in underflow relative to valid mappings, this calculation points to memory immediately preceding the allocated virtual mapping area. Since these mappings originate from vmap allocations, they are surrounded by guard pages designed to catch out-of-bounds accesses. Consequently, executing an instruction against this guard page triggers a supervisor read access fault in kernel mode, resulting in a kernel oops and system instability.
This vulnerability is classified under CWE-362, which describes concurrent execution issues or race conditions leading to unintended behavior, although more specifically it aligns with CWE-190 Integer Overflow/Wraparound due to the arithmetic operation on pointers that results in an invalid address calculation for empty ranges. From a threat modeling perspective using MITRE ATT&CK, this flaw facilitates Local Privilege Escalation via Denial of Service (T1498) or potentially T1531 if it leads to system crashes affecting availability. The attack vector is local and requires the attacker to have access to the render node device file associated with the AMD XDNA accelerator hardware. Any unprivileged user who can open this device interface can exploit the flaw by invoking the SYNC_BO ioctl command with a size parameter set to zero, thereby crashing the kernel or destabilizing the host system running the NPU driver.
The operational impact of this vulnerability is significant for systems relying on AMD's AI accelerators for compute tasks. A successful exploitation results in an immediate kernel panic or oops, causing a complete loss of availability for the affected machine. Since the flaw occurs during standard synchronization operations that might be triggered by various applications interacting with the hardware, it presents a reliable method for denial-of-service attacks without requiring complex exploit development techniques beyond submitting specific ioctl calls. The vulnerability affects both direct allocation paths and import arm scenarios where scatterlist flushing is involved, although the immediate crash is most consistently reproduced on AMD Strix Point NPUs when targeting shared buffer objects.
Mitigation strategies should focus on implementing strict input validation within the driver's ioctl handler before any memory operations are initiated. Developers must enforce a check to ensure that the requested flush size is greater than zero prior to calling drm_clflush_virt_range or similar cache maintenance functions. If an empty range is detected, the function should return early with success status since there is no data state to synchronize. This defensive programming approach prevents the arithmetic underflow that leads to guard page access. Additionally, kernel maintainers may consider adding explicit bounds checking for all memory mapping sizes in accelerator drivers to prevent similar issues across other hardware interfaces. Until a patch is applied, administrators should restrict access to render nodes and monitor system logs for suspicious ioctl patterns targeting zero-length operations on AMD XDNA devices.