CVE-2023-53577

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

bpf, cpumap: Make sure kthread is running before map update returns

The following warning was reported when running stress-mode enabled

xdp_redirect_cpu with some RT threads:

------------[ cut here ]------------

WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135

CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1

Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)

Workqueue: events cpu_map_kthread_stop

RIP: 0010:put_cpu_map_entry+0xda/0x220

......

Call Trace:

<TASK>

? show_regs+0x65/0x70

? __warn+0xa5/0x240

......

? put_cpu_map_entry+0xda/0x220

cpu_map_kthread_stop+0x41/0x60

process_one_work+0x6b0/0xb80

worker_thread+0x96/0x720

kthread+0x1a5/0x1f0

ret_from_fork+0x3a/0x70

ret_from_fork_asm+0x1b/0x30

</TASK>

The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memory

leak in cpu_map_update_elem"). The kthread is stopped prematurely by

kthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't call

cpu_map_kthread_run() at all but XDP program has already queued some

frames or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks

the ptr_ring, it will find it was not emptied and report a warning.

An alternative fix is to use __cpu_map_ring_cleanup() to drop these

pending frames or skbs when kthread_stop() returns -EINTR, but it may

confuse the user, because these frames or skbs have been handled

correctly by XDP program. So instead of dropping these frames or skbs,

just make sure the per-cpu kthread is running before

__cpu_map_entry_alloc() returns.

After apply the fix, the error handle for kthread_stop() will be

unnecessary because it will always return 0, so just remove it.