Vulnerabilities

Grafana is an open-source platform for monitoring and observability. <br /> The Grafana Alerting VictorOps integration was not properly protected and could be exposed to users with Viewer permission. <br /> Fixed in versions 11.5.0, 11.4.1, 11.3.3,  11.2.6, 11.1.11, 11.0.11 and 10.4.15

IBM Security Verify Directory 10.0 through 10.0.3 is vulnerable to a denial of service when sending an LDAP extended operation.

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.