CVE-2025-38683
BaseFortify
Publication date: 2025-09-04
Last updated on: 2025-11-03
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | kernel | 6.1.153-1 |
| linux | kernel | 5.10.244-1 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability occurs in the Linux kernel's hv_netvsc driver, where a panic happens during the deletion of a network namespace involving a Virtual Function (VF) NIC. The issue arises because when the netvsc NIC is moved back and registered to the default namespace, it automatically brings the VF NIC back as well. This causes the kernel's device exit function to fail to detect the end of the device list, leading to a NULL pointer dereference and kernel panic. The fix involves moving the namespace change operation to a workqueue and taking a lock to prevent concurrent changes to the network device list during namespace deletion.
How can this vulnerability impact me? :
This vulnerability can cause the Linux kernel to panic and crash during network namespace deletion involving VF NICs. Such a kernel panic can lead to system instability, downtime, and potential loss of network connectivity, impacting the availability and reliability of systems using the affected Linux kernel and hv_netvsc driver.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring kernel logs for panic or NULL pointer dereference messages related to hv_netvsc and VF NIC namespace movements. You can check the kernel log for messages similar to: 'BUG: kernel NULL pointer dereference' or lines mentioning 'Moved VF to namespace'. Commands such as 'dmesg | grep -i "hv_netvsc"' or 'journalctl -k | grep -i "NULL pointer dereference"' can help identify if the system has experienced this issue.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves updating the Linux kernel to a version where this vulnerability is fixed. The fix involves moving the namespace change to a workqueue and taking rtnl_lock to avoid concurrent netdev list changes during namespace deletion. Until the update is applied, avoid operations that trigger namespace deletion or VF NIC movements on netvsc devices to prevent kernel panic.