CVE-2025-40153
BaseFortify
Publication date: 2025-11-12
Last updated on: 2025-11-12
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | 6.17-rc7 |
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 memory management subsystem when the mprotect() system call is used on a large hugetlb memory area (around 300GB). It causes a 'soft lockup', where a CPU gets stuck for an extended period (e.g., 23 seconds), leading to system unresponsiveness. The issue arises because the kernel does not yield the CPU during long processing loops in hugetlb memory protection changes, unlike other memory types. The fix involves adding a conditional reschedule call (cond_resched()) to prevent the CPU from being stuck.
How can this vulnerability impact me? :
This vulnerability can cause a CPU core to become unresponsive for a significant time during memory protection changes on large hugetlb memory areas, leading to system performance degradation or temporary system hangs. This can affect workloads that use large hugetlb memory allocations, potentially causing delays or interruptions in service.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for soft lockup kernel warnings related to mprotect calls on large hugetlb memory areas. Specifically, look for kernel messages like 'watchdog: BUG: soft lockup - CPU#<num> stuck for <seconds>!'. You can check kernel logs using commands such as 'dmesg | grep -i soft lockup' or 'journalctl -k | grep -i soft lockup'. Additionally, monitoring processes that call mprotect on large hugetlb memory regions (~300GB) may help identify triggering conditions.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves updating the Linux kernel to a version that includes the fix for this issue, which adds cond_resched() calls in the hugetlb mprotect path to avoid soft lockups. Until the patch is applied, avoid workloads that call mprotect() on very large hugetlb memory areas to prevent triggering the soft lockup. Monitoring and limiting the size of hugetlb memory areas used by applications can also reduce risk.