CVE-2026-46016

What it actually does

This is a Linux kernel denial-of-service flaw in the Xilinx remoteproc receive callback. When the Xilinx remoteproc/IPI path handles an unexpected NULL message, vulnerable kernels may dereference the NULL pointer instead of validating it first. On affected systems, a local low-privileged attacker or faulty local component able to exercise the relevant remoteproc/IPI interface may trigger a kernel oops or panic, causing loss of availability. The vulnerability does not directly provide confidentiality or integrity impact, and exploitation requires local access with some privilege.

Why it matters to the business

Successful exploitation can crash affected Linux systems, disrupting embedded, edge, industrial, telecom, or appliance workloads that rely on Xilinx remote processor support. The primary risk is operational downtime rather than data theft. Current public risk signals are low: EPSS is very low, there is no known CISA KEV listing, no ransomware association, and no reported exploit maturity, but organizations using Linux on Xilinx platforms should still patch during normal kernel maintenance because kernel crashes can affect safety, availability, and service continuity.

How an attack unfolds

An attacker first needs local access to a system running a vulnerable Linux kernel with the Xilinx remoteproc driver and relevant IPI/mailbox functionality present. The attacker then interacts with local interfaces or workloads that can cause the remoteproc receive callback to process an IPI message state where the message pointer is NULL. In the vulnerable code path, the driver accesses buffer or message information without first confirming that the IPI path is buffered and that the message pointer is valid. This results in a NULL pointer dereference in kernel context. Depending on kernel panic settings and system configuration, the result may be a kernel oops, remoteproc subsystem failure, or full system panic/reboot. There is no indication that this flaw enables code execution or privilege escalation by itself.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the Xilinx remoteproc receive callback, specifically the change that only accesses buffer information when IPI is buffered and validates NULL messages before dereferencing them. No exact fixed version was provided in the input, so use the applicable Linux distribution, SoC vendor, board vendor, or appliance vendor advisory to identify the corrected kernel package. If immediate patching is not possible, reduce exposure by disabling unused Xilinx remoteproc functionality, unloading or blacklisting the affected driver where operationally safe, restricting local shell and device access, limiting access to remoteproc/sysfs/debugfs interfaces, and applying kernel panic/reboot monitoring to restore service quickly after a crash. Mitigations should be tested carefully on embedded platforms because disabling remoteproc may disrupt coprocessor or firmware-dependent functions.

How to confirm the fix worked

Confirm that deployed kernels include the patch for the Xilinx remoteproc NULL message validation issue. Validate through vendor package metadata, kernel changelogs, source inspection, or advisory mapping rather than relying only on the base kernel version, because vendors frequently backport fixes. On systems where source or debug symbols are available, verify that the Xilinx remoteproc receive callback checks for a NULL message and only accesses buffer metadata when the IPI is buffered. Inventory whether the affected functionality is present by checking kernel configuration and loaded modules for remoteproc and Xilinx remoteproc support. After patching, reboot into the corrected kernel and confirm the running kernel version with standard OS tooling. Avoid destructive proof-of-concept testing on production systems; if validation by triggering the condition is required, perform it only in an isolated test environment and confirm that the system no longer oopses or panics when the NULL-message path is exercised.

Typical attack path

1. Identify a Linux system using Xilinx remoteproc support, typically on Xilinx/Zynq/ZynqMP-style platforms or derivative embedded appliances.
2. Obtain local access with sufficient privileges to interact with the relevant remoteproc, mailbox, or device interfaces.
3. Trigger an IPI receive path where the callback receives a NULL message or an unbuffered IPI condition.
4. Cause the vulnerable kernel code to dereference the NULL message pointer.
5. Induce a kernel oops, panic, reboot, or service-impacting remoteproc failure, resulting in denial of service.

How to detect it

This issue causes availability impact rather than leaving a reliable compromise artifact. To determine whether it may have been exploited, review kernel logs, persistent journal data, serial console logs, crash dumps, watchdog reset records, and hardware management logs for kernel NULL pointer dereference events involving Xilinx remoteproc, remoteproc, mailbox, or IPI handling. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k output, pstore/ramoops records, kdump/vmcore data, embedded device serial console captures, and appliance watchdog reboot logs. Look for sudden reboots or kernel panics preceded by remoteproc or Xilinx driver messages, especially when correlated with local user sessions, commands interacting with sysfs/debugfs/device nodes, or repeated crashes at similar times. Because this vulnerability is local and currently has no known public exploit maturity, detection should focus on crash forensics and abuse of local access rather than network indicators.

• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops: 0000
• remoteproc
• xlnx
• xlnx_remoteproc
• xlnx_r5_remoteproc
• zynqmp_r5_remoteproc
• IPI
• mailbox
• /sys/class/remoteproc
• /sys/kernel/debug/remoteproc
• /proc/vmcore
• /sys/fs/pstore

What your security team should do

• Prioritize patching affected Linux kernels on Xilinx-based embedded, edge, industrial, and appliance systems during the next maintenance window.
• Inventory systems with Linux remoteproc and Xilinx remoteproc support enabled, including vendor appliances where kernel details may be abstracted.
• Use vendor or distribution advisories to identify the fixed kernel package because exact fixed versions were not provided.
• Where patching is delayed, restrict local access and access to device, sysfs, and debugfs interfaces that could exercise remoteproc functionality.
• Disable or remove unused Xilinx remoteproc components only after confirming that business-critical coprocessor, firmware, or real-time functions do not depend on them.
• Monitor kernel logs and crash telemetry for NULL pointer dereference, kernel oops, panic, or remoteproc-related failures on affected platforms.
• Treat repeated local crash attempts as suspicious activity even though this issue is currently low EPSS, not KEV-listed, and has no known mature public exploit.