Security Vulnerabilities - CVEs Published In June 2024
FreeRTOS-Plus-TCP is a lightweight TCP/IP stack for FreeRTOS. FreeRTOS-Plus-TCP versions 4.0.0 through 4.1.0 contain a buffer over-read issue in the DNS Response Parser when parsing domain names in a DNS response. A carefully crafted DNS response with domain name length value greater than the actual domain name length, could cause the parser to read beyond the DNS response buffer. This issue affects applications using DNS functionality of the FreeRTOS-Plus-TCP stack. Applications that do not use DNS functionality are not affected, even when the DNS functionality is enabled. This vulnerability has been patched in version 4.1.1.
CVSS Score
9.6
EPSS Score
0.006
Published
2024-06-24
Incorrect Calculation vulnerability in Renesas arm-trusted-firmware allows Local Execution of Code.
When checking whether a new image invades/overlaps with a previously loaded image the code neglects to consider a few cases. that could An attacker to bypass memory range restriction and overwrite an already loaded image partly or completely, which could result in code execution and bypass of secure boot.
CVSS Score
7.5
EPSS Score
0.0
Published
2024-06-24
Integer Underflow (Wrap or Wraparound) vulnerability in Renesas arm-trusted-firmware.
An integer underflow in image range check calculations could lead to bypassing address restrictions and loading of images to unallowed addresses.
CVSS Score
7.5
EPSS Score
0.0
Published
2024-06-24
Insufficient verification of data authenticity issue exists in NJ Series CPU Unit all versions and NX Series CPU Unit all versions. If a user program in the affected product is altered, the product may not be able to detect the alteration.
CVSS Score
7.5
EPSS Score
0.002
Published
2024-06-24
The CRUDDIY project is vulnerable to shell command injection via sending a crafted POST request to the application server.
The exploitation risk is limited since CRUDDIY is meant to be launched locally. Nevertheless, a user with the project running on their computer might visit a website which would send such a malicious request to the locally launched server.
CVSS Score
8.8
EPSS Score
0.003
Published
2024-06-24
In the Linux kernel, the following vulnerability has been resolved:
fpga: region: add owner module and take its refcount
The current implementation of the fpga region assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the region
during programming if the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_region
struct and use it to take the module's refcount. Modify the functions for
registering a region to take an additional owner module parameter and
rename them to avoid conflicts. Use the old function names for helper
macros that automatically set the module that registers the region as the
owner. This ensures compatibility with existing low-level control modules
and reduces the chances of registering a region without setting the owner.
Also, update the documentation to keep it consistent with the new interface
for registering an fpga region.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-06-24
In the Linux kernel, the following vulnerability has been resolved:
fpga: bridge: add owner module and take its refcount
The current implementation of the fpga bridge assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the bridge if
the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_bridge
struct and use it to take the module's refcount. Modify the function for
registering a bridge to take an additional owner module parameter and
rename it to avoid conflicts. Use the old function name for a helper macro
that automatically sets the module that registers the bridge as the owner.
This ensures compatibility with existing low-level control modules and
reduces the chances of registering a bridge without setting the owner.
Also, update the documentation to keep it consistent with the new interface
for registering an fpga bridge.
Other changes: opportunistically move put_device() from __fpga_bridge_get()
to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since
the bridge device is taken in these functions.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-06-24
In the Linux kernel, the following vulnerability has been resolved:
fpga: manager: add owner module and take its refcount
The current implementation of the fpga manager assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the manager if
the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_manager
struct and use it to take the module's refcount. Modify the functions for
registering the manager to take an additional owner module parameter and
rename them to avoid conflicts. Use the old function names for helper
macros that automatically set the module that registers the manager as the
owner. This ensures compatibility with existing low-level control modules
and reduces the chances of registering a manager without setting the owner.
Also, update the documentation to keep it consistent with the new interface
for registering an fpga manager.
Other changes: opportunistically move put_device() from __fpga_mgr_get() to
fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the
manager device is taken in these functions.
CVSS Score
5.5
EPSS Score
0.0
Published
2024-06-24
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: Only use reserved BCS instances for usm migrate exec queue
The GuC context scheduling queue is 2 entires deep, thus it is possible
for a migration job to be stuck behind a fault if migration exec queue
shares engines with user jobs. This can deadlock as the migrate exec
queue is required to service page faults. Avoid deadlock by only using
reserved BCS instances for usm migrate exec queue.
(cherry picked from commit 04f4a70a183a688a60fe3882d6e4236ea02cfc67)
CVSS Score
5.5
EPSS Score
0.0
Published
2024-06-24
In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: fix list corruption from reorder of WRITE ->lqueued
__blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start
is being executed.
If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in
the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one
stat instance being added in blk_cgroup_bio_start(), then the local
list in __blkcg_rstat_flush() could be corrupted.
Fix the issue by adding one barrier.
CVSS Score
8.4
EPSS Score
0.0
Published
2024-06-24