Vulnerabilities

SQL injection vulnerability in TeamCal Neo, version 3.8.2. This could allow an attacker to retrieve, update and delete all database information by injecting a malicious SQL statement via the ‘abs’ parameter in ‘/teamcal/src/index.php’.

Reflected Cross-Site Scripting (XSS) in TeamCal Neo, version 3.8.2. This allows an attacker to execute malicious JavaScript code, after injecting code via the ‘abs’ parameter in ‘/teamcal/src/index.php’.

Local privilege escalation due to DLL hijacking vulnerability. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 39378.

Local privilege escalation due to unquoted search path vulnerability. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 39378.

Local privilege escalation due to DLL hijacking vulnerability. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 39378.

Local privilege escalation due to DLL hijacking vulnerability. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 39378.

Local privilege escalation due to DLL hijacking vulnerability. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 39378.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: add the missing error handling inside get_canonical_dev_path<br /> <br /> Inside function get_canonical_dev_path(), we call d_path() to get the<br /> final device path.<br /> <br /> But d_path() can return error, and in that case the next strscpy() call<br /> will trigger an invalid memory access.<br /> <br /> Add back the missing error handling for d_path().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pktgen: Avoid out-of-bounds access in get_imix_entries<br /> <br /> Passing a sufficient amount of imix entries leads to invalid access to the<br /> pkt_dev-&gt;imix_entries array because of the incorrect boundary check.<br /> <br /> UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24<br /> index 20 is out of range for type &amp;#39;imix_pkt [20]&amp;#39;<br /> CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Call Trace:<br /> <br /> dump_stack_lvl lib/dump_stack.c:117<br /> __ubsan_handle_out_of_bounds lib/ubsan.c:429<br /> get_imix_entries net/core/pktgen.c:874<br /> pktgen_if_write net/core/pktgen.c:1063<br /> pde_write fs/proc/inode.c:334<br /> proc_reg_write fs/proc/inode.c:346<br /> vfs_write fs/read_write.c:593<br /> ksys_write fs/read_write.c:644<br /> do_syscall_64 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> [ fp: allow to fill the array completely; minor changelog cleanup ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: fix lockup on tx to unregistering netdev with carrier<br /> <br /> Commit in a fixes tag attempted to fix the issue in the following<br /> sequence of calls:<br /> <br /> do_output<br /> -&gt; ovs_vport_send<br /> -&gt; dev_queue_xmit<br /> -&gt; __dev_queue_xmit<br /> -&gt; netdev_core_pick_tx<br /> -&gt; skb_tx_hash<br /> <br /> When device is unregistering, the &amp;#39;dev-&gt;real_num_tx_queues&amp;#39; goes to<br /> zero and the &amp;#39;while (unlikely(hash &gt;= qcount))&amp;#39; loop inside the<br /> &amp;#39;skb_tx_hash&amp;#39; becomes infinite, locking up the core forever.<br /> <br /> But unfortunately, checking just the carrier status is not enough to<br /> fix the issue, because some devices may still be in unregistering<br /> state while reporting carrier status OK.<br /> <br /> One example of such device is a net/dummy. It sets carrier ON<br /> on start, but it doesn&amp;#39;t implement .ndo_stop to set the carrier off.<br /> And it makes sense, because dummy doesn&amp;#39;t really have a carrier.<br /> Therefore, while this device is unregistering, it&amp;#39;s still easy to hit<br /> the infinite loop in the skb_tx_hash() from the OVS datapath. There<br /> might be other drivers that do the same, but dummy by itself is<br /> important for the OVS ecosystem, because it is frequently used as a<br /> packet sink for tcpdump while debugging OVS deployments. And when the<br /> issue is hit, the only way to recover is to reboot.<br /> <br /> Fix that by also checking if the device is running. The running<br /> state is handled by the net core during unregistering, so it covers<br /> unregistering case better, and we don&amp;#39;t really need to send packets<br /> to devices that are not running anyway.<br /> <br /> While only checking the running state might be enough, the carrier<br /> check is preserved. The running and the carrier states seem disjoined<br /> throughout the code and different drivers. And other core functions<br /> like __dev_direct_xmit() check both before attempting to transmit<br /> a packet. So, it seems safer to check both flags in OVS as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix bpf_sk_select_reuseport() memory leak<br /> <br /> As pointed out in the original comment, lookup in sockmap can return a TCP<br /> ESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF<br /> set before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb<br /> does not imply a non-refcounted socket.<br /> <br /> Drop sk&amp;#39;s reference in both error paths.<br /> <br /> unreferenced object 0xffff888101911800 (size 2048):<br /> comm "test_progs", pid 44109, jiffies 4297131437<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 9336483b):<br /> __kmalloc_noprof+0x3bf/0x560<br /> __reuseport_alloc+0x1d/0x40<br /> reuseport_alloc+0xca/0x150<br /> reuseport_attach_prog+0x87/0x140<br /> sk_reuseport_attach_bpf+0xc8/0x100<br /> sk_setsockopt+0x1181/0x1990<br /> do_sock_setsockopt+0x12b/0x160<br /> __sys_setsockopt+0x7b/0xc0<br /> __x64_sys_setsockopt+0x1b/0x30<br /> do_syscall_64+0x93/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: bnxt: always recalculate features after XDP clearing, fix null-deref<br /> <br /> Recalculate features when XDP is detached.<br /> <br /> Before:<br /> # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp<br /> # ip li set dev eth0 xdp off<br /> # ethtool -k eth0 | grep gro<br /> rx-gro-hw: off [requested on]<br /> <br /> After:<br /> # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp<br /> # ip li set dev eth0 xdp off<br /> # ethtool -k eth0 | grep gro<br /> rx-gro-hw: on<br /> <br /> The fact that HW-GRO doesn&amp;#39;t get re-enabled automatically is just<br /> a minor annoyance. The real issue is that the features will randomly<br /> come back during another reconfiguration which just happens to invoke<br /> netdev_update_features(). The driver doesn&amp;#39;t handle reconfiguring<br /> two things at a time very robustly.<br /> <br /> Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in<br /> __bnxt_reserve_rings()") we only reconfigure the RSS hash table<br /> if the "effective" number of Rx rings has changed. If HW-GRO is<br /> enabled "effective" number of rings is 2x what user sees.<br /> So if we are in the bad state, with HW-GRO re-enablement "pending"<br /> after XDP off, and we lower the rings by / 2 - the HW-GRO rings<br /> doing 2x and the ethtool -L doing / 2 may cancel each other out,<br /> and the:<br /> <br /> if (old_rx_rings != bp-&gt;hw_resc.resv_rx_rings &amp;&amp;<br /> <br /> condition in __bnxt_reserve_rings() will be false.<br /> The RSS map won&amp;#39;t get updated, and we&amp;#39;ll crash with:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000168<br /> RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0<br /> bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180<br /> __bnxt_setup_vnic_p5+0x58/0x110<br /> bnxt_init_nic+0xb72/0xf50<br /> __bnxt_open_nic+0x40d/0xab0<br /> bnxt_open_nic+0x2b/0x60<br /> ethtool_set_channels+0x18c/0x1d0<br /> <br /> As we try to access a freed ring.<br /> <br /> The issue is present since XDP support was added, really, but<br /> prior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in<br /> __bnxt_reserve_rings()") it wasn&amp;#39;t causing major issues.