CVE-2026-98787 in Linux
Summary
by MITRE • 10/18/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel's eBPF subsystem contains a concurrency flaw within the rhashtable-based map implementation, specifically affecting the batch lookup and deletion operation function known as __rhtab_map_lookup_and_delete_batch(). This vulnerability arises from an incorrect assumption regarding CPU migration safety during memory cache operations. The underlying issue is rooted in how per-CPU pointers are accessed when freeing BPF memory elements via bpf_mem_cache_free_rcu(). This helper function relies on this_cpu_ptr(), a macro that retrieves data specific to the currently executing processor core. Accessing such per-CPU variables safely requires strict guarantees that the execution context will not migrate to another CPU during the operation, as doing so would result in accessing stale or incorrect memory locations associated with a different logical processor.
In configurations where PREEMPT_RCU is enabled, which allows for more aggressive preemption of read-side critical sections, rcu_read_lock() does not inherently disable task migration. While many callers of rhtab_delete_elem correctly disabled CPU migration to ensure safety when accessing per-CPU structures, __rhtab_map_lookup_and_delete_batch() failed to do so, relying solely on the RCU read lock for synchronization. Consequently, during the iterative deletion loop within this batch operation, the executing task could be preempted and scheduled onto a different CPU core by the kernel scheduler. When bpf_mem_cache_free_rcu subsequently invoked this_cpu_ptr(), it would retrieve data based on smp_processor_id() from the new context rather than the original one where the RCU read lock was acquired. This mismatch triggers a kernel BUG, manifesting as a crash with the error message indicating the use of smp_processor_id in preemptible code, effectively causing a denial of service for any process utilizing this specific eBPF map operation pattern.
From a classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources without proper synchronization. The lack of migration protection constitutes a race condition where the state assumed by one part of the code (the RCU read lock context) diverges from the actual hardware execution environment due to scheduler intervention. In terms of adversarial tactics, this flaw could potentially be leveraged within ATT&CK technique T1499, Endpoint Denial of Service, if an attacker can trigger repeated batch deletions on rhashtable-based eBPF maps to induce kernel panics and destabilize the host system. The impact is primarily localized to systems running with PREEMPT_RCU enabled, which includes many modern desktop and server distributions aiming for lower latency by allowing preemption within RCU read-side critical sections.
The resolution involves wrapping the delete loop inside __rhtab_map_lookup_and_delete_batch() with explicit migrate_disable() and migrate_enable() calls. This ensures that once the operation begins, the task is pinned to its current CPU core until the batch deletion completes or fails, thereby guaranteeing that this_cpu_ptr accesses remain valid throughout the critical section. To mitigate the risk of exploitation in unpatched systems, administrators should ensure that kernel updates are applied promptly via their distribution's package management system. Additionally, monitoring for frequent eBPF program crashes or kernel oops logs related to RCU and per-CPU pointer issues can help identify potential abuse attempts targeting this specific code path before a patch is deployed.