A bug in the Linux kernel’s mlx5 driver, used by Mellanox/NVIDIA network cards, can turn a routine hardware interrupt allocation failure into a full system crash. The flaw, tracked as CVE-2025-40250, has been fixed upstream, and system administrators should patch immediately if they rely on affected hardware.

What changed in the mlx5 driver

The vulnerability lives in the mlx5_irq_alloc function, which manages interrupt request (IRQ) mappings for the driver. When the kernel tries to allocate an IRQ for the device and fails—for example, because all available IRQ vectors are already in use—the driver must clean up any partial state it created. In affected versions, the cleanup code overreacted: instead of removing only the mapping that failed, it tore down the entire IRQ mapping table, or “rmap.” This left other threads with dangling pointers into freed memory, leading to general protection faults and kernel crashes.

Symptomatically, the crash appears as a failure to request an IRQ (often with error code -28, ENOSPC) followed immediately by a general protection fault in functions like free_irq_cpu_rmap. The fix, backported to stable kernels, ensures the cleanup removes only the newly added IRQ glue, not existing mappings. No configuration or user action triggers the bug other than exhausting IRQ vectors—something that can happen under normal high-load conditions, especially when features like fwctl and rds are enabled in the driver.

What this means for you

For home users and enthusiasts

If you run a Linux desktop or homelab server with a Mellanox ConnectX NIC pulling IRQ vectors, you are vulnerable only if the system is under extreme vector pressure. Most home setups will never hit the failure condition. Still, if you’ve experienced unexplained kernel panics after moving heavy traffic or re-plugging devices, this patch may resolve them.

For system administrators and DevOps engineers

Production servers—especially virtualization hosts, high-performance computing clusters, and any multi-tenant machines using RDMA over Converged Ethernet (RoCE) or InfiniBand—should treat this as a high-priority patch. A single failed IRQ request can bring down an entire node, and in automated environments, cascading failures are a real risk. Red Hat, SUSE, Ubuntu, and others have already begun shipping fixed kernels; check your vendor’s security advisory for the exact package version.

For developers and kernel contributors

This bug offers a textbook example of why error paths must be surgical. The faulty cleanup logic was introduced in a commit that attempted to simplify resource tracking but neglected thread-safety and invalidation concerns. Reviewing failure-handling code under the lens of concurrent access remains one of the hardest kernel-engineering challenges, and this CVE serves as a reminder that even small convenience functions can harbor severe flaws.

How we got here

The mlx5 driver has a long history of handling complex IRQ allocation for high-performance devices. The allocation function, mlx5_irq_alloc, uses a multi-step process: prepare glue objects, call request_irq to bind a handler to a vector, and if successful, add the mapping to the rmap. The bug appeared when a commit (not publicly identified in advisories but tracked in kernel Git logs) attempted to unify failed-allocation cleanup by removing the entire rmap. However, that assumption was wrong—other mappings in the table are still active and in use by other components. The overzealous cleanup created a use-after-free scenario prone to panics.

Linux distribution security teams and kernel maintainers worked quickly to identify the problematic code and merge a minimal fix into the mainline and stable trees. The vulnerability was assigned CVE-2025-40250, and the fix has been available since late August 2025 in upstream kernels. As of this writing, no public exploits or active attacks have been documented, but the consensus among kernel developers is that local denial-of-service is trivial to trigger given sufficient vector exhaustion.

What to do now

1. Determine if you are affected

  • Check whether you have a Mellanox/NVIDIA mlx5-based network adapter. Use lspci | grep -i mellanox or ethtool -i <interface> and look for mlx5_core in the driver field.
  • Verify your kernel version. Vulnerable kernels include those that contain the problematic commit. While no definitive commit list is provided in this advisory, vendors are publishing kernel versions that contain the fix. For example, Ubuntu’s USN-XXXX, Red Hat’s RHSA-XXXX, and SUSE’s SUSE-SU-XXXX (check your vendor’s latest security update).
  • If you run a custom or vendor-forked kernel, contact your supplier or check the changelog for backports of the mlx5: fix cleanup on failed irq alloc patch.

2. Apply the patch

  • For most users, updating your kernel package through your distribution’s package manager is sufficient. After updating, reboot into the new kernel.
  • If you compile your own kernel, ensure you pull the latest stable/longterm tree (5.15.y, 6.1.y, 6.6.y, etc.) where the fix is present.
  • For containerized or immutable deployments (e.g., CoreOS, Flatcar), the host kernel must be updated separately; restart nodes according to your cluster’s rolling update procedure.

3. Verify the fix

  • After rebooting, you can run a stress test that involves heavy network traffic and device resets to see if previous panics reproduce. The absence of oopses and the Failed to request irq. err = -28 message is a good sign.
  • Inspect the kernel package changelog (e.g., rpm -q --changelog kernel or dpkg -l linux-image-*) for mention of CVE-2025-40250 or the specific commit hash.
  • Continue monitoring system logs (dmesg or journalctl -k) for at least a week for any regression, especially around IRQ allocation failures.

4. Short-term mitigations if you can’t patch immediately

  • Reduce concurrent network device activity to lower IRQ pressure. Disable features like SR-IOV or RDMA if not strictly necessary until patched.
  • Restrict local access to production hosts. Since the bug requires local code execution (or a service triggering a driver reload), limiting shell access and container workloads reduces risk.
  • Move critical workloads to servers without Mellanox hardware or to already-patched nodes if possible.

Outlook

While the immediate danger is limited to local denial-of-service, the disruption from unplanned reboots in production environments is not to be underestimated. Distributions will continue to integrate the fix into their stable kernels, and embedded or appliance vendors may take longer. Expect follow-up advisories from networking hardware vendors who ship branded Linux systems.

No follow-on exploits leveraging this flaw for privilege escalation or remote code execution are currently known, but the kernel’s attack surface is large, and chaining a local crash primitive with another vulnerability is always a possibility. Administrators should treat kernel crashes as a potential indicator of deeper issues and prioritize patch deployment.

The fix for CVE-2025-40250 is a tidy example of kernel maintainers doing what they do best: isolating a small, low-risk code change that restores correctness. The lesson for anyone operating Linux systems in anger: error paths matter, and even obscure driver code can lead to outsized operational headaches when left unpatched.