Skip to content
Fencer Vulns
medium 5.5

CVE-2026-23159 json

perf: sched: Fix perf crash with new is_user_task() helper

published 2026-02-14 8 mo ago modified 2026-06-17 4 mo ago also EUVD-2026-5878

cvss
5.5
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.1%
EPSS 0.1% chance of exploitation in 30 days, percentile 2%
public exploits
0
none known

Summary

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/20250425204120.639530125@goodmis.org/

Patch / fix

  • Linux Linux 6.6.123, 6.12.69, 6.18, 6.18.9, 6.19
  • linux Debian 13 6.12.69-1
  • linux Debian 14 6.18.9-1

debian advisories DEBIAN-CVE-2026-23159

  • linux Ubuntu 24.04 LTS 6.8.0-117.117
  • linux-aws Ubuntu 24.04 LTS 6.8.0-1055.58
  • linux-gcp Ubuntu 24.04 LTS 6.8.0-1058.61
  • linux-gke Ubuntu 24.04 LTS 6.8.0-1054.60
  • linux-ibm Ubuntu 24.04 LTS 6.8.0-1055.56
  • linux-azure Ubuntu 24.04 LTS 6.8.0-1056.62
  • linux-gkeop Ubuntu 24.04 LTS 6.8.0-1041.44
  • linux-raspi Ubuntu 24.04 LTS 6.8.0-1056.60

ubuntu advisories UBUNTU-CVE-2026-23159

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-23159 updated cvss 6.1

kernel: perf: sched: Fix perf crash with new is_user_task() helper

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more
    affected: no fix planned “Out of support scope”
  • Red Hat Enterprise Linux 10 kernel
    affected: no fix available “Fix deferred”
  • Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.13% chance of exploitation in the next 30 days, higher than 2% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
NVD 3.1 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected products

  • Linux Linux

Classification

Weakness
Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.