CVE-2026-23311
published 2026-03-25CVE-2026-23311: In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix invalid wait context in ctx_sched_in() Lockdep found a bug in the event…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.09%
0.7th percentile
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix invalid wait context in ctx_sched_in()
Lockdep found a bug in the event scheduling when a pinned event was
failed and wakes up the threads in the ring buffer like below.
It seems it should not grab a wait-queue lock under perf-context lock.
Let's do it with irq_work.
[ 39.913691] =============================
[ 39.914157] [ BUG: Invalid wait context ]
[ 39.914623] 6.15.0-next-20250530-next-2025053 #1 Not tainted
[ 39.915271] -----------------------------
[ 39.915731] repro/837 is trying to lock:
[ 39.916191] ffff88801acfabd8 (&event->waitq){....}-{3:3}, at: __wake_up+0x26/0x60
[ 39.917182] other info that might help us debug this:
[ 39.917761] context-{5:5}
[ 39.918079] 4 locks held by repro/837:
[ 39.918530] #0: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: __perf_event_task_sched_in+0xd1/0xbc0
[ 39.919612] #1: ffff88806ca3c6f8 (&cpuctx_lock){....}-{2:2}, at: __perf_event_task_sched_in+0x1a7/0xbc0
[ 39.920748] #2: ffff88800d91fc18 (&ctx->lock){....}-{2:2}, at: __perf_event_task_sched_in+0x1f9/0xbc0
[ 39.921819] #3: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: perf_event_wakeup+0x6c/0x470
Affected
11 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.19.8-1 (forky) | linux 6.19.8-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= f4b07fd62d4d11d57a15cb4ae01b3833282eb8f6 < c67ab059953e3b66cb17ddd6524c23f9e1f6526d | c67ab059953e3b66cb17ddd6524c23f9e1f6526d |
| linux | linux | >= f4b07fd62d4d11d57a15cb4ae01b3833282eb8f6 < 825f218ca70ef394c2b8546b313711d867b24584 | 825f218ca70ef394c2b8546b313711d867b24584 |
| linux | linux | >= f4b07fd62d4d11d57a15cb4ae01b3833282eb8f6 < 486ff5ad49bc50315bcaf6d45f04a33ef0a45ced | 486ff5ad49bc50315bcaf6d45f04a33ef0a45ced |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.19.8-1 | 6.19.8-1 |
| linux | linux_kernel | >= 6.15 < 6.18.17 | 6.18.17 |
| linux | linux_kernel | >= 6.15.0 < 6.18.17 | 6.18.17 |
| linux | linux_kernel | >= 6.19 < 6.19.7 | 6.19.7 |
| linux | linux_kernel | >= 6.19.0 < 6.19.7 | 6.19.7 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vendor_redhat5.5LOW
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: perf/core: Fix invalid wait context in ctx_sched_in()
vendor_redhat·2026-03-25·CVSS 5.5
CVE-2026-23311 [LOW] CWE-413 kernel: perf/core: Fix invalid wait context in ctx_sched_in()
kernel: perf/core: Fix invalid wait context in ctx_sched_in()
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix invalid wait context in ctx_sched_in()
Lockdep found a bug in the event scheduling when a pinned event was
failed and wakes up the threads in the ring buffer like below.
It seems it should not grab a wait-queue lock under perf-context lock.
Let's do it with irq_work.
[ 39.913691] =============================
[ 39.914157] [ BUG: Invalid wait context ]
[ 39.914623] 6.15.0-next-20250530-next-2025053 #1 Not tainted
[ 39.915271] -----------------------------
[ 39.915731] repro/837 is trying to lock:
[ 39.916191] ffff88801acfabd8 (&event->waitq){....}-{3:3}, at: __wake_up+0x26/0x60
[ 39.917182] other info that might help us debug this:
[ 39.917761] co
Debian
CVE-2026-23311: linux - In the Linux kernel, the following vulnerability has been resolved: perf/core: ...
vendor_debian·2026
CVE-2026-23311 [LOW] CVE-2026-23311: linux - In the Linux kernel, the following vulnerability has been resolved: perf/core: ...
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix invalid wait context in ctx_sched_in() Lockdep found a bug in the event scheduling when a pinned event was failed and wakes up the threads in the ring buffer like below. It seems it should not grab a wait-queue lock under perf-context lock. Let's do it with irq_work. [ 39.913691] ============================= [ 39.914157] [ BUG: Invalid wait context ] [ 39.914623] 6.15.0-next-20250530-next-2025053 #1 Not tainted [ 39.915271] ----------------------------- [ 39.915731] repro/837 is trying to lock: [ 39.916191] ffff88801acfabd8 (&event->waitq){....}-{3:3}, at: __wake_up+0x26/0x60 [ 39.917182] other info that might help us debug this: [ 39.917761] context-{5:5} [ 39.918079] 4 locks held by repro/837: [ 39.918530
VulDB
Linux Kernel up to 6.18.16/6.19.6/7.0-rc1 perf ctx_sched_in buffer overflow (Nessus ID 303739 / WID-SEC-2026-0861)
vuldb·2026-05-27·CVSS 5.5
CVE-2026-23311 [MEDIUM] Linux Kernel up to 6.18.16/6.19.6/7.0-rc1 perf ctx_sched_in buffer overflow (Nessus ID 303739 / WID-SEC-2026-0861)
A vulnerability was found in Linux Kernel up to 6.18.16/6.19.6/7.0-rc1 and classified as critical. This vulnerability affects the function ctx_sched_in of the component perf. The manipulation results in buffer overflow.
This vulnerability is known as CVE-2026-23311. Access to the local network is required for this attack. No exploit is available.
It is suggested to upgrade the affected component.
GHSA
GHSA-h7wr-qv5c-937x: In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix invalid wait context in ctx_sched_in()
Lockdep found a bug in the
ghsa_unreviewed·2026-03-25
CVE-2026-23311 GHSA-h7wr-qv5c-937x: In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix invalid wait context in ctx_sched_in()
Lockdep found a bug in the
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix invalid wait context in ctx_sched_in()
Lockdep found a bug in the event scheduling when a pinned event was
failed and wakes up the threads in the ring buffer like below.
It seems it should not grab a wait-queue lock under perf-context lock.
Let's do it with irq_work.
[ 39.913691] =============================
[ 39.914157] [ BUG: Invalid wait context ]
[ 39.914623] 6.15.0-next-20250530-next-2025053 #1 Not tainted
[ 39.915271] -----------------------------
[ 39.915731] repro/837 is trying to lock:
[ 39.916191] ffff88801acfabd8 (&event->waitq){....}-{3:3}, at: __wake_up+0x26/0x60
[ 39.917182] other info that might help us debug this:
[ 39.917761] context-{5:5}
[ 39.918079] 4 locks held by repro/837:
[ 39.91
OSV
perf/core: Fix invalid wait context in ctx_sched_in()
osv·2026-03-25
CVE-2026-23311 perf/core: Fix invalid wait context in ctx_sched_in()
perf/core: Fix invalid wait context in ctx_sched_in()
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix invalid wait context in ctx_sched_in()
Lockdep found a bug in the event scheduling when a pinned event was
failed and wakes up the threads in the ring buffer like below.
It seems it should not grab a wait-queue lock under perf-context lock.
Let's do it with irq_work.
[ 39.913691] =============================
[ 39.914157] [ BUG: Invalid wait context ]
[ 39.914623] 6.15.0-next-20250530-next-2025053 #1 Not tainted
[ 39.915271] -----------------------------
[ 39.915731] repro/837 is trying to lock:
[ 39.916191] ffff88801acfabd8 (&event->waitq){....}-{3:3}, at: __wake_up+0x26/0x60
[ 39.917182] other info that might help us debug this:
[ 39.917761] contex
OSV
CVE-2026-23311: In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix invalid wait context in ctx_sched_in() Lockdep found a bug in the e
osv·2026-03-25
CVE-2026-23311 CVE-2026-23311: In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix invalid wait context in ctx_sched_in() Lockdep found a bug in the e
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix invalid wait context in ctx_sched_in() Lockdep found a bug in the event scheduling when a pinned event was failed and wakes up the threads in the ring buffer like below. It seems it should not grab a wait-queue lock under perf-context lock. Let's do it with irq_work. [ 39.913691] ============================= [ 39.914157] [ BUG: Invalid wait context ] [ 39.914623] 6.15.0-next-20250530-next-2025053 #1 Not tainted [ 39.915271] ----------------------------- [ 39.915731] repro/837 is trying to lock: [ 39.916191] ffff88801acfabd8 (&event->waitq){....}-{3:3}, at: __wake_up+0x26/0x60 [ 39.917182] other info that might help us debug this: [ 39.917761] context-{5:5} [ 39.918079] 4 locks held by repro/837: [ 39.918530
No detection rules found.
No public exploits indexed.
2026-03-25
Published