CVE-2025-38628 in Linux
Summary
by MITRE • 08/22/2025
In the Linux kernel, the following vulnerability has been resolved:
vdpa/mlx5: Fix release of uninitialized resources on error path
The commit in the fixes tag made sure that mlx5_vdpa_free() is the single entrypoint for removing the vdpa device resources added in mlx5_vdpa_dev_add(), even in the cleanup path of mlx5_vdpa_dev_add().
This means that all functions from mlx5_vdpa_free() should be able to handle uninitialized resources. This was not the case though: mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx() were not able to do so. This caused the splat below when adding a vdpa device without a MAC address.
This patch fixes these remaining issues:
- Makes mlx5_vdpa_destroy_mr_resources() return early if called on uninitialized resources.
- Moves mlx5_cmd_init_async_ctx() early on during device addition because it can't fail. This means that mlx5_cmd_cleanup_async_ctx() also can't fail. To mirror this, move the call site of mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free().
An additional comment was added in mlx5_vdpa_free() to document the expectations of functions called from this context.
Splat:
mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned? ------------[ cut here ]------------
WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0 [...]
Call Trace: <TASK> ? __try_to_del_timer_sync+0x61/0x90 ? __timer_delete_sync+0x2b/0x40 mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa]
mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa]
vdpa_release_dev+0x1e/0x50 [vdpa]
device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa]
vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa]
genl_family_rcv_msg_doit+0xd8/0x130 genl_family_rcv_msg+0x14b/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa]
genl_rcv_msg+0x47/0xa0 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x27b/0x3b0 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x1fa/0x210 ? ___pte_offset_map+0x17/0x160 ? next_uptodate_folio+0x85/0x2b0 ? percpu_counter_add_batch+0x51/0x90 ? filemap_map_pages+0x515/0x660 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x7b/0x2c0 ? do_read_fault+0x108/0x220 ? do_pte_missing+0x14a/0x3e0 ? __handle_mm_fault+0x321/0x730 ? count_memcg_events+0x13f/0x180 ? handle_mm_fault+0x1fb/0x2d0 ? do_user_addr_fault+0x20c/0x700 ? syscall_exit_work+0x104/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0c25b0feca [...]
---[ end trace 0000000000000000 ]---
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 05/28/2026
The vulnerability described in CVE-2025-38628 resides within the Linux kernel's mlx5_vdpa driver, specifically concerning resource management during the initialization and cleanup of virtual data path acceleration devices. This flaw manifests when a vdpa device is added without a MAC address, leading to a kernel panic due to improper handling of uninitialized resources during error paths. The issue stems from the mlx5_vdpa_dev_add() function not consistently ensuring that all cleanup functions, particularly mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx(), can gracefully handle uninitialized or partially initialized components. The root cause lies in the driver's failure to establish a consistent resource lifecycle management protocol, where cleanup functions are invoked without proper initialization checks, resulting in invalid memory access patterns that trigger kernel warnings and ultimately system instability.
The technical implementation of this vulnerability is rooted in improper resource lifecycle management within the mlx5_vdpa subsystem. During device addition, the mlx5_vdpa_dev_add() function orchestrates multiple initialization steps including memory registration and command context setup. However, when an error occurs before all resources are properly initialized, the cleanup path fails because mlx5_vdpa_destroy_mr_resources() attempts to operate on structures that may not have been fully constructed. This directly violates the principle of defensive programming and proper error handling, as outlined in CWE-459, which deals with incomplete cleanup. The function mlx5_cmd_cleanup_async_ctx() also encounters similar issues because it is called in a context where the underlying asynchronous command context may not have been properly initialized, leading to attempts to clean up invalid kernel objects.
The operational impact of this vulnerability extends beyond simple system instability, presenting a potential denial-of-service condition that could affect virtualized environments relying on Mellanox hardware for data path acceleration. When triggered, the kernel panic results in a system crash, requiring manual intervention to restore normal operations. The vulnerability affects systems using the mlx5_vdpa driver in virtualization scenarios where devices are dynamically added through the vDPA subsystem. This aligns with ATT&CK technique T1489, which covers denial of service attacks, and specifically targets the kernel's device management subsystem. The vulnerability is particularly concerning in cloud and containerized environments where dynamic device provisioning is common, as it could be exploited to cause service disruptions or system instability.
Mitigation strategies for this vulnerability require patching the kernel to implement proper resource initialization checks and ensure consistent cleanup behavior. The fix implemented in the patch ensures that mlx5_vdpa_destroy_mr_resources() returns early when called on uninitialized resources, preventing invalid memory access patterns. Additionally, the patch restructures the initialization sequence by moving mlx5_cmd_init_async_ctx() to occur early during device addition, guaranteeing its successful completion before any cleanup attempts. This approach aligns with secure coding practices and follows the principle of fail-fast, where initialization failures are detected and handled gracefully. System administrators should prioritize applying the kernel patch to affected systems and monitor for any unusual behavior in virtualized environments that utilize Mellanox hardware for vDPA functionality. The fix also includes documentation updates within mlx5_vdpa_free() to clarify the expected behavior of functions called from this cleanup context, improving maintainability and reducing the likelihood of similar issues in future modifications.