Cloudanix VulnDB

CVE-2025-38628

None

CVSS

—

EPSS

0.2%

Published

Aug 22, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Linux kernel bug could cause warnings or instability when setting up certain virtual network devices on specific hardware if configuration is incomplete.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Other
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Improper cleanup of partially initialized vdpa resources in mlx5 driver allows mlx5_vdpa_destroy_mr_resources and mlx5_cmd_cleanup_async_ctx to be called on uninitialized state, triggering warnings and workqueue flush failures during device release on error paths such as missing MAC address.

Why it matters to the business

Administrators may encounter kernel warnings or instability when provisioning vdpa devices on mlx5 hardware without complete configuration, increasing operational risk for virtualized networking setups; prevalence in Linux kernel deployments heightens exposure across server and cloud environments.

How an attack unfolds

An attacker with privileges to add vdpa devices via netlink triggers the mlx5_vdpa_dev_add error path (no MAC provisioned), causing mlx5_vdpa_free to invoke unhandled cleanup functions that produce the workqueue splat; unrelated actors such as VMSCAPE have targeted similar Linux kernel privilege issues but this flaw is not known for active exploitation.

How to fix it

Update to fixed Linux kernel commit 37f26b9013b46457b0a96633fc3a7dc977d8beb1 or later; for listed packages apply the specified fixed versions such as openjdk-17-openj9 0.53.0-r0 where applicable; ensure vdpa device addition always supplies required parameters to avoid error paths.

How to confirm the fix worked

Confirm kernel version contains the referenced commit; attempt vdpa device addition without MAC address and verify absence of the workqueue warning and splat; review mlx5_vdpa_free for early-return guards and reordered async ctx cleanup.

Typical attack path

  1. Obtain capability to issue vdpa_nl_cmd_dev_add_set_doit netlink commands
  2. Request addition of mlx5 vdpa device without supplying a MAC address
  3. Trigger error path in mlx5_vdpa_dev_add leading to vdpa_release_dev
  4. Observe warning and potential system impact from uninitialized resource cleanup

How to detect it

Search kernel logs for the exact warning string 'warning: No mac address provisioned?' combined with call traces referencing mlx5_vdpa_destroy_mr_resources and __flush_work; inspect netlink activity leading to vdpa_nl_cmd_dev_add_set_doit around device addition failures.

  • mlx5_vdpa_dev_add:3950:(pid
  • warning: No mac address provisioned?
  • mlx5_vdpa_destroy_mr_resources+0x1c/0x40
  • vdpa_nl_cmd_dev_add_set_doit

What your security team should do

  • Prioritize kernel upgrades on systems using mlx5 vdpa devices given 431 days since publication
  • Audit vdpa configuration scripts to always provide MAC addresses
  • Monitor EPSS trend and re-evaluate if score increases
  • Test error-path behavior in staging before production rollout

The record

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 ]---

Affected packages

Ecosystem Package Introduced Fixed
Debian:13 linux 0 No fix
Debian:14 linux 0 No fix
Debian:14 linux 0 6.16.3-1
Linux Kernel 6.12.0 6.12.42
SUSE:Linux Enterprise Live Patching 15 SP7 kernel-livepatch-SLE15-SP7-RT_Update_5 0 1-150700.1.3.1
SUSE:Real Time Module 15 SP7 kernel-rt 0 6.4.0-150700.7.19.1
SUSE:Real Time Module 15 SP7 kernel-source-rt 0 6.4.0-150700.7.19.1
SUSE:Real Time Module 15 SP7 kernel-syms-rt 0 6.4.0-150700.7.19.1
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.6.1.160000.2.4
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.6.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.6.1

Related vulnerabilities