Live › vulnerability › CVE-2026-98787
Go to dashboardIn the Linux kernel's BPF resizable hash map, batch lookup-and-delete runs under rcu_read_lock() without disabling migration, so a task can move between CPUs while calling a per-CPU pointer. The result is a kernel warning about smp_processor_id() in preemptible code, and the fix wraps the delete loop in migrate_disable()/migrate_enable().
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with CONFIG_PREEMPT_RCU that use BPF resizable hash maps with batch lookup-and-delete operations. The sources do not say which kernel versions are affected or whether an unprivileged user can reach the path, so the exposure is unclear.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix missing migration protection in __rhtab_map_lookup_and_delete_batch()
bpf_mem_cache_free_rcu() uses this_cpu_ptr() which requires migration to be disabled. All callers of rhtab_delete_elem() disable migration except __rhtab_map_lookup_and_delete_batch(), which calls it under rcu_read_lock() only.
On CONFIG_PREEMPT_RCU, rcu_read_lock() does not disable preemption or migration, so the task can migrate between CPUs during the delete loop, causing this_cpu_ptr() to trigger:
BUG: using smp_processor_id() in preemptible [00000000] code
Fix by wrapping the delete loop in migrate_disable()/migrate_enable() in __rhtab_map_lookup_and_delete_batch(), matching the migration protection that the other callers already provide.
This page as .md · .json · in your agent: get_signal("CVE-2026-98787")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.