CVE-2025-38032
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.13 |
| linux | linux_kernel | 6.13 |
| linux | linux_kernel | 6.13 |
| linux | linux_kernel | 6.13 |
| linux | linux_kernel | 6.13 |
| linux | linux_kernel | 6.13 |
| linux | linux_kernel | 6.13 |
| 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-NVD-CWE-noinfo |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a flaw in the Linux kernel's ipmr (IP multicast routing) code, specifically in the ipmr_can_free_table() checks during the network namespace cleanup process. It can cause a kernel crash (splat) due to insufficient sanity checks when the CONFIG_IP_MROUTE_MULTIPLE_TABLES option is disabled. The issue arises from loose validation in the cleanup path, which has been addressed by consolidating the sanity checks into a single helper function shared between IPv4 and IPv6 code.
How can this vulnerability impact me? :
This vulnerability can cause the Linux kernel to crash unexpectedly during network namespace cleanup, potentially leading to denial of service (DoS) conditions. Such crashes can disrupt system availability and stability, affecting any services or applications relying on the affected kernel's networking features.
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 logs for kernel warnings or splats related to ipmr (IP multicast routing) netns cleanup path, specifically messages like 'WARNING: CPU: ... ipmr_free_table net/ipv4/ipmr.c:440'. Checking dmesg or journalctl logs for such warnings can help identify if the issue is occurring.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves updating the Linux kernel to a version where the vulnerability has been fixed by consolidating the ipmr_can_free_table() checks and improving sanity checks regardless of kernel configuration. Until then, monitoring for related kernel warnings and avoiding configurations that trigger the ipmr netns cleanup path may reduce risk.