CVE-2026-43013

What it actually does

This is a local denial-of-service flaw in the Linux kernel Mellanox/NVIDIA mlx5 network driver LAG handling code. During mlx5 LAG initialization, the driver can continue creating debugfs entries even when no valid LAG device context exists. If a local user or process with permission to access the affected debugfs entries reads or otherwise interacts with files such as the LAG members interface, the kernel may dereference a NULL pointer. The expected result is a kernel oops or panic depending on system configuration, causing loss of availability for the affected host. The flaw does not provide a direct confidentiality or integrity impact and is not considered remotely exploitable based on the provided vector.

Why it matters to the business

A user or compromised local process on a system using affected Linux kernels with mlx5 hardware and debugfs exposure could crash the host, disrupting workloads, network services, storage traffic, virtualization hosts, or clustered systems that depend on that machine. The risk is most relevant for servers using Mellanox/NVIDIA ConnectX mlx5 adapters, especially where debugfs is mounted and accessible to non-administrative operational users or service accounts. EPSS is very low, there is no known KEV listing, and no public exploit maturity is reported, so broad active exploitation is unlikely, but the operational impact of a crash can still be high for critical infrastructure nodes.

How an attack unfolds

An attacker first needs local access to an affected Linux system and sufficient permission to interact with debugfs entries created by the mlx5 driver. The system must have the mlx5 driver in use and encounter the driver state where LAG debugfs entries are created despite the absence of a valid LAG context. The attacker then accesses a vulnerable debugfs file, such as the LAG members file, that assumes the internal LAG device pointer is valid. Because the pointer is NULL, the kernel dereferences it while servicing the file operation. This can trigger a kernel oops or panic, resulting in denial of service for the host. There is no indication from the supplied data that this vulnerability enables privilege escalation, remote code execution, data theft, or ransomware activity.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the mlx5 LAG debugfs NULL pointer dereference. The corrective change checks that mlx5_lag_dev(dev) returns a valid LAG device pointer before creating mlx5 LAG debugfs entries. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, hardware vendor, cloud image provider, or appliance vendor. If immediate patching is not possible, mitigate by restricting local shell access, limiting sudo and service-account privileges, avoiding unnecessary debugfs mounting, and ensuring /sys/kernel/debug is not accessible to untrusted users. Where operationally feasible, unload unused mlx5 modules or disable unneeded LAG/debug functionality, but validate carefully because mlx5 devices are commonly used for production networking.

How to confirm the fix worked

Confirm exposure by checking whether the system runs a kernel version identified by the vendor as affected and whether mlx5 hardware or modules are present. Validate that the patched kernel is active after remediation by checking the running kernel version, not only the installed package version. Confirm whether debugfs is mounted and whether mlx5 LAG debugfs paths are present under /sys/kernel/debug. After applying the fix, verify that the kernel package or source includes the guard that skips mlx5_ldev_add_debugfs() when mlx5_lag_dev(dev) is NULL. For production systems, avoid intentionally triggering the vulnerable debugfs access as a validation method unless performed in a controlled test environment because it may crash the host.

Typical attack path

1. Gain local access to a Linux system running an affected kernel with the mlx5 driver present or loaded.
2. Confirm that debugfs is mounted, typically under /sys/kernel/debug.
3. Identify mlx5 debugfs entries associated with LAG functionality.
4. Access a vulnerable LAG debugfs file such as the members interface when the driver has created entries without a valid LAG context.
5. Trigger a NULL pointer dereference in kernel space.
6. Cause a kernel oops or panic, leading to host instability or denial of service.

How to detect it

To determine whether exploitation may already have occurred, review kernel and system logs for oops, panic, BUG, or NULL pointer dereference messages involving mlx5, mlx5_core, LAG, debugfs, or the members file. Useful sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent pstore/ramoops records, crash dump tooling such as kdump/vmcore, and centralized EDR/SIEM telemetry for host reboots or kernel panics. Correlate crash times with local authentication logs, sudo logs, auditd file-access records, shell history where available, and process execution telemetry showing access to /sys/kernel/debug/mlx5 paths. If auditd was configured to monitor debugfs, look for read/open events against mlx5 LAG files shortly before a kernel oops or reboot. There are no known network indicators for this issue because exploitation is local and debugfs-based.

• NULL pointer dereference
• kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• mlx5_ldev_add_debugfs
• mlx5_lag_dev
• __mlx5_lag_dev_add_mdev
• mlx5_core
• net/mlx5
• /sys/kernel/debug/mlx5
• /sys/kernel/debug/mlx5/*/lag
• /sys/kernel/debug/mlx5/*/lag/members
• debugfs
• lag/members

What your security team should do

• Prioritize patching on Linux servers with Mellanox/NVIDIA mlx5 adapters, especially virtualization hosts, storage nodes, Kubernetes workers, HPC systems, and network-intensive production servers.
• Use vendor kernel advisories to identify the exact fixed package versions for each Linux distribution and ensure hosts reboot into the fixed kernel.
• Inventory systems where the mlx5_core driver is loaded and debugfs is mounted.
• Restrict access to /sys/kernel/debug to trusted administrators only and remove unnecessary debugfs mounts from production systems where feasible.
• Review local user and service-account access on affected systems because exploitation requires local privileges.
• Monitor kernel logs for NULL pointer dereferences, oops, or panic events involving mlx5 LAG/debugfs code.
• Treat unexpected crashes on mlx5-equipped systems as potentially security-relevant until kernel logs are reviewed.
• Because EPSS is low and there is no KEV listing, prioritize based on system criticality and presence of mlx5 hardware rather than internet exposure alone.