CVE-2026-45922: RDMA/mlx5: Fix memory leak in GET_DATA_DIRECT_SYSFS_PATH handler
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix memory leak in GETDATADIRECTSYSFSPATH handler
The UVERBSHANDLER(MLX5IBMETHODGETDATADIRECTSYSFSPATH) function allocates memory for the device path using kobjectgetpath(). If the length of the device path exceeds the output buffer length, the function returns -ENOSPC but does not free the allocated memory, resulting in a memory leak.
Add a kfree() call to the error path to ensure the allocated memory is properly freed.
Compile tested only. Issue found using a prototype static analysis tool and code review.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Operational
In the Linux kernel RDMA/mlx5 driver, modify UVERBS_HANDLER(MLX5_IB_METHOD_GET_DATA_DIRECT_SYSFS_PATH) so that when kobject_get_path() allocates memory and the handler returns -ENOSPC (device path length exceeds the output buffer), the allocated memory is freed by calling kfree() on the pointer before returning.
- Operational
Rebuild (compile) the kernel with the modified RDMA/mlx5 code (compile-tested only), run validation tests, and deploy the updated kernel binary.
Event History
Frequently Asked Questions
What conditions are required to trigger the memory leak?
A local attacker or user needs low-privilege access and must invoke the MLX5 RDMA GET_DATA_DIRECT_SYSFS_PATH handler in a way that makes the device-path length exceed the provided output-buffer length. The failure path returns -ENOSPC without freeing memory allocated for the path.
What is the practical impact?
Repeatedly triggering the affected error path can leak kernel memory and exhaust available memory, causing a denial of service. The supplied CVSS vector indicates no confidentiality or integrity impact.
Is this remotely exploitable?
The provided CVSS vector lists attack vector as local and requires low privileges. No remote attack path is described.
What change fixes the issue?
The fix adds a kfree() call on the -ENOSPC error path so that the device-path memory allocated by kobject_get_path() is released. Stable kernel references are provided for the corresponding fixes.