CVE-2025-38551 in Linux
Summary
by MITRE • 08/16/2025
In the Linux kernel, the following vulnerability has been resolved:
virtio-net: fix recursived rtnl_lock() during probe()
The deadlock appears in a stack trace like:
virtnet_probe() rtnl_lock() virtio_config_changed_work() netdev_notify_peers() rtnl_lock()
It happens if the VMM sends a VIRTIO_NET_S_ANNOUNCE request while the virtio-net driver is still probing.
The config_work in probe() will get scheduled until virtnet_open() enables the config change notification via virtio_config_driver_enable().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 01/30/2026
The vulnerability CVE-2025-38551 represents a critical deadlock condition within the Linux kernel's virtio-net driver implementation that stems from improper locking mechanisms during device probe operations. This issue manifests as a recursive acquisition of the rtnl_lock() semaphore, creating a circular dependency that prevents the system from proceeding with normal network device initialization. The problem specifically occurs when a Virtual Machine Monitor (VMM) sends a VIRTIO_NET_S_ANNOUNCE configuration request while the virtio-net driver is in the midst of its probe phase, establishing a race condition that leads to system hang and potential denial of service.
The technical flaw resides in the driver's handling of configuration change notifications during the device probing sequence. When the virtio-net driver encounters a VIRTIO_NET_S_ANNOUNCE request from the VMM, it schedules a configuration work item that gets queued for later execution. However, this work item execution occurs before the driver has fully completed its probe phase and established proper notification mechanisms through virtio_config_driver_enable(). The recursive locking pattern emerges because the initial probe operation acquires the rtnl_lock() to register the network device, while subsequent execution of the queued configuration work triggers netdev_notify_peers() which attempts to acquire the same lock again, creating an irrecoverable deadlock scenario.
This vulnerability directly impacts the operational stability of virtualized environments where virtio-net devices are extensively used, particularly affecting cloud computing platforms, containerized applications, and virtual machine deployments that rely on dynamic network configuration changes during boot processes. The deadlock condition prevents the network interface from becoming operational, effectively rendering the virtual machine's network connectivity non-functional until the system is rebooted or the problematic configuration sequence is manually resolved. The issue is particularly dangerous in automated deployment environments where multiple virtual machines may simultaneously attempt to initialize their network interfaces, potentially causing cascading failures across entire virtualized infrastructures.
The root cause of this vulnerability aligns with CWE-362, which describes a concurrent execution of a critical section without proper synchronization mechanisms. Additionally, this flaw maps to ATT&CK technique T1489, which involves creating or enabling a denial of service condition through manipulation of system resources, as the deadlock effectively prevents normal system operation. The vulnerability demonstrates poor adherence to kernel locking protocols and improper handling of asynchronous notification mechanisms during device initialization phases. Organizations should prioritize patching affected systems immediately, as the vulnerability can be exploited by malicious actors to create persistent denial of service conditions in virtualized environments. System administrators should also monitor for unusual network initialization delays or failed network interface bring-up operations that might indicate this deadlock condition has occurred.
Mitigation strategies include applying the kernel patches that address the recursive locking behavior by ensuring proper ordering of lock acquisition and configuration notification enablement. The fix typically involves modifying the driver to defer configuration change notifications until after the probe phase completes, preventing the scheduling of work items that could trigger recursive lock acquisition. Additionally, implementing proper timeout mechanisms for device initialization sequences and monitoring for prolonged network interface setup times can help detect vulnerable conditions before they escalate into system-wide failures. Organizations should also consider implementing network configuration validation procedures that prevent VMMs from sending configuration requests during critical device initialization phases, thereby reducing the likelihood of triggering this specific deadlock scenario.