CVE-2026-23159
Unknown Unknown - Not Provided
Null Pointer Dereference in Linux perf Causing Crash

Publication date: 2026-02-14

Last updated on: 2026-03-18

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: perf: sched: Fix perf crash with new is_user_task() helper In order to do a user space stacktrace the current task needs to be a user task that has executed in user space. It use to be possible to test if a task is a user task or not by simply checking the task_struct mm field. If it was non NULL, it was a user task and if not it was a kernel task. But things have changed over time, and some kernel tasks now have their own mm field. An idea was made to instead test PF_KTHREAD and two functions were used to wrap this check in case it became more complex to test if a task was a user task or not[1]. But this was rejected and the C code simply checked the PF_KTHREAD directly. It was later found that not all kernel threads set PF_KTHREAD. The io-uring helpers instead set PF_USER_WORKER and this needed to be added as well. But checking the flags is still not enough. There's a very small window when a task exits that it frees its mm field and it is set back to NULL. If perf were to trigger at this moment, the flags test would say its a user space task but when perf would read the mm field it would crash with at NULL pointer dereference. Now there are flags that can be used to test if a task is exiting, but they are set in areas that perf may still want to profile the user space task (to see where it exited). The only real test is to check both the flags and the mm field. Instead of making this modification in every location, create a new is_user_task() helper function that does all the tests needed to know if it is safe to read the user space memory or not. [1] https://lore.kernel.org/all/[email protected]/
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-14
Last Modified
2026-03-18
Generated
2026-05-27
AI Q&A
2026-02-14
EPSS Evaluated
2026-05-25
NVD
EUVD
Affected Vendors & Products
Showing 10 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel 6.19
linux linux_kernel From 6.12.57 (inc) to 6.12.69 (exc)
linux linux_kernel From 6.17.7 (inc) to 6.18.9 (exc)
linux linux_kernel From 6.6.116 (inc) to 6.6.123 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
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 involves the Linux kernel's perf tool crashing due to an incorrect method of determining whether a task is a user task or a kernel task.

Originally, the kernel checked if a task was a user task by verifying if the task_struct mm field was non-NULL. However, some kernel tasks now have their own mm field, making this check unreliable.

Attempts to fix this by checking task flags like PF_KTHREAD were incomplete because not all kernel threads set PF_KTHREAD; some use PF_USER_WORKER instead.

Additionally, there is a small window when a task exits where its mm field is freed and set to NULL, which can cause perf to crash with a NULL pointer dereference if it tries to read the mm field at that moment.

The fix was to create a new helper function, is_user_task(), that performs all necessary checks on both flags and the mm field to safely determine if it is a user task and avoid crashes.


How can this vulnerability impact me? :

This vulnerability can cause the perf tool in the Linux kernel to crash unexpectedly due to a NULL pointer dereference when profiling tasks.

If you rely on perf for performance monitoring or debugging, this crash could interrupt your profiling activities, potentially leading to loss of diagnostic data or system instability during profiling.

However, this issue does not directly affect the security or integrity of the system beyond causing perf to crash.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


What immediate steps should I take to mitigate this vulnerability?

I don't know


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart