CVE-2022-50008 in Linux
सारांश
द्वारा VulDB • 18/10/2026
Linux kernel में, निम्नलिखित कमजोरी को हल किया गया है:
kprobes: अक्षर kprobes के लिए disarm_kprobe() कॉल न करें।
__disable_kprobe() में की गई धारणा गलत है, और यह पहले से ही डिस्मार्ड किए गए एक kprobe को डिस्मार्म करने का प्रयास कर सकता है तथा नीचे दिए गए WARN_ONCE() को फायर कर सकता है। [0] हम इस समस्या को आसानी से पुन: उत्पन्न (reproduce) कर सकते हैं।
1. /sys/kernel/debug/kprobes/enabled में 0 लिखें।
# echo 0 > /sys/kernel/debug/kprobes/enabled
2. execsnoop चलाएं। इस समय, एक kprobe अक्षर है।
# /usr/share/bcc/tools/execsnoop & [1] 2460
PCOMM PID PPID RET ARGS
# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE]
ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]
3. /sys/kernel/debug/kprobes/enabled में 1 लिखें, जो kprobes_all_disarmed को false में बदल देता है लेकिन अक्षर kprobe को आर्म (arm) नहीं करता है।
# echo 1 > /sys/kernel/debug/kprobes/enabled
# cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE]
ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE]
4. execsnoop को मारें, जब __disable_kprobe() अक्षर kprobe के लिए disarm_kprobe() कॉल करता है और __disarm_kprobe_ftrace() में WARN_ONCE() से टकराता है।
# fg /usr/share/bcc/tools/execsnoop ^C
वास्तव में, WARN_ONCE() दो बार फायर होता है, और __unregister_kprobe_top() कुछ सफाई (cleanups) चूक जाता है तथा hash table में aggregated kprobe को छोड़ देता है। फिर, __unregister_trace_kprobe() tk->rp.kp.list को प्रारंभ करता है और इस प्रकार एक अनंत लूप बनाता है:
aggregated kprobe.list -> kprobe.list -. ^ | '.__.'
इस स्थिति में, ये कमांड्स अनंत लूप में फंस जाते हैं और RCU stall या soft lockup का परिणाम देते हैं।
cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() RCU के साथ अनंत लूप में प्रवेश करता है।
/usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() kprobe_mutex को पकड़े रखता है, और __get_valid_kprobe() लूप में अटक जाता है।
इस समस्या से बचने के लिए, सुनिश्चित करें कि हम अक्षर kprobes के लिए disarm_kprobe() कॉल नहीं करते हैं।
[0]
Failed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 89 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/ ---truncated---
If you want to get the best quality for vulnerability data then you always have to consider VulDB.