CVE-2026-98530: kprobes: Fix permanent hang when flushing the kprobe optimizer

Published Oct 18, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

kprobes: Fix permanent hang when flushing the kprobe optimizer

Writing 0 to /proc/sys/debug/kprobes-optimization while a kprobe is jump-optimized never returns. The writer sleeps in D state forever with kprobesysctlmutex held, so any later read or write of that sysctl hangs as well. For example, with vfsread+9 as an optimizable address in this build:

# cd /sys/kernel/tracing # echo 'p:myprobe vfsread+9' >> kprobeevents # echo 1 > events/kprobes/myprobe/enable # # wait until /sys/kernel/debug/kprobes/list shows [OPTIMIZED] # echo 0 > /proc/sys/debug/kprobes-optimization

INFO: task sh:246 blocked for more than 10 seconds. Call Trace: <TASK> schedule+0x1176/0x4f70 schedule+0xdc/0x2c0 scheduletimeout+0x17b/0x260 waitforcompletion+0x173/0x3c0 waitforkprobeoptimizerlocked+0xbc/0x130 prockprobesoptimizationhandler+0x156/0x1b0 procsyscallhandler+0x324/0x490 vfswrite+0x52d/0xfe0 ksyswrite+0xff/0x200 dosyscall64+0x106/0x630 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> ... INFO: task cat:265 is blocked on a mutex likely owned by task sh:246.

waitforkprobeoptimizerlocked() reinitializes optimizercompletion, asks the optimizer thread to flush and sleeps in waitforcompletion(). The thread drains the (un)optimizing lists, but calls complete() only if completiondone() is true, i.e. if the completion is already done, which never happens while someone waits. disarmallkprobes() and kprobetraceselftestsinit() wait the same way.

Calling complete() unconditionally would not be enough: the waiter drops kprobemutex while it sleeps, and nothing else serializes the sysctl handler against the debugfs "enabled" file. A second flusher that still finds the lists non-empty, e.g. because a disabled probe is queued for unoptimizing, reinitializes the completion under the first:

sysctl write debugfs "enabled" write unoptimizeallkprobes() waitforkprobeoptimizerlocked() initcompletion(c) mutexunlock(&kprobemutex) waitforcompletion(c) disarmallkprobes() waitforkprobeoptimizerlocked() initcompletion(c) // c->wait is reset, the first // waiter is off the queue mutexunlock(&kprobemutex) waitforcompletion(c) kprobeoptimizer() complete(c) // wakes the debugfs writer only

where c is &optimizercompletion. Lining up the two writes during an optimizer pass loses the sysctl writer this way.

Replace the completion with a counter of optimizer passes, bumped at the end of each pass and signalled with wakeupvarlocked(), both under kprobemutex. A flusher samples the count and waits with waitvareventmutex(), which drops kprobemutex only while sleeping, so a new count means a whole pass ran in the meantime. Nothing is reinitialized, so several flushers can sleep in the wait at once.

Affected Software

127 affected componentsFixes available
Linux Linux kernel
ubuntu/linux-hwe-edge*
ubuntu/linux-aws-5.0*
ubuntu/linux-aws-5.3*
ubuntu/linux-azure*
ubuntu/linux-azure-5.3*
ubuntu/linux-azure-edge*
ubuntu/linux-gcp*
ubuntu/linux-gcp-5.3*
ubuntu/linux-gke-4.15*
ubuntu/linux-gke-5.4*
ubuntu/linux-gkeop-5.4*
ubuntu/linux-hwe*
ubuntu/linux-hwe-edge*
ubuntu/linux-oem*
ubuntu/linux-oracle-5.0*
ubuntu/linux-oracle-5.3*
ubuntu/linux-aws-5.11*
ubuntu/linux-aws-5.13*
ubuntu/linux-aws-5.8*
ubuntu/linux-azure-5.11*
ubuntu/linux-azure-5.13*
ubuntu/linux-azure-5.8*
ubuntu/linux-azure-fde*
ubuntu/linux-gcp-5.11*
ubuntu/linux-gcp-5.13*
ubuntu/linux-gcp-5.8*
ubuntu/linux-gke*
ubuntu/linux-gke-5.15*
ubuntu/linux-gkeop*
ubuntu/linux-gkeop-5.15*
ubuntu/linux-hwe-5.11*
ubuntu/linux-hwe-5.13*
ubuntu/linux-hwe-5.8*
ubuntu/linux-intel-5.13*
ubuntu/linux-oem-5.10*
ubuntu/linux-oem-5.13*
ubuntu/linux-oem-5.6*
ubuntu/linux-oracle-5.11*
ubuntu/linux-oracle-5.13*
ubuntu/linux-oracle-5.8*
ubuntu/linux-raspi2*
ubuntu/linux-riscv*
ubuntu/linux-riscv-5.11*
ubuntu/linux-riscv-5.8*
ubuntu/linux-allwinner-5.19*
ubuntu/linux-aws-5.19*
ubuntu/linux-aws-6.2*
ubuntu/linux-aws-6.5*
ubuntu/linux-azure-5.19*
ubuntu/linux-azure-6.2*
ubuntu/linux-azure-6.5*
ubuntu/linux-azure-fde-5.19*
ubuntu/linux-azure-fde-6.2*
ubuntu/linux-gcp-5.19*
ubuntu/linux-gcp-6.2*
ubuntu/linux-gcp-6.5*
ubuntu/linux-hwe-5.19*
ubuntu/linux-hwe-6.2*
ubuntu/linux-hwe-6.5*
ubuntu/linux-intel-iot-realtime*
ubuntu/linux-lowlatency-hwe-5.19*
ubuntu/linux-lowlatency-hwe-6.2*
ubuntu/linux-lowlatency-hwe-6.5*
ubuntu/linux-nvidia-6.2*
ubuntu/linux-nvidia-6.5*
ubuntu/linux-oem-5.17*
ubuntu/linux-oem-6.0*
ubuntu/linux-oem-6.1*
ubuntu/linux-oem-6.5*
ubuntu/linux-oracle-6.5*
ubuntu/linux-realtime*
ubuntu/linux-riscv*
ubuntu/linux-riscv-5.19*
ubuntu/linux-riscv-6.5*
ubuntu/linux-starfive-5.19*
ubuntu/linux-starfive-6.2*
ubuntu/linux-starfive-6.5*
ubuntu/linux-aws-6.14*
ubuntu/linux-aws-6.17*
ubuntu/linux-aws-7.0*
ubuntu/linux-azure-6.11*
ubuntu/linux-azure-6.14*
ubuntu/linux-azure-6.17*
ubuntu/linux-azure-7.0*
ubuntu/linux-azure-fde-6.14*
ubuntu/linux-azure-fde-6.17*
ubuntu/linux-azure-fde-7.0*
ubuntu/linux-azure-nvidia-6.14*
ubuntu/linux-gcp-6.11*
ubuntu/linux-gcp-6.14*
ubuntu/linux-gcp-7.0*
ubuntu/linux-hwe-6.11*
ubuntu/linux-hwe-6.14*
ubuntu/linux-hwe-7.0<7.0.0-42.42~24.04.1
7.0.0-42.42~24.04.1
ubuntu/linux-lowlatency-hwe-6.11*
ubuntu/linux-nvidia-6.11*
ubuntu/linux-nvidia-6.17*
ubuntu/linux-nvidia-7.0*
ubuntu/linux-oem-6.11*
ubuntu/linux-oem-6.14*
ubuntu/linux-oem-6.8*
ubuntu/linux-oracle-6.14*
ubuntu/linux-oracle-6.17*
ubuntu/linux-oracle-7.0*
ubuntu/linux-raspi-realtime*
ubuntu/linux-realtime*
ubuntu/linux-riscv*
ubuntu/linux-riscv-6.14*
ubuntu/linux-riscv-6.17*
ubuntu/linux-riscv-7.0<7.0.0-42.42.1~24.04.1
7.0.0-42.42.1~24.04.1
ubuntu/linux-realtime-6.14*
ubuntu/linux-realtime-6.17*
ubuntu/linux<7.0.0-42.42
7.0.0-42.42
ubuntu/linux-aws<7.0.0-1016.17
7.0.0-1016.17
ubuntu/linux-azure*
ubuntu/linux-azure-fde*
ubuntu/linux-gcp<7.0.0-1016.18
7.0.0-1016.18
ubuntu/linux-gke*
ubuntu/linux-ibm<7.0.0-1017.17
7.0.0-1017.17
ubuntu/linux-nvidia*
ubuntu/linux-nvidia-bos*
ubuntu/linux-oem-7.0<7.0.0-1017.17
7.0.0-1017.17
ubuntu/linux-oracle<7.0.0-1015.16
7.0.0-1015.16
ubuntu/linux-raspi*
ubuntu/linux-realtime*
ubuntu/linux-riscv<7.0.0-42.42.1
7.0.0-42.42.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade ubuntu/linux-hwe-7.0 to a version that resolves this vulnerability.

    Fixed in 7.0.0-42.42~24.04.1
  2. Upgrade

    Upgrade ubuntu/linux-riscv-7.0 to a version that resolves this vulnerability.

    Fixed in 7.0.0-42.42.1~24.04.1
  3. Upgrade

    Upgrade ubuntu/linux to a version that resolves this vulnerability.

    Fixed in 7.0.0-42.42
  4. Upgrade

    Upgrade ubuntu/linux-aws to a version that resolves this vulnerability.

    Fixed in 7.0.0-1016.17
  5. Upgrade

    Upgrade ubuntu/linux-gcp to a version that resolves this vulnerability.

    Fixed in 7.0.0-1016.18
  6. Upgrade

    Upgrade ubuntu/linux-ibm to a version that resolves this vulnerability.

    Fixed in 7.0.0-1017.17
  7. Upgrade

    Upgrade ubuntu/linux-oem-7.0 to a version that resolves this vulnerability.

    Fixed in 7.0.0-1017.17
  8. Upgrade

    Upgrade ubuntu/linux-oracle to a version that resolves this vulnerability.

    Fixed in 7.0.0-1015.16
  9. Upgrade

    Upgrade ubuntu/linux-riscv to a version that resolves this vulnerability.

    Fixed in 7.0.0-42.42.1

Event History

Oct 18, 2026
CVE Published
via MITRE·03:17 PM
Data Sourced
via MITRE·03:17 PM
Description
Data Sourced
via OSV·04:17 PM
DescriptionSeverityAffected Software
Data Sourced
via NVD·04:17 PM
Description

Frequently Asked Questions

1

What must occur for the hang to be triggered?

A kprobe must already be jump-optimized, and someone must write 0 to /proc/sys/debug/kprobes-optimization. The supplied example creates and enables an optimizable kprobe, waits for it to show [OPTIMIZED], and then performs that write.

2

How can I recognize an affected system during triage?

The process writing 0 to the kprobes-optimization sysctl remains blocked in uninterruptible D state, with a stack involving wait_for_kprobe_optimizer_locked(). Because it holds kprobe_sysctl_mutex, subsequent reads or writes of that sysctl also hang.

3

What is the operational impact once the condition is triggered?

The write never returns permanently, and later access to /proc/sys/debug/kprobes-optimization is blocked as well. This can prevent further reads or configuration changes through that sysctl until the condition is cleared.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203