CVE-2025-38035
BaseFortify
Publication date: 2025-06-18
Last updated on: 2025-12-17
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 5.0 (inc) to 5.4.294 (exc) |
| linux | linux_kernel | From 5.5 (inc) to 5.10.238 (exc) |
| linux | linux_kernel | From 5.11 (inc) to 5.15.185 (exc) |
| linux | linux_kernel | From 5.16 (inc) to 6.1.141 (exc) |
| linux | linux_kernel | From 6.2 (inc) to 6.6.93 (exc) |
| linux | linux_kernel | From 6.7 (inc) to 6.12.31 (exc) |
| linux | linux_kernel | From 6.13 (inc) to 6.14.9 (exc) |
| linux | linux_kernel | 6.15 |
| linux | linux_kernel | 6.15 |
| linux | linux_kernel | 6.15 |
| linux | linux_kernel | 6.15 |
| debian | debian_linux | 11.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-476 | The product dereferences a pointer that it expects to be valid but is NULL. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in the Linux kernel's nvmet-tcp component involves improper handling of the state_change callback for TCP connections. Specifically, if the TCP connection is not established when nvmet_tcp_set_queue_sock() is called, the queue->state_change is not set, and the sock->sk->sk_state_change callback is not replaced. Attempting to restore this callback when queue->state_change is NULL can lead to a NULL pointer dereference, causing a kernel crash (BUG). The fix avoids restoring the callback if queue->state_change is NULL, preventing such NULL pointer dereferences.
How can this vulnerability impact me? :
This vulnerability can cause a kernel NULL pointer dereference leading to a system crash or kernel panic. This can result in denial of service (DoS) conditions on affected systems running the vulnerable Linux kernel, potentially disrupting services and requiring system reboots.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring the system kernel logs for NULL pointer dereference errors related to nvmet-tcp, such as messages containing 'BUG: kernel NULL pointer dereference' and stack traces involving nvmet_tcp_set_queue_sock or tcp_fin. You can use commands like 'dmesg | grep -i nvmet' or 'journalctl -k | grep -i null' to look for such kernel oops or crash messages.
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, as the issue is resolved by a patch that avoids restoring a null sk_state_change pointer. Until an update is applied, monitoring for kernel crashes and avoiding use of affected nvmet-tcp functionality may reduce risk.