CVE-2026-31439

What it actually does

This is a local denial-of-service flaw in the Linux kernel Xilinx XDMA dmaengine driver. The driver incorrectly checks the return value from devm_regmap_init_mmio(): the API returns an ERR_PTR() on failure, not NULL. On systems where this driver is present and the regmap initialization path can be made to fail, the driver may treat an error pointer as a valid regmap object, leading to a kernel fault, oops, or panic. The impact is availability only; the published scoring indicates no confidentiality or integrity impact and requires local low-privileged access.

Why it matters to the business

An attacker with local access to an affected Linux system may be able to crash the host or disrupt workloads that depend on it. The risk is most relevant to systems using or exposing the Xilinx XDMA driver, such as FPGA, accelerator, embedded, or specialized PCIe/DMA environments. EPSS is very low and there is no known CISA KEV listing or public exploit maturity reported, so broad internet-scale exploitation is unlikely, but the operational impact can still be high for systems where local users, containers, or untrusted workloads can interact with hardware drivers.

How an attack unfolds

An attacker first needs local execution on an affected Linux system and a way to influence or trigger the Xilinx XDMA driver initialization/probe path. They attempt to cause devm_regmap_init_mmio() to fail, for example by reaching an error condition during device probing, driver binding, or related hardware/resource initialization. Because the vulnerable driver checks for NULL instead of checking IS_ERR(), the returned error pointer is not handled correctly. The driver then continues as though initialization succeeded and later uses the invalid pointer, causing a kernel exception that can escalate to an oops or full system panic depending on kernel configuration and runtime conditions.

How to fix it

Apply a Linux kernel update from the operating system, appliance, or embedded platform vendor that includes the Xilinx XDMA regmap error-handling fix for this issue. No exact fixed package versions were provided in the input, so track the vendor advisory or upstream stable kernel release notes for the backported fix. If immediate patching is not possible, reduce exposure by disabling or removing the Xilinx XDMA driver where it is not required, preventing untrusted users from loading/unloading or rebinding kernel drivers, restricting access to relevant device nodes and sysfs driver controls, and avoiding deployment of untrusted workloads on hosts that expose this hardware path. For custom kernels, ensure the driver uses IS_ERR()/PTR_ERR() handling for devm_regmap_init_mmio() failures rather than checking only for NULL.

How to confirm the fix worked

Confirm the running kernel package or custom kernel source contains the corrected error handling in the Xilinx XDMA driver. For source validation, inspect drivers/dma/xilinx/xdma.c or the vendor-patched equivalent and verify devm_regmap_init_mmio() return values are checked with IS_ERR() and reported with PTR_ERR(). For binary validation, compare the installed kernel version and vendor build metadata against the advisory-fixed release. Confirm whether the module/driver is present or loaded using standard kernel module and device-driver inventory methods, and test that normal XDMA device probing does not produce kernel oops or panic messages in dmesg or journald.

Typical attack path

1. Gain local execution on a Linux system running an affected kernel with the Xilinx XDMA dmaengine driver available or loaded.
2. Identify whether the Xilinx XDMA device/driver can be probed, rebound, or otherwise exercised by the attacker’s privilege level.
3. Trigger a driver initialization path where devm_regmap_init_mmio() fails.
4. Rely on the vulnerable NULL-only error check to allow an ERR_PTR() value to be treated as valid.
5. Cause the driver to dereference or otherwise use the invalid regmap pointer.
6. Crash the kernel or degrade system availability through an oops, panic, or driver failure.

How to detect it

Look for signs of local denial-of-service activity rather than network exploitation. Relevant sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, and audit logs for module loading or sysfs driver bind/unbind activity. Investigate kernel oops or panic events that reference the Xilinx XDMA driver, regmap initialization, invalid pointer dereferences, or failures around device probing. Correlate crash timing with local user sessions, container activity, modprobe/rmmod attempts, writes to driver bind/unbind sysfs paths, and hardware hotplug/probe events. Because no known public exploit or KEV exploitation is reported, repeated XDMA-related crashes after local driver interaction are stronger signals than ordinary isolated hardware initialization failures.

• xdma
• xilinx_xdma
• Xilinx XDMA
• drivers/dma/xilinx/xdma.c
• devm_regmap_init_mmio
• regmap init
• regmap initialization
• Oops:
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• general protection fault
• /sys/bus/platform/drivers/xdma/bind
• /sys/bus/platform/drivers/xdma/unbind
• /sys/bus/pci/drivers/xdma/bind
• /sys/bus/pci/drivers/xdma/unbind

What your security team should do

• Inventory Linux systems that include Xilinx XDMA hardware support, especially FPGA, accelerator, embedded, and specialized PCIe/DMA platforms.
• Prioritize patching systems where local users, container workloads, or automation can interact with device binding, module loading, or hardware initialization paths.
• If the driver is not required, disable it in the kernel configuration, blacklist the module, or remove the package providing it where supported by the platform vendor.
• Restrict privileges for module loading, sysfs driver bind/unbind operations, and direct device access to trusted administrators only.
• Monitor kernel logs for XDMA-related oops, panic, or regmap initialization failures, particularly on shared systems.
• For custom or vendor-maintained kernels, verify the upstream fix has been backported rather than relying only on major kernel version numbers.