CVE-2026-98036: bpf: Preserve special fields in recycled rhtab elements

Published Sep 25, 2026
·
Updated

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

bpf: Preserve special fields in recycled rhtab elements

rhtabmapupdateelem() initializes special fields after obtaining an element from bpfmemcachealloc(). The allocator can return a fresh, zeroed unit, or recycle one from its RCU-pending lists before the registered destructor has run.

A BPF program can retain a map-value pointer after deleting its element and initialize and arm a timer through that pointer. If the deleted unit is recycled, checkandinitmapvalue() clears the only pointer to the timer. Neither a later deletion nor rhtabmemdtor() can then cancel it, and the callback can run with its key and value pointing into freed memory.

Do not reinitialize special fields on insertion. Fresh allocator units are already zeroed. For recycled units, the special fields are ownership state that must remain visible to the eventual destructor. copymapvalue() already skips those fields, matching the non-preallocated hash-map path and the lifecycle established by commit 275c30bcee66 ("bpf: Don't reinit map value in prealloclrupop").

[ kkd: Split out the fix and rewrote the commit log ]

Affected Software

1 affected component
Linux Linux kernel

Event History

Sep 25, 2026
CVE Published
via MITRE·10:23 AM
Data Sourced
via MITRE·10:23 AM
Description

Frequently Asked Questions

1

What conditions are required to trigger this issue?

An attacker needs the ability to run a BPF program that can retain a map-value pointer after deleting its hash-map element. The program must initialize and arm a timer through that stale pointer, and the deleted allocation must then be recycled before its registered destructor runs.

2

What is the consequence if the vulnerable lifecycle occurs?

The timer pointer can be cleared while the timer remains armed. Later cleanup cannot cancel it, allowing its callback to execute with its key and value pointing to freed memory.

3

Is a workaround described for systems that cannot be patched immediately?

No workaround is provided in the available data. The described fix avoids reinitializing special fields when recycled hash-table map elements are inserted, preserving timer ownership state for eventual destruction.

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