In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
kprobes: Fix permanent hang when flushing the kprobe optimizer<\/p>\n
Writing 0 to \/proc\/sys\/debug\/kprobes-optimization while a kprobe is
\njump-optimized never returns. The writer sleeps in D state forever with
\nkprobe_sysctl_mutex held, so any later read or write of that sysctl
\nhangs as well. For example, with vfs_read+9 as an optimizable address
\nin this build:<\/p>\n
# cd \/sys\/kernel\/tracing
\n # echo ‘p:myprobe vfs_read+9’ >> kprobe_events
\n # echo 1 > events\/kprobes\/myprobe\/enable
\n # # wait until \/sys\/kernel\/debug\/kprobes\/list shows [OPTIMIZED]
\n # echo 0 > \/proc\/sys\/debug\/kprobes-optimization<\/p>\n
INFO: task sh:246 blocked for more than 10 seconds.
\n Call Trace:<\/p>\n
__schedule+0x1176\/0x4f70
\n schedule+0xdc\/0x2c0
\n schedule_timeout+0x17b\/0x260
\n wait_for_completion+0x173\/0x3c0
\n wait_for_kprobe_optimizer_locked+0xbc\/0x130
\n proc_kprobes_optimization_handler+0x156\/0x1b0
\n proc_sys_call_handler+0x324\/0x490
\n vfs_write+0x52d\/0xfe0
\n ksys_write+0xff\/0x200
\n do_syscall_64+0x106\/0x630
\n entry_SYSCALL_64_after_hwframe+0x77\/0x7f<\/p>\n
…
\n INFO: task cat:265 is blocked on a mutex likely owned by task sh:246.<\/p>\n
wait_for_kprobe_optimizer_locked() reinitializes optimizer_completion,
\nasks the optimizer thread to flush and sleeps in wait_for_completion().
\nThe thread drains the (un)optimizing lists, but calls complete() only
\nif completion_done() is true, i.e. if the completion is already done,
\nwhich never happens while someone waits. disarm_all_kprobes() and
\nkprobe_trace_self_tests_init() wait the same way.<\/p>\n
Calling complete() unconditionally would not be enough: the waiter
\ndrops kprobe_mutex while it sleeps, and nothing else serializes the
\nsysctl handler against the debugfs “enabled” file. A second flusher
\nthat still finds the lists non-empty, e.g. because a disabled probe is
\nqueued for unoptimizing, reinitializes the completion under the first:<\/p>\n
sysctl write debugfs “enabled” write
\n unoptimize_all_kprobes()
\n wait_for_kprobe_optimizer_locked()
\n init_completion(c)
\n mutex_unlock(&kprobe_mutex)
\n wait_for_completion(c)
\n disarm_all_kprobes()
\n wait_for_kprobe_optimizer_locked()
\n init_completion(c)
\n \/\/ c->wait is reset, the first
\n \/\/ waiter is off the queue
\n mutex_unlock(&kprobe_mutex)
\n wait_for_completion(c)
\n kprobe_optimizer()
\n complete(c)
\n \/\/ wakes the debugfs writer only<\/p>\n
where c is &optimizer_completion. Lining up the two writes during an
\noptimizer pass loses the sysctl writer this way.<\/p>\n
Replace the completion with a counter of optimizer passes, bumped at the
\nend of each pass and signalled with wake_up_var_locked(), both under
\nkprobe_mutex. A flusher samples the count and waits with
\nwait_var_event_mutex(), which drops kprobe_mutex only while sleeping, so
\na new count means a whole pass ran in the meantime. Nothing is
\nreinitialized, so several flushers can sleep in the wait at once.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
kprobes: Fix permanent hang when flushing the kprobe optimizer<\/p>\n
Writing 0 to \/proc\/sys\/debug\/kprobes-optimization while a kprobe is<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-41002","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/41002","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=41002"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=41002"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=41002"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}