ghsa-2qfm-24x8-gwfp
Vulnerability from github
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: ? __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 ? pteoffset_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 ]---
{
"affected": [],
"aliases": [
"CVE-2025-38628"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-22T16:15:36Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvdpa/mlx5: Fix release of uninitialized resources on error path\n\nThe commit in the fixes tag made sure that mlx5_vdpa_free()\nis the single entrypoint for removing the vdpa device resources\nadded in mlx5_vdpa_dev_add(), even in the cleanup path of\nmlx5_vdpa_dev_add().\n\nThis means that all functions from mlx5_vdpa_free() should be able to\nhandle uninitialized resources. This was not the case though:\nmlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx()\nwere not able to do so. This caused the splat below when adding\na vdpa device without a MAC address.\n\nThis patch fixes these remaining issues:\n\n- Makes mlx5_vdpa_destroy_mr_resources() return early if called on\n uninitialized resources.\n\n- Moves mlx5_cmd_init_async_ctx() early on during device addition\n because it can\u0027t fail. This means that mlx5_cmd_cleanup_async_ctx()\n also can\u0027t fail. To mirror this, move the call site of\n mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free().\n\nAn additional comment was added in mlx5_vdpa_free() to document\nthe expectations of functions called from this context.\n\nSplat:\n\n mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned?\n ------------[ cut here ]------------\n WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0\n [...]\n Call Trace:\n \u003cTASK\u003e\n ? __try_to_del_timer_sync+0x61/0x90\n ? __timer_delete_sync+0x2b/0x40\n mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa]\n mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa]\n vdpa_release_dev+0x1e/0x50 [vdpa]\n device_release+0x31/0x90\n kobject_cleanup+0x37/0x130\n mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa]\n vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa]\n genl_family_rcv_msg_doit+0xd8/0x130\n genl_family_rcv_msg+0x14b/0x220\n ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa]\n genl_rcv_msg+0x47/0xa0\n ? __pfx_genl_rcv_msg+0x10/0x10\n netlink_rcv_skb+0x53/0x100\n genl_rcv+0x24/0x40\n netlink_unicast+0x27b/0x3b0\n netlink_sendmsg+0x1f7/0x430\n __sys_sendto+0x1fa/0x210\n ? ___pte_offset_map+0x17/0x160\n ? next_uptodate_folio+0x85/0x2b0\n ? percpu_counter_add_batch+0x51/0x90\n ? filemap_map_pages+0x515/0x660\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x7b/0x2c0\n ? do_read_fault+0x108/0x220\n ? do_pte_missing+0x14a/0x3e0\n ? __handle_mm_fault+0x321/0x730\n ? count_memcg_events+0x13f/0x180\n ? handle_mm_fault+0x1fb/0x2d0\n ? do_user_addr_fault+0x20c/0x700\n ? syscall_exit_work+0x104/0x140\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n RIP: 0033:0x7f0c25b0feca\n [...]\n ---[ end trace 0000000000000000 ]---",
"id": "GHSA-2qfm-24x8-gwfp",
"modified": "2025-08-22T18:31:22Z",
"published": "2025-08-22T18:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38628"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37f26b9013b46457b0a96633fc3a7dc977d8beb1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6de4ef950dd56a6a81daf92d8a1d864fc6a56971"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc51a66815999afb7e9cd845968de4fdf07567b7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf4fc23d0d3d5b89b36f0d79f2674510bb574d8e"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.