CVE-2025-38050
BaseFortify
Publication date: 2025-06-18
Last updated on: 2025-11-14
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | 6.15 |
| linux | linux_kernel | 6.15 |
| linux | linux_kernel | 6.15 |
| linux | linux_kernel | 6.15 |
| linux | linux_kernel | 6.15 |
| linux | linux_kernel | 6.15 |
| linux | linux_kernel | 6.15 |
| linux | linux_kernel | From 5.15.160 (inc) to 5.16 (inc) |
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 is a race condition in the Linux kernel's huge page memory management. Specifically, when replacing free hugetlb folios, a race between two functions can cause a NULL pointer dereference. One CPU thread may clear and free a hugetlb folio while another thread simultaneously tries to access it, leading to a NULL pointer being accessed and causing a kernel crash. The issue is fixed by adding a lock to prevent this race condition.
How can this vulnerability impact me? :
This vulnerability can cause the Linux kernel to crash due to a NULL pointer dereference. A kernel crash can lead to system instability, downtime, and potential data loss or corruption. Systems using huge pages for memory management may be particularly affected, impacting availability and reliability.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for kernel crashes or oops messages related to NULL pointer dereferences in the hugetlb subsystem. Specifically, look for kernel logs containing messages like 'BUG: kernel NULL pointer dereference' and call traces involving 'replace_free_hugepage_folios' or 'alloc_and_dissolve_hugetlb_folio'. You can check the kernel logs using commands such as 'dmesg | grep -i hugetlb' or 'journalctl -k | grep -i hugetlb'.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation is to update the Linux kernel to a version where this vulnerability is fixed, as the issue is resolved by adding proper locking (hugetlb_lock) around folio_hstate(folio) to prevent NULL pointer dereferences. Until an update is applied, avoid workloads or operations that heavily use hugetlb folios or memory allocation patterns that trigger this race condition to reduce the risk of kernel crashes.