Security Vulnerabilities
- CVEs Published In June 2024
VMware ESXi contains an out-of-bounds read vulnerability. A
malicious actor with local administrative privileges on a virtual
machine with an existing snapshot may trigger an out-of-bounds read
leading to a denial-of-service condition of the host.
The vCenter Server contains a denial-of-service vulnerability. A malicious actor with network access to vCenter Server may create a denial-of-service condition.
In the Linux kernel, the following vulnerability has been resolved:
x86/xen: Drop USERGS_SYSRET64 paravirt call
commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.
USERGS_SYSRET64 is used to return from a syscall via SYSRET, but
a Xen PV guest will nevertheless use the IRET hypercall, as there
is no sysret PV hypercall defined.
So instead of testing all the prerequisites for doing a sysret and
then mangling the stack for Xen PV again for doing an iret just use
the iret exit from the beginning.
This can easily be done via an ALTERNATIVE like it is done for the
sysenter compat case already.
It should be noted that this drops the optimization in Xen for not
restoring a few registers when returning to user mode, but it seems
as if the saved instructions in the kernel more than compensate for
this drop (a kernel build in a Xen PV guest was slightly faster with
this patch applied).
While at it remove the stale sysret32 remnants.
[ pawan: Brad Spengler and Salvatore Bonaccorso <carnil@debian.org>
reported a problem with the 5.10 backport commit edc702b4a820
("x86/entry_64: Add VERW just before userspace transition").
When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in
syscall_return_via_sysret path as USERGS_SYSRET64 is runtime
patched to:
.cpu_usergs_sysret64 = { 0x0f, 0x01, 0xf8,
0x48, 0x0f, 0x07 }, // swapgs; sysretq
which is missing CLEAR_CPU_BUFFERS. It turns out dropping
USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS
to be explicitly added to syscall_return_via_sysret path. Below
is with CONFIG_PARAVIRT_XXL=y and this patch applied:
syscall_return_via_sysret:
...
<+342>: swapgs
<+345>: xchg %ax,%ax
<+347>: verw -0x1a2(%rip) <------
<+354>: sysretq
]
In the Linux kernel, the following vulnerability has been resolved:
media: lgdt3306a: Add a check against null-pointer-def
The driver should check whether the client provides the platform_data.
The following log reveals it:
[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[ 29.612820] Call Trace:
[ 29.613030] <TASK>
[ 29.613201] dump_stack_lvl+0x56/0x6f
[ 29.613496] ? kmemdup+0x30/0x40
[ 29.613754] print_report.cold+0x494/0x6b7
[ 29.614082] ? kmemdup+0x30/0x40
[ 29.614340] kasan_report+0x8a/0x190
[ 29.614628] ? kmemdup+0x30/0x40
[ 29.614888] kasan_check_range+0x14d/0x1d0
[ 29.615213] memcpy+0x20/0x60
[ 29.615454] kmemdup+0x30/0x40
[ 29.615700] lgdt3306a_probe+0x52/0x310
[ 29.616339] i2c_device_probe+0x951/0xa90
HCL Connections contains a broken access control vulnerability that may allow unauthorized user to update data in certain scenarios.
A buffer overflow in PX4-Autopilot v1.12.3 allows attackers to cause a Denial of Service (DoS) via a crafted MavLink message.
PX4-Autopilot v1.14.3 was discovered to contain a buffer overflow via the topic_name parameter at /logger/logged_topics.cpp.
A leftover debug code vulnerability exists in the cli_server debug functionality of Tp-Link ER7206 Omada Gigabit VPN Router 1.4.1 Build 20240117 Rel.57421. A specially crafted series of network requests can lead to arbitrary command execution. An attacker can send a sequence of requests to trigger this vulnerability.
Lack of validation of origin in federation API in Conduit, allowing any remote server to impersonate any user from any server in most EDUs
Lack of privilege checking when processing a redaction in Conduit versions v0.6.0 and lower, allowing a local user to redact any message from users on the same server, given that they are able to send redaction events.