Security Vulnerabilities - CVEs Published In October 2024
InCopy versions 19.4, 18.5.3 and earlier are affected by an Unrestricted Upload of File with Dangerous Type vulnerability that could result in arbitrary code execution by an attacker. An attacker could exploit this vulnerability by uploading a malicious file which can then be executed on the server. Exploitation of this issue requires user interaction.
CVSS Score
7.8
EPSS Score
0.001
Published
2024-10-09
InDesign Desktop versions 19.4, 18.5.3 and earlier are affected by an Unrestricted Upload of File with Dangerous Type vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by uploading a malicious file which, when executed, could run arbitrary code in the context of the server. Exploitation of this issue requires user interaction.
CVSS Score
7.8
EPSS Score
0.001
Published
2024-10-09
Adobe Framemaker versions 2020.6, 2022.4 and earlier are affected by an out-of-bounds read vulnerability when parsing a crafted file, which could result in a read past the end of an allocated memory structure. An attacker could leverage this vulnerability to execute code in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
CVSS Score
7.8
EPSS Score
0.001
Published
2024-10-09
Substance3D - Stager versions 3.0.3 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.
CVSS Score
7.8
EPSS Score
0.002
Published
2024-10-09
PHPGurukul Hospital Management System 4.0 is vulnerable to Cross Site Scripting (XSS) via the patname, pataddress, and medhis parameters in doctor/add-patient.php and doctor/edit-patient.php.
CVSS Score
5.4
EPSS Score
0.001
Published
2024-10-09
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Disable DMCUB timeout for DCN35
[Why]
DMCUB can intermittently take longer than expected to process commands.
Old ASIC policy was to continue while logging a diagnostic error - which
works fine for ASIC without IPS, but with IPS this could lead to a race
condition where we attempt to access DCN state while it's inaccessible,
leading to a system hang when the NIU port is not disabled or register
accesses that timeout and the display configuration in an undefined
state.
[How]
We need to investigate why these accesses take longer than expected, but
for now we should disable the timeout on DCN35 to avoid this race
condition. Since the waits happen only at lower interrupt levels the
risk of taking too long at higher IRQ and causing a system watchdog
timeout are minimal.
CVSS Score
4.7
EPSS Score
0.0
Published
2024-10-09
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX
[Why & How]
It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller
number to create array dmub_callback & dmub_thread_offload has potential to access
item out of array bound. Fix it.
CVSS Score
7.8
EPSS Score
0.0
Published
2024-10-09
In the Linux kernel, the following vulnerability has been resolved:
crypto: stm32/cryp - call finalize with bh disabled
The finalize operation in interrupt mode produce a produces a spinlock
recursion warning. The reason is the fact that BH must be disabled
during this process.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-10-09
In the Linux kernel, the following vulnerability has been resolved:
smack: tcp: ipv4, fix incorrect labeling
Currently, Smack mirrors the label of incoming tcp/ipv4 connections:
when a label 'foo' connects to a label 'bar' with tcp/ipv4,
'foo' always gets 'foo' in returned ipv4 packets. So,
1) returned packets are incorrectly labeled ('foo' instead of 'bar')
2) 'bar' can write to 'foo' without being authorized to write.
Here is a scenario how to see this:
* Take two machines, let's call them C and S,
with active Smack in the default state
(no settings, no rules, no labeled hosts, only builtin labels)
* At S, add Smack rule 'foo bar w'
(labels 'foo' and 'bar' are instantiated at S at this moment)
* At S, at label 'bar', launch a program
that listens for incoming tcp/ipv4 connections
* From C, at label 'foo', connect to the listener at S.
(label 'foo' is instantiated at C at this moment)
Connection succeedes and works.
* Send some data in both directions.
* Collect network traffic of this connection.
All packets in both directions are labeled with the CIPSO
of the label 'foo'. Hence, label 'bar' writes to 'foo' without
being authorized, and even without ever being known at C.
If anybody cares: exactly the same happens with DCCP.
This behavior 1st manifested in release 2.6.29.4 (see Fixes below)
and it looks unintentional. At least, no explanation was provided.
I changed returned packes label into the 'bar',
to bring it into line with the Smack documentation claims.
CVSS Score
8.8
EPSS Score
0.004
Published
2024-10-09
In the Linux kernel, the following vulnerability has been resolved:
fsnotify: clear PARENT_WATCHED flags lazily
In some setups directories can have many (usually negative) dentries.
Hence __fsnotify_update_child_dentry_flags() function can take a
significant amount of time. Since the bulk of this function happens
under inode->i_lock this causes a significant contention on the lock
when we remove the watch from the directory as the
__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()
races with __fsnotify_update_child_dentry_flags() calls from
__fsnotify_parent() happening on children. This can lead upto softlockup
reports reported by users.
Fix the problem by calling fsnotify_update_children_dentry_flags() to
set PARENT_WATCHED flags only when parent starts watching children.
When parent stops watching children, clear false positive PARENT_WATCHED
flags lazily in __fsnotify_parent() for each accessed child.
CVSS Score
4.7
EPSS Score
0.0
Published
2024-10-09