Race Condition Affecting python3-perf 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-RHEL8-PYTHON3PERF-8284874
- published23 Oct 2024
- disclosed21 Oct 2024
Introduced: 21 Oct 2024
CVE-2024-49866 (opens in a new tab)How to fix?
There is no fixed version for RHEL:8 python3-perf.
NVD Description
Note: Versions mentioned in the description apply only to the upstream python3-perf package and not the python3-perf package as distributed by RHEL.
See How to fix? for RHEL:8 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
tracing/timerlat: Fix a race during cpuhp processing
There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally:
ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220
WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0
Modules linked in:
CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:debug_print_object+0x7d/0xb0
...
Call Trace:
<TASK>
? __warn+0x7c/0x110
? debug_print_object+0x7d/0xb0
? report_bug+0xf1/0x1d0
? prb_read_valid+0x17/0x20
? handle_bug+0x3f/0x70
? exc_invalid_op+0x13/0x60
? asm_exc_invalid_op+0x16/0x20
? debug_print_object+0x7d/0xb0
? debug_print_object+0x7d/0xb0
? __pfx_timerlat_irq+0x10/0x10
__debug_object_init+0x110/0x150
hrtimer_init+0x1d/0x60
timerlat_main+0xab/0x2d0
? __pfx_timerlat_main+0x10/0x10
kthread+0xb7/0xe0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2d/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU:
T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() |
To fix this, skip online processing if the CPU is already offline.
References
- https://access.redhat.com/security/cve/CVE-2024-49866
- https://git.kernel.org/stable/c/322920b53dc11f9c2b33397eb3ae5bc6a175b60d
- https://git.kernel.org/stable/c/829e0c9f0855f26b3ae830d17b24aec103f7e915
- https://git.kernel.org/stable/c/a0d9c0cd5856191e095cf43a2e141b73945b7716
- https://git.kernel.org/stable/c/a6e9849063a6c8f4cb2f652a437e44e3ed24356c
- https://git.kernel.org/stable/c/ce25f33ba89d6eefef64157655d318444580fa14
- https://git.kernel.org/stable/c/f72b451dc75578f644a3019c1489e9ae2c14e6c4