PT-2026-117019 · Linux · Linux

CVE-2026-98800

·

Published

2026-10-18

·

Updated

2026-10-18

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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: 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.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-98800

Affected Products

Linux