CVE-2026-72092 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
accel/amdxdna: reject command submission on devices without a submit op
amdxdna_cmd_submit() calls xdna->dev_info->ops->cmd_submit() unconditionally, but only aie2_dev_ops defines that callback. aie4_vf_ops (the AIE4 SR-IOV virtual function) does not, so a user AMDXDNA_EXEC_CMD ioctl on an AIE4 device reaches a NULL function-pointer call and oopses the kernel. AIE4 submits work through a mapped user queue and doorbell, not this ioctl path.
Reject the submission early with -EOPNOTSUPP when the device provides no cmd_submit op, so the shared EXEC ioctl is a clean no-op on such devices.
Found by 0sec automated security-research tooling (https://0sec.ai).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/16/2026
The Linux kernel driver for AMD XDNA accelerators contains a critical null pointer dereference vulnerability that arises from improper validation of device capabilities during command submission operations. The core issue resides in the amdxdna_cmd_submit function, which is invoked when user-space applications attempt to submit execution commands via the EXEC ioctl interface. This function unconditionally calls the cmd_submit callback defined within the xdna->dev_info->ops structure without first verifying whether that specific operation pointer has been initialized for the target device hardware variant. While older or standard AIE2 devices define this operational callback, newer AIE4 virtual functions operating under SR-IOV configurations do not implement it because they utilize a fundamentally different submission mechanism involving mapped user queues and doorbell registers rather than the traditional ioctl-based command path.
When an unprivileged user attempts to execute the AMDXDNA_EXEC_CMD ioctl on an AIE4 device configured as a virtual function, the kernel proceeds to dereference the null cmd_submit pointer within the driver's operation structure. This results in a immediate kernel oops or panic due to accessing memory address zero through an invalid function call. Such a vulnerability allows for local denial of service attacks where any user with access to the accelerator device node can crash the host system by triggering this specific code path. The severity is compounded by the fact that the flaw exists within core driver logic, making it accessible to any process capable of opening and interacting with the character device associated with the AMD XDNA hardware acceleration unit.
This vulnerability aligns with CWE-476, which describes a NULL pointer dereference error occurring when software fails to check for null pointers before using them as if they were valid memory addresses. In terms of offensive security frameworks, this flaw facilitates Local Denial of Service (T1529) within the ATT&CK framework by allowing an attacker to disrupt system availability through kernel-level crashes. The root cause is a lack of defensive programming practices where the driver assumes all supported device types expose the same set of operational callbacks without performing capability checks prior to execution. This oversight highlights the risks associated with shared ioctl interfaces that must handle multiple hardware variants with divergent internal architectures and submission mechanisms.
To mitigate this vulnerability, it is essential for system administrators to apply kernel updates provided by their distribution vendors that include patches from upstream Linux maintainers addressing the AMD XDNA driver logic. The fix involves modifying the amdxdna_cmd_submit function to explicitly check if the cmd_submit operation pointer is non-null before attempting invocation. If the pointer is null, indicating that the device does not support this specific submission method, the function should return an error code such as -EOPNOTSUPP rather than proceeding with the dereference. This ensures that shared ioctl interfaces behave gracefully on hardware variants where those operations are unsupported or implemented differently. Organizations relying on AMD XDNA accelerators in virtualized environments must prioritize patching to prevent potential system instability and ensure compliance with secure coding standards for kernel drivers handling user-supplied input.