Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Fix two issues in iommu_copy_struct_from_user()<br /> <br /> In the review for iommu_copy_struct_to_user() helper, Matt pointed out that<br /> a NULL pointer should be rejected prior to dereferencing it:<br /> https://lore.kernel.org/all/86881827-8E2D-461C-BDA3-FA8FD14C343C@nvidia.com<br /> <br /> And Alok pointed out a typo at the same time:<br /> https://lore.kernel.org/all/480536af-6830-43ce-a327-adbd13dc3f1d@oracle.com<br /> <br /> Since both issues were copied from iommu_copy_struct_from_user(), fix them<br /> first in the current header.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in session logoff<br /> <br /> The sess-&gt;user object can currently be in use by another thread, for<br /> example if another connection has sent a session setup request to<br /> bind to the session being free&amp;#39;d. The handler for that connection could<br /> be in the smb2_sess_setup function which makes use of sess-&gt;user.

IBM Security ReaQta EDR 3.12 could allow an attacker to perform unauthorized actions due to improper SSL certificate validation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: use sock_gen_put() when sk_state is TCP_TIME_WAIT<br /> <br /> It is possible for a pointer of type struct inet_timewait_sock to be<br /> returned from the functions __inet_lookup_established() and<br /> __inet6_lookup_established(). This can cause a crash when the<br /> returned pointer is of type struct inet_timewait_sock and<br /> sock_put() is called on it. The following is a crash call stack that<br /> shows sk-&gt;sk_wmem_alloc being accessed in sk_free() during the call to<br /> sock_put() on a struct inet_timewait_sock pointer. To avoid this issue,<br /> use sock_gen_put() instead of sock_put() when sk-&gt;sk_state<br /> is TCP_TIME_WAIT.<br /> <br /> mrdump.ko ipanic() + 120<br /> vmlinux notifier_call_chain(nr_to_call=-1, nr_calls=0) + 132<br /> vmlinux atomic_notifier_call_chain(val=0) + 56<br /> vmlinux panic() + 344<br /> vmlinux add_taint() + 164<br /> vmlinux end_report() + 136<br /> vmlinux kasan_report(size=0) + 236<br /> vmlinux report_tag_fault() + 16<br /> vmlinux do_tag_recovery() + 16<br /> vmlinux __do_kernel_fault() + 88<br /> vmlinux do_bad_area() + 28<br /> vmlinux do_tag_check_fault() + 60<br /> vmlinux do_mem_abort() + 80<br /> vmlinux el1_abort() + 56<br /> vmlinux el1h_64_sync_handler() + 124<br /> vmlinux &gt; 0xFFFFFFC080011294()<br /> vmlinux __lse_atomic_fetch_add_release(v=0xF2FFFF82A896087C)<br /> vmlinux __lse_atomic_fetch_sub_release(v=0xF2FFFF82A896087C)<br /> vmlinux arch_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C)<br /> + 8<br /> vmlinux raw_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C)<br /> + 8<br /> vmlinux atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C) + 8<br /> vmlinux __refcount_sub_and_test(i=1, r=0xF2FFFF82A896087C,<br /> oldp=0) + 8<br /> vmlinux __refcount_dec_and_test(r=0xF2FFFF82A896087C, oldp=0) + 8<br /> vmlinux refcount_dec_and_test(r=0xF2FFFF82A896087C) + 8<br /> vmlinux sk_free(sk=0xF2FFFF82A8960700) + 28<br /> vmlinux sock_put() + 48<br /> vmlinux tcp6_check_fraglist_gro() + 236<br /> vmlinux tcp6_gro_receive() + 624<br /> vmlinux ipv6_gro_receive() + 912<br /> vmlinux dev_gro_receive() + 1116<br /> vmlinux napi_gro_receive() + 196<br /> ccmni.ko ccmni_rx_callback() + 208<br /> ccmni.ko ccmni_queue_recv_skb() + 388<br /> ccci_dpmaif.ko dpmaif_rxq_push_thread() + 1088<br /> vmlinux kthread() + 268<br /> vmlinux 0xFFFFFFC08001F30C()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-mem: Add fix to avoid divide error<br /> <br /> For some SPI flash memory operations, dummy bytes are not mandatory. For<br /> example, in Winbond SPINAND flash memory devices, the `write_cache` and<br /> `update_cache` operation variants have zero dummy bytes. Calculating the<br /> duration for SPI memory operations with zero dummy bytes causes<br /> a divide error when `ncycles` is calculated in the<br /> spi_mem_calc_op_duration().<br /> <br /> Add changes to skip the &amp;#39;ncylcles&amp;#39; calculation for zero dummy bytes.<br /> <br /> Following divide error is fixed by this change:<br /> <br /> Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI<br /> ...<br /> <br /> ? do_trap+0xdb/0x100<br /> ? do_error_trap+0x75/0xb0<br /> ? spi_mem_calc_op_duration+0x56/0xb0<br /> ? exc_divide_error+0x3b/0x70<br /> ? spi_mem_calc_op_duration+0x56/0xb0<br /> ? asm_exc_divide_error+0x1b/0x20<br /> ? spi_mem_calc_op_duration+0x56/0xb0<br /> ? spinand_select_op_variant+0xee/0x190 [spinand]<br /> spinand_match_and_init+0x13e/0x1a0 [spinand]<br /> spinand_manufacturer_match+0x6e/0xa0 [spinand]<br /> spinand_probe+0x357/0x7f0 [spinand]<br /> ? kernfs_activate+0x87/0xd0<br /> spi_mem_probe+0x7a/0xb0<br /> spi_probe+0x7d/0x130

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix error handling path in bnxt_init_chip()<br /> <br /> WARN_ON() is triggered in __flush_work() if bnxt_init_chip() fails<br /> because we call cancel_work_sync() on dim work that has not been<br /> initialized.<br /> <br /> WARNING: CPU: 37 PID: 5223 at kernel/workqueue.c:4201 __flush_work.isra.0+0x212/0x230<br /> <br /> The driver relies on the BNXT_STATE_NAPI_DISABLED bit to check if dim<br /> work has already been cancelled. But in the bnxt_open() path,<br /> BNXT_STATE_NAPI_DISABLED is not set and this causes the error<br /> path to think that it needs to cancel the uninitalized dim work.<br /> Fix it by setting BNXT_STATE_NAPI_DISABLED during initialization.<br /> The bit will be cleared when we enable NAPI and initialize dim work.

An unauthenticated blind SQL injection vulnerability exists in RSI Queue Management System v3.0 within the TaskID parameter of the get request handler. Attackers can remotely inject time-delayed SQL payloads to induce server response delays, enabling time-based inference and iterative extraction of sensitive database contents without authentication.

The vCenter Server contains an authenticated command-execution vulnerability. A malicious actor with privileges to create or modify alarms and run script action may exploit this issue to run arbitrary commands on the vCenter Server.

VMware ESXi contains a denial-of-service vulnerability that occurs when performing a guest operation. A malicious actor with guest operation privileges on a VM, who is already authenticated through vCenter Server or ESXi may trigger this issue to create a denial-of-service condition of guest VMs with VMware Tools running and guest operations enabled.

VMware ESXi, Workstation, and Fusion contain a denial-of-service vulnerability due to certain guest options. A malicious actor with non-administrative privileges within a guest operating system may be able to exploit this issue by exhausting memory of the host process leading to a denial-of-service condition.

VMware ESXi and vCenter Server contain a reflected cross-site scripting vulnerability due to improper input validation. A malicious actor with network access to the login page of certain ESXi host or vCenter Server URL paths may exploit this issue to steal cookies or redirect to malicious websites.

IBM Security ReaQta EDR 3.12 could allow an attacker to spoof a trusted entity by interfering with the communication path between the host and client.