In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()<\/p>\n
__htab_map_lookup_and_delete_batch() has no rescheduling point. The
\nbatch count bounds how many entries are copied out, not how many
\nbuckets are visited, so one BPF_MAP_LOOKUP_BATCH call can walk the
\nmap end to end. The empty-bucket fast path is worse: it stays inside
\na single rcu_read_lock() \/ bpf_disable_instrumentation() section for
\nany run of consecutive empty buckets.<\/p>\n
That holds up on small maps, but it falls apart at scale. On a
\n144-CPU arm64 host running a CONFIG_PREEMPT_NONE kernel, periodic
\nBPF_MAP_LOOKUP_BATCH calls against an LRU hash map with 16,777,216
\nbuckets held a CPU inside the batch op for 77+ seconds and triggered
\nthe soft lockup watchdog.<\/p>\n
Commit 75134f16e7dd (“bpf: Add schedule points in batch ops”) fixed this
\nsame problem in the generic batch ops, but not in this htab-native path,
\nwhich every htab-based hash map variant uses for its lookup[_and_delete]
\nbatch ops.<\/p>\n
Complete that fix here. Leave the critical section after 64 consecutive
\nempty buckets, call cond_resched_tasks_rcu_qs(), and resume at the saved
\nbucket cursor. No locks are held at that point, and resuming from the
\ncursor is already the function’s behavior for non-empty buckets. Add the
\nsame call to the per-bucket loop after copy_to_user(), where every lock
\nhas been dropped. cond_resched_rcu() is not enough here: sleeping with
\nbpf_prog_active elevated makes tracing programs on that CPU silently
\nskip their invocations.<\/p>\n
Plain cond_resched() is not enough either. It is a no-op under PREEMPT
\nand PREEMPT_LAZY, the only models arm64 and x86 have offered since
\ncommit 7dadeaa6e851 (“sched: Further restrict the preemption modes”).
\nIt is also never a Tasks RCU quiescent state, in any model: the
\nreschedule counts as a preemption. The walking task stays a holdout and
\nstalls every synchronize_rcu_tasks() caller, ftrace and BPF trampoline
\nteardown included, until the syscall returns [1].
\ncond_resched_tasks_rcu_qs() is the usual tool for that [2]. It reports
\nthe quiescent state at each yield and still reschedules as
\ncond_resched() does on PREEMPT_NONE and PREEMPT_VOLUNTARY kernels.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
bpf: Avoid soft lockup in __htab_map_lookup_and_delete_batch()<\/p>\n
__htab_map_lookup_and_delete_batch() has no rescheduling point. The<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-41116","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/41116","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=41116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=41116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=41116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}