CVE-2025-39887
BaseFortify
Publication date: 2025-09-23
Last updated on: 2025-12-11
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 6.16 (inc) to 6.16.8 (exc) |
| linux | linux_kernel | 6.17 |
| linux | linux_kernel | 6.17 |
| linux | linux_kernel | 6.17 |
| linux | linux_kernel | 6.17 |
| linux | linux_kernel | 6.17 |
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 null pointer dereference in the Linux kernel's tracing/osnoise component, specifically in the bitmap_parselist() function. It occurs when a user writes to /sys/kernel/debug/tracing/osnoise/cpus with a count parameter of zero, causing kmalloc() to return a ZERO_SIZE_PTR which is incorrectly treated as a valid pointer. This leads to a kernel crash (NULL pointer dereference). The issue was fixed by adding a check for the count parameter to prevent this condition.
How can this vulnerability impact me? :
This vulnerability can cause the Linux kernel to crash due to a NULL pointer dereference when the affected function is triggered. This can lead to system instability or denial of service, as the kernel may panic or become unresponsive.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by checking for kernel crash logs indicating a NULL pointer dereference in bitmap_parselist(), specifically looking for messages like 'BUG: kernel NULL pointer dereference, address: 0000000000000010' and call traces involving osnoise_cpus_write. You can also attempt to reproduce the issue by running commands that write to /sys/kernel/debug/tracing/osnoise/cpus with a zero count parameter, for example: 1) fd=$(sudo sh -c 'echo $$'); 2) sudo sh -c 'echo "0-2" > /sys/kernel/debug/tracing/osnoise/cpus' (Note: this may cause a kernel crash if vulnerable). Monitoring kernel logs with 'dmesg' or 'journalctl -k' for related Oops messages can help detect exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include updating the Linux kernel to a version where the vulnerability is fixed (post 6.17.0-rc4-00201-gd69eb204c255). Until then, avoid writing to /sys/kernel/debug/tracing/osnoise/cpus with a zero count parameter or untrusted input. Restrict access to the tracing subsystem to trusted users only to prevent exploitation. Monitoring and restricting usage of the osnoise tracing interface can reduce risk.