Cloudanix VulnDB

CVE-2026-98800

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's handling of certain low-level tracing programs could let a running task keep using a program after it has been deleted, potentially crashing the system.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in BPF trampoline program execution on preemptible kernels: a detached program is freed after an RCU or RCU-tasks-trace grace period, but a task preempted inside the trampoline before acquiring the enter-helper lock can resume and dereference the already-freed program object.

Why it matters to the business

Kernel instability or memory-corruption crashes on Linux systems that attach BPF programs to trampolines; low immediate exploitability but affects reliability of eBPF-based observability, security, and networking tools.

How an attack unfolds

An attacker crafts or re-uses a BPF program attached to a trampoline, detaches it to trigger the buggy free path, and relies on scheduler preemption to leave a task inside the trampoline; on resume the task executes the now-freed program, producing a use-after-free that may be turned into information disclosure or code execution.

How to fix it

Apply the upstream fix that adds an RCU-tasks grace period before freeing trampoline-linked programs (see bpf_tramp_image_put and bpf_trampoline_add_prog changes); rebuild and boot the corrected kernel. Until patched, avoid or limit use of sleepable programs attached to trampolines on preemptible kernels.

How to confirm the fix worked

Confirm the kernel contains the commit that waits for an RCU-tasks grace period in the trampoline free path; run existing BPF selftests and KASAN-enabled stress tests that exercise trampoline attach/detach under preemption; verify absence of the described KASAN report.

Typical attack path

  1. Attach a BPF program to a trampoline via bpf_trampoline_add_prog
  2. Trigger detachment so the program is queued for freeing after an RCU grace period
  3. Force preemption of a task inside the trampoline before the enter helper acquires its read lock
  4. Resume the preempted task so it calls the already-freed program
  5. Observe or exploit the resulting vmalloc-out-of-bounds access

How to detect it

Search kernel logs for KASAN reports containing __bpf_prog_enter_recur and bpf_trampoline; inspect crash dumps for tasks that were preempted inside trampolines; correlate with BPF program attach/detach events in audit or BPF ring-buffer logs.

  • BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_enter_recur
  • bpf_trampoline_
  • bpf_tramp_image_put

What your security team should do

  • Prioritize kernel upgrade on any system running untrusted or complex BPF workloads within the next maintenance window
  • Enable KASAN or similar memory-debugging configurations on test fleets to catch similar issues early
  • Monitor EPSS and KEV feeds for any rise in exploit maturity
  • Review and minimize use of trampoline-attached programs until patches are widely deployed

The record

In the Linux kernel, the following vulnerability has been resolved: bpf: Wait for an RCU tasks grace period before freeing trampoline progs When a prog is detached from a trampoline, it is freed after an RCU grace period, or an RCU tasks trace one if it is sleepable. This covers the tasks that are running the prog, since the prog's enter helper takes the matching read lock before the prog is called. On a preemptible kernel, it doesn't cover a task that was preempted in the trampoline just before the enter helper. That task holds no lock yet, and it calls the prog after it was freed: BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_enter_recur+0x3a5/0x3f0 Read of size 8 at addr ffffc90000055040 by task candidate/110 CPU: 1 UID: 0 PID: 110 Comm: candidate Not tainted 7.3.0-rc2-00014-g15071f2a1263-dirty #2 PREEMPT(full) Call Trace: <TASK> __bpf_prog_enter_recur+0x3a5/0x3f0 bpf_trampoline_6442509193+0x37/0xf1 __x64_sys_futex+0x9/0x410 do_syscall_64+0xb0/0x530 ... Wait for an RCU tasks grace period before the existing one when freeing a prog that was linked to a trampoline. An RCU tasks grace period only ends once the tasks that were preempted have run again, and bpf_tramp_image_put() already relies on it to free the image. It doesn't wait for tasks that sleep in the trampoline, the next commit takes care of those. Only progs that were linked to a trampoline can be called this way, so bpf_trampoline_add_prog() marks them and other progs are still freed as before.

Affected packages

Ecosystem Package Introduced Fixed