Security Vulnerabilities - CVEs Published In June 2024
Memory corruption while copying a keyblob`s material when the key material`s size is not accurately checked.
CVSS Score
7.8
EPSS Score
0.001
Published
2024-06-03
Memory corruption in Audio during a playback or a recording due to race condition between allocation and deallocation of graph object.
CVSS Score
6.7
EPSS Score
0.001
Published
2024-06-03
Memory corruption when IPC callback handle is used after it has been released during register callback by another thread.
CVSS Score
6.7
EPSS Score
0.001
Published
2024-06-03
Memory corruption when more scan frequency list or channels are sent from the user space.
CVSS Score
6.7
EPSS Score
0.001
Published
2024-06-03
Information disclosure while handling T2LM Action Frame in WLAN Host.
CVSS Score
6.5
EPSS Score
0.002
Published
2024-06-03
Memory corruption in TZ Secure OS while Tunnel Invoke Manager initialization.
CVSS Score
9.3
EPSS Score
0.001
Published
2024-06-03
Server-Side Request Forgery (SSRF) vulnerability in andy_moyle Church Admin church-admin.This issue affects Church Admin: from n/a through <= 4.3.6.
CVSS Score
4.4
EPSS Score
0.002
Published
2024-06-03
An improper removal of sensitive information before storage or transfer vulnerability [CWE-212] in FortiSOAR version 7.3.0, version 7.2.2 and below, version 7.0.3 and below may allow an authenticated low privileged user to read Connector passwords in plain-text via HTTP responses.
CVSS Score
6.5
EPSS Score
0.005
Published
2024-06-03
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix invalid reads in fence signaled events
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.
CVSS Score
7.1
EPSS Score
0.003
Published
2024-06-03
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+
CVSS Score
5.5
EPSS Score
0.001
Published
2024-06-03