CVE-2025-21751 in Linux
Summary
by MITRE • 02/27/2025
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: HWS, change error flow on matcher disconnect
Currently, when firmware failure occurs during matcher disconnect flow, the error flow of the function reconnects the matcher back and returns an error, which continues running the calling function and eventually frees the matcher that is being disconnected. This leads to a case where we have a freed matcher on the matchers list, which in turn leads to use-after-free and eventual crash.
This patch fixes that by not trying to reconnect the matcher back when some FW command fails during disconnect.
Note that we're dealing here with FW error. We can't overcome this problem. This might lead to bad steering state (e.g. wrong connection between matchers), and will also lead to resource leakage, as it is the case with any other error handling during resource destruction.
However, the goal here is to allow the driver to continue and not crash the machine with use-after-free error.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 05/25/2026
The vulnerability identified as CVE-2025-21751 resides within the Linux kernel's mlx5 network driver, specifically addressing issues in the Hardware Steering (HWS) functionality. This flaw manifests during the matcher disconnect process when firmware failures occur, creating a critical race condition that can lead to system instability. The vulnerability operates at the intersection of hardware-software interaction and memory management, where the driver's error handling mechanism inadvertently creates a use-after-free condition that can result in system crashes. The issue stems from the driver's attempt to reconnect matchers during error recovery, which creates a temporal window where freed memory structures remain accessible, violating fundamental memory safety principles that are critical for kernel stability.
The technical implementation of this vulnerability involves the mlx5 driver's handling of firmware commands during matcher disconnection operations. When a firmware command fails during this critical phase, the current error handling logic attempts to reconnect the matcher back to the system before returning an error to the calling function. This approach creates a dangerous sequence where the matcher structure is freed by the disconnect operation but remains referenced in the matchers list due to the reconnection attempt. The underlying problem aligns with CWE-416, which describes use-after-free vulnerabilities, and the error handling mechanism fails to properly manage object lifecycle during error conditions. The driver's state management becomes inconsistent as it attempts to maintain connectivity while simultaneously processing resource cleanup, creating a scenario where freed memory structures are accessed, leading to unpredictable behavior and system crashes.
From an operational impact perspective, this vulnerability represents a significant threat to system stability in environments utilizing Mellanox ConnectX network adapters with hardware steering capabilities. The vulnerability can cause unexpected system panics and kernel oops messages, particularly in high-throughput networking scenarios where matcher operations occur frequently. Network administrators may observe sudden system crashes or kernel failures during normal operation, making this a critical issue for production environments. The vulnerability affects systems running Linux kernels with the mlx5 driver and is particularly concerning for data center and high-performance computing environments where network reliability is paramount. The resource leakage aspect of this vulnerability compounds the operational impact, as failed firmware commands can lead to accumulation of unreleased resources over time, potentially degrading system performance.
The mitigation strategy for this vulnerability focuses on preventing the problematic reconnection attempt during firmware failure scenarios, as implemented in the patch. This approach aligns with defensive programming principles and follows the principle of least privilege by ensuring that error recovery mechanisms do not introduce new failure modes. The solution involves modifying the driver's error handling to avoid reconnecting matchers when firmware commands fail during disconnect operations, thereby preventing the use-after-free condition. This fix addresses the root cause by ensuring proper object lifecycle management during error recovery, which is consistent with ATT&CK technique T1070.004 related to indicator removal and system modification. The patch effectively breaks the dangerous feedback loop where error recovery attempts create new vulnerabilities, instead allowing the driver to gracefully handle the error condition and continue operation without crashing the system. The solution maintains system stability while acknowledging that firmware errors may still result in suboptimal steering behavior and resource leaks, which are acceptable trade-offs for preventing system crashes.