Improper Locking Affecting libperf package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS9-LIBPERF-13388160
- published7 Oct 2025
- disclosed4 Oct 2025
Introduced: 4 Oct 2025
NewCVE-2023-53587 (opens in a new tab)How to fix?
There is no fixed version for Centos:9 libperf.
NVD Description
Note: Versions mentioned in the description apply only to the upstream libperf package and not the libperf package as distributed by Centos.
See How to fix? for Centos:9 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Sync IRQ works before buffer destruction
If something was written to the buffer just before destruction, it may be possible (maybe not in a real system, but it did happen in ARCH=um with time-travel) to destroy the ringbuffer before the IRQ work ran, leading this KASAN report (or a crash without KASAN):
BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a Read of size 8 at addr 000000006d640a48 by task swapper/0CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7 Stack: 60c4f20f 0c203d48 41b58ab3 60f224fc 600477fa 60f35687 60c4f20f 601273dd 00000008 6101eb00 6101eab0 615be548 Call Trace: [<60047a58>] show_stack+0x25e/0x282 [<60c609e0>] dump_stack_lvl+0x96/0xfd [<60c50d4c>] print_report+0x1a7/0x5a8 [<603078d3>] kasan_report+0xc1/0xe9 [<60308950>] __asan_report_load8_noabort+0x1b/0x1d [<60232844>] irq_work_run_list+0x11a/0x13a [<602328b4>] irq_work_tick+0x24/0x34 [<6017f9dc>] update_process_times+0x162/0x196 [<6019f335>] tick_sched_handle+0x1a4/0x1c3 [<6019fd9e>] tick_sched_timer+0x79/0x10c [<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695 [<60182913>] hrtimer_interrupt+0x16c/0x2c4 [<600486a3>] um_timer+0x164/0x183 [...]
Allocated by task 411: save_stack_trace+0x99/0xb5 stack_trace_save+0x81/0x9b kasan_save_stack+0x2d/0x54 kasan_set_track+0x34/0x3e kasan_save_alloc_info+0x25/0x28 ____kasan_kmalloc+0x8b/0x97 __kasan_kmalloc+0x10/0x12 __kmalloc+0xb2/0xe8 load_elf_phdrs+0xee/0x182 [...]
The buggy address belongs to the object at 000000006d640800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 584 bytes inside of freed 1024-byte region [000000006d640800, 000000006d640c00)
Add the appropriate irq_work_sync() so the work finishes before the buffers are destroyed.
Prior to the commit in the Fixes tag below, there was only a single global IRQ work, so this issue didn't exist.
References
- https://access.redhat.com/security/cve/CVE-2023-53587
- https://git.kernel.org/stable/c/0a65165bd24ee9231191597b7c232376fcd70cdb
- https://git.kernel.org/stable/c/1c99f65d6af2a454bfd5207b4f6a97c8474a1191
- https://git.kernel.org/stable/c/2399b1fda025e939b6fb1ac94505bcf718534e65
- https://git.kernel.org/stable/c/2702b67f59d455072a08dc40312f9b090d4dec04
- https://git.kernel.org/stable/c/372c5ee537b8366b64b691ba29e9335525e1655e
- https://git.kernel.org/stable/c/675751bb20634f981498c7d66161584080cc061e
- https://git.kernel.org/stable/c/c63741e872fcfb10e153517750f7908f0c00f60d
- https://git.kernel.org/stable/c/d9834abd8b24d1fe8092859e436fe1e0fd467c61
- https://git.kernel.org/stable/c/fc6858b7f8e1221f62ce8c6ff8a13a349c32cd76