Improper Locking Affecting kernel package, versions *
Threat Intelligence
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 ID SNYK-CENTOS7-KERNEL-7213699
- published 5 Jun 2024
- disclosed 3 Jun 2024
Introduced: 3 Jun 2024
CVE-2024-36961 Open this link in a new tabHow to fix?
There is no fixed version for Centos:7
kernel
.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel
package and not the kernel
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:
thermal/debugfs: Fix two locking issues with thermal zone debug
With the current thermal zone locking arrangement in the debugfs code, user space can open the "mitigations" file for a thermal zone before the zone's debugfs pointer is set which will result in a NULL pointer dereference in tze_seq_start().
Moreover, thermal_debug_tz_remove() is not called under the thermal zone lock, so it can run in parallel with the other functions accessing the thermal zone's struct thermal_debugfs object. Then, it may clear tz->debugfs after one of those functions has checked it and the struct thermal_debugfs object may be freed prematurely.
To address the first problem, pass a pointer to the thermal zone's struct thermal_debugfs object to debugfs_create_file() in thermal_debug_tz_add() and make tze_seq_start(), tze_seq_next(), tze_seq_stop(), and tze_seq_show() retrieve it from s->private instead of a pointer to the thermal zone object. This will ensure that tz_debugfs will be valid across the "mitigations" file accesses until thermal_debugfs_remove_id() called by thermal_debug_tz_remove() removes that file.
To address the second problem, use tz->lock in thermal_debug_tz_remove() around the tz->debugfs value check (in case the same thermal zone is removed at the same time in two different threads) and its reset to NULL.
Cc :6.8+ <stable@vger.kernel.org> # 6.8+