Lucene search

K
nvd416baaa9-dc9f-4396-8d5f-8c081fb06d67NVD:CVE-2024-36961
HistoryJun 03, 2024 - 8:15 a.m.

CVE-2024-36961

2024-06-0308:15:09
416baaa9-dc9f-4396-8d5f-8c081fb06d67
web.nvd.nist.gov
6
linux kernel
thermal zone
debugfs
null pointer
locking issues

AI Score

6.3

Confidence

High

EPSS

0

Percentile

9.0%

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+ <[email protected]> # 6.8+

AI Score

6.3

Confidence

High

EPSS

0

Percentile

9.0%