Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp/dccp: Don&amp;#39;t use timer_pending() in reqsk_queue_unlink().<br /> <br /> Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().<br /> <br /> """<br /> We are seeing a use-after-free from a bpf prog attached to<br /> trace_tcp_retransmit_synack. The program passes the req-&gt;sk to the<br /> bpf_sk_storage_get_tracing kernel helper which does check for null<br /> before using it.<br /> """<br /> <br /> The commit 83fccfc3940c ("inet: fix potential deadlock in<br /> reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not<br /> to call del_timer_sync() from reqsk_timer_handler(), but it introduced a<br /> small race window.<br /> <br /> Before the timer is called, expire_timers() calls detach_timer(timer, true)<br /> to clear timer-&gt;entry.pprev and marks it as not pending.<br /> <br /> If reqsk_queue_unlink() checks timer_pending() just after expire_timers()<br /> calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will<br /> continue running and send multiple SYN+ACKs until it expires.<br /> <br /> The reported UAF could happen if req-&gt;sk is close()d earlier than the timer<br /> expiration, which is 63s by default.<br /> <br /> The scenario would be<br /> <br /> 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),<br /> but del_timer_sync() is missed<br /> <br /> 2. reqsk timer is executed and scheduled again<br /> <br /> 3. req-&gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but<br /> reqsk timer still has another one, and inet_csk_accept() does not<br /> clear req-&gt;sk for non-TFO sockets<br /> <br /> 4. sk is close()d<br /> <br /> 5. reqsk timer is executed again, and BPF touches req-&gt;sk<br /> <br /> Let&amp;#39;s not use timer_pending() by passing the caller context to<br /> __inet_csk_reqsk_queue_drop().<br /> <br /> Note that reqsk timer is pinned, so the issue does not happen in most<br /> use cases. [1]<br /> <br /> [0]<br /> BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0<br /> <br /> Use-after-free read at 0x00000000a891fb3a (in kfence-#1):<br /> bpf_sk_storage_get_tracing+0x2e/0x1b0<br /> bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda<br /> bpf_trace_run2+0x4c/0xc0<br /> tcp_rtx_synack+0xf9/0x100<br /> reqsk_timer_handler+0xda/0x3d0<br /> run_timer_softirq+0x292/0x8a0<br /> irq_exit_rcu+0xf5/0x320<br /> sysvec_apic_timer_interrupt+0x6d/0x80<br /> asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> intel_idle_irq+0x5a/0xa0<br /> cpuidle_enter_state+0x94/0x273<br /> cpu_startup_entry+0x15e/0x260<br /> start_secondary+0x8a/0x90<br /> secondary_startup_64_no_verify+0xfa/0xfb<br /> <br /> kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6<br /> <br /> allocated by task 0 on cpu 9 at 260507.901592s:<br /> sk_prot_alloc+0x35/0x140<br /> sk_clone_lock+0x1f/0x3f0<br /> inet_csk_clone_lock+0x15/0x160<br /> tcp_create_openreq_child+0x1f/0x410<br /> tcp_v6_syn_recv_sock+0x1da/0x700<br /> tcp_check_req+0x1fb/0x510<br /> tcp_v6_rcv+0x98b/0x1420<br /> ipv6_list_rcv+0x2258/0x26e0<br /> napi_complete_done+0x5b1/0x2990<br /> mlx5e_napi_poll+0x2ae/0x8d0<br /> net_rx_action+0x13e/0x590<br /> irq_exit_rcu+0xf5/0x320<br /> common_interrupt+0x80/0x90<br /> asm_common_interrupt+0x22/0x40<br /> cpuidle_enter_state+0xfb/0x273<br /> cpu_startup_entry+0x15e/0x260<br /> start_secondary+0x8a/0x90<br /> secondary_startup_64_no_verify+0xfa/0xfb<br /> <br /> freed by task 0 on cpu 9 at 260507.927527s:<br /> rcu_core_si+0x4ff/0xf10<br /> irq_exit_rcu+0xf5/0x320<br /> sysvec_apic_timer_interrupt+0x6d/0x80<br /> asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> cpuidle_enter_state+0xfb/0x273<br /> cpu_startup_entry+0x15e/0x260<br /> start_secondary+0x8a/0x90<br /> secondary_startup_64_no_verify+0xfa/0xfb

A flaw was found in Undertow package. Using the FormAuthenticationMechanism, a malicious user could trigger a Denial of Service by sending crafted requests, leading the server to an OutofMemory error, exhausting the server&amp;#39;s memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix shift-out-of-bounds bug<br /> <br /> Fix a shift-out-of-bounds bug reported by UBSAN when running<br /> VM with MTE enabled host kernel.<br /> <br /> UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14<br /> shift exponent 33 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34<br /> Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024<br /> Call trace:<br /> dump_backtrace+0xa0/0x128<br /> show_stack+0x20/0x38<br /> dump_stack_lvl+0x74/0x90<br /> dump_stack+0x18/0x28<br /> __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0<br /> reset_clidr+0x10c/0x1c8<br /> kvm_reset_sys_regs+0x50/0x1c8<br /> kvm_reset_vcpu+0xec/0x2b0<br /> __kvm_vcpu_set_target+0x84/0x158<br /> kvm_vcpu_set_target+0x138/0x168<br /> kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0<br /> kvm_arch_vcpu_ioctl+0x28c/0x4b8<br /> kvm_vcpu_ioctl+0x4bc/0x7a8<br /> __arm64_sys_ioctl+0xb4/0x100<br /> invoke_syscall+0x70/0x100<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x3c/0x158<br /> el0t_64_sync_handler+0x120/0x130<br /> el0t_64_sync+0x194/0x198

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/core: Disable page allocation in task_tick_mm_cid()<br /> <br /> With KASAN and PREEMPT_RT enabled, calling task_work_add() in<br /> task_tick_mm_cid() may cause the following splat.<br /> <br /> [ 63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> [ 63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe<br /> [ 63.696416] preempt_count: 10001, expected: 0<br /> [ 63.696416] RCU nest depth: 1, expected: 1<br /> <br /> This problem is caused by the following call trace.<br /> <br /> sched_tick() [ acquire rq-&gt;__lock ]<br /> -&gt; task_tick_mm_cid()<br /> -&gt; task_work_add()<br /> -&gt; __kasan_record_aux_stack()<br /> -&gt; kasan_save_stack()<br /> -&gt; stack_depot_save_flags()<br /> -&gt; alloc_pages_mpol_noprof()<br /> -&gt; __alloc_pages_noprof()<br /> -&gt; get_page_from_freelist()<br /> -&gt; rmqueue()<br /> -&gt; rmqueue_pcplist()<br /> -&gt; __rmqueue_pcplist()<br /> -&gt; rmqueue_bulk()<br /> -&gt; rt_spin_lock()<br /> <br /> The rq lock is a raw_spinlock_t. We can&amp;#39;t sleep while holding<br /> it. IOW, we can&amp;#39;t call alloc_pages() in stack_depot_save_flags().<br /> <br /> The task_tick_mm_cid() function with its task_work_add() call was<br /> introduced by commit 223baf9d17f2 ("sched: Fix performance regression<br /> introduced by mm_cid") in v6.4 kernel.<br /> <br /> Fortunately, there is a kasan_record_aux_stack_noalloc() variant that<br /> calls stack_depot_save_flags() while not allowing it to allocate<br /> new pages. To allow task_tick_mm_cid() to use task_work without<br /> page allocation, a new TWAF_NO_ALLOC flag is added to enable calling<br /> kasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack()<br /> if set. The task_tick_mm_cid() function is modified to add this new flag.<br /> <br /> The possible downside is the missing stack trace in a KASAN report due<br /> to new page allocation required when task_work_add_noallloc() is called<br /> which should be rare.

Zohocorp ManageEngine EndPoint Central versions 11.3.2416.21 and below, 11.3.2428.9 and below are vulnerable to Arbitrary File Deletion in the agent installed machines.

A flaw was found in hibernate-validator&amp;#39;s &amp;#39;isValid&amp;#39; method in the org.hibernate.validator.internal.constraintvalidators.hv.SafeHtmlValidator class, which can be bypassed by omitting the tag ending in a less-than character. Browsers may render an invalid html, allowing HTML injection or Cross-Site-Scripting (XSS) attacks.

HCL BigFix Compliance is affected by unvalidated redirects and forwards. The HOST header can be manipulated by an attacker and as a result, it can poison the web cache and provide back to users being served the page.

HCL BigFix Compliance is vulnerable to the generation of error messages containing sensitive information. Detailed error messages can provide enticement information or expose information about its environment, users, or associated data.

HCL BigFix Compliance is affected by a missing secure flag on a cookie. If a secure flag is not set, cookies may be stolen by an attacker using XSS, resulting in unauthorized access or session cookies could be transferred over an unencrypted channel.

Allocation of Resources Without Limits or Throttling vulnerability in Apache Tomcat.<br /> <br /> This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M20, from 10.1.0-M1 through 10.1.24, from 9.0.13 through 9.0.89.<br /> <br /> <br /> The following versions were EOL at the time the CVE was created but are <br /> known to be affected: 8.5.35 through 8.5.100 and 7.0.92 through 7.0.109. Other EOL versions may also be affected.<br /> <br /> <br /> Users are recommended to upgrade to version 11.0.0-M21, 10.1.25, or 9.0.90, which fixes the issue.<br /> <br /> <br /> <br /> Apache Tomcat, under certain configurations on any platform, allows an attacker to cause an OutOfMemoryError by abusing the TLS handshake process.

The WP Booking Calendar WordPress plugin before 10.6.3 does not sanitise and escape some of its Widgets settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).

A vulnerability classified as critical has been found in Guangzhou Tuchuang Computer Software Development Interlib Library Cluster Automation Management System up to 2.0.1. This affects an unknown part of the file /interlib/admin/SysLib?cmdACT=inputLIBCODE&amp;mod=batchXSL&amp;xsl=editLIBCODE.xsl&amp;libcodes=&amp;ROWID=. The manipulation of the argument sql leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.