CVE-2023-53577
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-04

Last updated on: 2026-03-23

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-04
Last Modified
2026-03-23
Generated
2026-05-07
AI Q&A
2025-10-04
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 7 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.5
linux linux_kernel 6.5
linux linux_kernel 6.5
linux linux_kernel 6.5
linux linux_kernel From 6.2 (inc) to 6.4.10 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.45 (exc)
linux linux_kernel From 4.15 (inc) to 5.15.126 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-401 The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel involves the bpf cpumap feature where a kernel thread (kthread) may be stopped prematurely before a map update completes. This causes a warning because the XDP program has queued frames or skbs into a ring buffer that is not emptied when checked, leading to potential memory handling issues. The fix ensures the kthread is running before the map update returns, preventing the warning and avoiding dropping frames or skbs unnecessarily.


How can this vulnerability impact me? :

The vulnerability can cause warnings and potential instability in the Linux kernel when using the bpf cpumap feature with XDP programs, due to premature stopping of kernel threads and unemptied ring buffers. This could lead to unexpected behavior or resource leaks in systems relying on this functionality.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by observing kernel warnings related to the bpf cpumap kthread. Specifically, look for warnings similar to the following in the kernel logs: "WARNING: CPU: ... at kernel/bpf/cpumap.c:135" indicating issues with kthread not running before map update returns. You can check kernel logs using commands like `dmesg | grep cpumap` or `journalctl -k | grep cpumap` to find such warnings.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves ensuring that the Linux kernel is updated to a version that includes the fix for this vulnerability, which makes sure the per-CPU kthread is running before __cpu_map_entry_alloc() returns. Since the issue is resolved by a kernel patch, applying the updated kernel version is the recommended step. There are no alternative manual mitigations mentioned.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart