In the Linux kernel, the following vulnerability has been resolved:

kprobes: don't call disarm_kprobe() for disabled kprobes

The assumption in __disablekprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARNONCE() below. [0] We can easily reproduce this issue.

1. Write 0 to /sys/kernel/debug/kprobes/enabled.

   echo 0 > /sys/kernel/debug/kprobes/enabled

2. Run execsnoop. At this time, one kprobe is disabled.

   /usr/share/bcc/tools/execsnoop &

   [1] 2460 PCOMM PID PPID RET ARGS

   cat /sys/kernel/debug/kprobes/list

   ffffffff91345650 r __x64sysexecve+0x0 [FTRACE] ffffffff91345650 k __x64sysexecve+0x0 [DISABLED][FTRACE]

3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobesalldisarmed to false but does not arm the disabled kprobe.

   echo 1 > /sys/kernel/debug/kprobes/enabled

   cat /sys/kernel/debug/kprobes/list

   ffffffff91345650 r __x64sysexecve+0x0 [FTRACE] ffffffff91345650 k __x64sysexecve+0x0 [DISABLED][FTRACE]

4. Kill execsnoop, when __disablekprobe() calls disarmkprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarmkprobeftrace().

   fg

   /usr/share/bcc/tools/execsnoop ^C

Actually, WARN_ONCE() is fired twice, and __unregisterkprobetop() misses some cleanups and leaves the aggregated kprobe in the hash table. Then, __unregistertracekprobe() initialises tk->rp.kp.list and creates an infinite loop like this.

aggregated kprobe.list -> kprobe.list -. ^ | '.__.'

In this situation, these commands fall into the infinite loop and result in RCU stall or soft lockup.

cat /sys/kernel/debug/kprobes/list : showkprobeaddr() enters into the infinite loop with RCU.

/usr/share/bcc/tools/execsnoop : warnkproberereg() holds kprobe_mutex, and __getvalidkprobe() is stuck in the loop.

To avoid the issue, make sure we don't call disarm_kprobe() for disabled kprobes.

[0] Failed to disarm kprobe-ftrace at __x64sysexecve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarmkprobeftrace.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:__disarmkprobeftrace.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> __disablekprobe (kernel/kprobes.c:1716) disablekprobe (kernel/kprobes.c:2392) __disabletracekprobe (kernel/trace/tracekprobe.c:340) disabletracekprobe (kernel/trace/tracekprobe.c:429) perf_traceeventunreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trace/traceeventperf.c:168) perfkprobedestroy (kernel/trace/traceeventperf.c:295) freeevent (kernel/events/core.c:4971) perfeventreleasekernel (kernel/events/core.c:5176) perfrelease (kernel/events/core.c:5186) _fput (fs/filetable.c:321) taskworkrun (./include/linux/ ---truncated---