Resource Injection 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-CENTOS8-PYTHON3PERF-6506624
- published27 Mar 2024
- disclosed26 Mar 2024
Introduced: 26 Mar 2024
CVE-2024-26646 (opens in a new tab)How to fix?
There is no fixed version for Centos: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 Centos.
See How to fix? for Centos:8 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
thermal: intel: hfi: Add syscore callbacks for system-wide PM
The kernel allocates a memory buffer and provides its location to the hardware, which uses it to update the HFI table. This allocation occurs during boot and remains constant throughout runtime.
When resuming from hibernation, the restore kernel allocates a second memory buffer and reprograms the HFI hardware with the new location as part of a normal boot. The location of the second memory buffer may differ from the one allocated by the image kernel.
When the restore kernel transfers control to the image kernel, its HFI buffer becomes invalid, potentially leading to memory corruption if the hardware writes to it (the hardware continues to use the buffer from the restore kernel).
It is also possible that the hardware "forgets" the address of the memory buffer when resuming from "deep" suspend. Memory corruption may also occur in such a scenario.
To prevent the described memory corruption, disable HFI when preparing to suspend or hibernate. Enable it when resuming.
Add syscore callbacks to handle the package of the boot CPU (packages of non-boot CPUs are handled via CPU offline). Syscore ops always run on the boot CPU. Additionally, HFI only needs to be disabled during "deep" suspend and hibernation. Syscore ops only run in these cases.
[ rjw: Comment adjustment, subject and changelog edits ]
References
- https://access.redhat.com/security/cve/CVE-2024-26646
- https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee
- https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566
- https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9
- https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c