CVE-2024-36007 Affecting python3-perf package, versions <0:4.18.0-553.8.1.el8_10
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-ROCKY8-PYTHON3PERF-7455210
- published16 Jul 2024
- disclosed20 May 2024
Introduced: 20 May 2024
CVE-2024-36007 (opens in a new tab)How to fix?
Upgrade Rocky-Linux:8 python3-perf to version 0:4.18.0-553.8.1.el8_10 or higher.
This issue was patched in RLSA-2024:4211.
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 Rocky-Linux.
See How to fix? for Rocky-Linux:8 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix warning during rehash
As previously explained, the rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters.
When the work runs out of credits it stores the current chunk and entry as markers in the per-work context so that it would know where to resume the migration from the next time the work is scheduled.
Upon error, the chunk marker is reset to NULL, but without resetting the entry markers despite being relative to it. This can result in migration being resumed from an entry that does not belong to the chunk being migrated. In turn, this will eventually lead to a chunk being iterated over as if it is an entry. Because of how the two structures happen to be defined, this does not lead to KASAN splats, but to warnings such as [1].
Fix by creating a helper that resets all the markers and call it from all the places the currently only reset the chunk marker. For good measures also call it when starting a completely new rehash. Add a warning to avoid future cases.
[1] WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0 Modules linked in: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_afk_encode+0x242/0x2f0 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 </TASK>
References
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-36007
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://git.kernel.org/stable/c/039992b6d2df097c65f480dcf269de3d2656f573
- https://git.kernel.org/stable/c/0b88631855026b55cad901ac28d081e0f358e596
- https://git.kernel.org/stable/c/17e9e0bbae652b9b2049e51699e93dfa60b2988d
- https://git.kernel.org/stable/c/1d76bd2a0034d0d08045c1c6adf2235d88982952
- https://git.kernel.org/stable/c/743edc8547a92b6192aa1f1b6bb78233fa21dc9b
- https://git.kernel.org/stable/c/751d352858108314efd33dddd5a9a2b6bf7d6916
- https://git.kernel.org/stable/c/e890456051fe8c57944b911defb3e6de91315861