Race Condition Affecting python-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-CENTOS7-PYTHONPERF-7460767
- published16 Jul 2024
- disclosed12 Jul 2024
Introduced: 12 Jul 2024
CVE-2024-39501 (opens in a new tab)How to fix?
There is no fixed version for Centos:7 python-perf.
NVD Description
Note: Versions mentioned in the description apply only to the upstream python-perf package and not the python-perf package as distributed by Centos.
See How to fix? for Centos:7 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
drivers: core: synchronize really_probe() and dev_uevent()
Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization:
Thread #1:
really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... }
Thread #2:
dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... }
really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. This is the path where above race is observed:
dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Add lock here dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Similar cases are reported by syzkaller in
https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a
But these are regarding the initialization of dev->driver
dev->driver = drv;
As this switches dev->driver to non-NULL these reports can be considered to be false-positives (which should be "fixed" by this commit, as well, though).
The same issue was reported and tried to be fixed back in 2015 in
https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/
already.
References
- https://access.redhat.com/security/cve/CVE-2024-39501
- https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69
- https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c
- https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad
- https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea6f564e6
- https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90
- https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080
- https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0
- https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721