Vulnerabilities

A vulnerability exists in the Progress Flowmon web application prior to version 12.5.5, whereby a user who clicks a malicious link provided by an attacker may inadvertently trigger unintended actions within their authenticated session.

GitLab has remediated an issue in GitLab EE affecting all versions from 18.3 to 18.3.4, 18.4 to 18.4.2 that, under certain conditions, could have allowed authenticated users with read-only API tokens to perform unauthorized write operations on vulnerability records by exploiting incorrectly scoped GraphQL mutations.

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 5.2 prior to 18.2.8, 18.3 prior to 18.3.4, and 18.4 prior to 18.4.2 that could have allowed an authenticated attacker to create a denial of service condition by configuring malicious webhook endpoints that send crafted HTTP responses.

The Betheme theme for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘page_title’ parameter in all versions up to, and including, 28.1.6 due to insufficient input sanitization and output escaping of theme breadcrumbs. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.12 to 18.2.8, 18.3 to 18.3.4, and 18.4 to 18.4.2 that could make the GitLab instance unresponsive or severely degraded by sending crafted GraphQL queries requesting large repository blobs.

The Slider Revolution plugin for WordPress is vulnerable to unauthorized access and modification of data due to a missing capability check on several functions in all versions up to, and including, 6.7.37. This makes it possible for authenticated attackers, with Contributor-level access and above, to install and activate plugin add-ons, create sliders, and download arbitrary files.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: amd: acp: Fix incorrect retrival of acp_chip_info<br /> <br /> Use dev_get_drvdata(dev-&gt;parent) instead of dev_get_platdata(dev)<br /> to correctly obtain acp_chip_info members in the acp I2S driver.<br /> Previously, some members were not updated properly due to incorrect<br /> data access, which could potentially lead to null pointer<br /> dereferences.<br /> <br /> This issue was missed in the earlier commit<br /> ("ASoC: amd: acp: Fix NULL pointer deref in acp_i2s_set_tdm_slot"),<br /> which only addressed set_tdm_slot(). This change ensures that all<br /> relevant functions correctly retrieve acp_chip_info, preventing<br /> further null pointer dereference issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/s390: Make attach succeed when the device was surprise removed<br /> <br /> When a PCI device is removed with surprise hotplug, there may still be<br /> attempts to attach the device to the default domain as part of tear down<br /> via (__iommu_release_dma_ownership()), or because the removal happens<br /> during probe (__iommu_probe_device()). In both cases zpci_register_ioat()<br /> fails with a cc value indicating that the device handle is invalid. This<br /> is because the device is no longer part of the instance as far as the<br /> hypervisor is concerned.<br /> <br /> Currently this leads to an error return and s390_iommu_attach_device()<br /> fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()<br /> because attaching to the default domain must never fail.<br /> <br /> With the device fenced by the hypervisor no DMAs to or from memory are<br /> possible and the IOMMU translations have no effect. Proceed as if the<br /> registration was successful and let the hotplug event handling clean up<br /> the device.<br /> <br /> This is similar to how devices in the error state are handled since<br /> commit 59bbf596791b ("iommu/s390: Make attach succeed even if the device<br /> is in error state") except that for removal the domain will not be<br /> registered later. This approach was also previously discussed at the<br /> link.<br /> <br /> Handle both cases, error state and removal, in a helper which checks if<br /> the error needs to be propagated or ignored. Avoid magic number<br /> condition codes by using the pre-existing, but never used, defines for<br /> PCI load/store condition codes and rename them to reflect that they<br /> apply to all PCI instructions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: increase scan_ies_len for S1G<br /> <br /> Currently the S1G capability element is not taken into account<br /> for the scan_ies_len, which leads to a buffer length validation<br /> failure in ieee80211_prep_hw_scan() and subsequent WARN in<br /> __ieee80211_start_scan(). This prevents hw scanning from functioning.<br /> To fix ensure we accommodate for the S1G capability length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Clear tcp_sk(sk)-&gt;fastopen_rsk in tcp_disconnect().<br /> <br /> syzbot reported the splat below where a socket had tcp_sk(sk)-&gt;fastopen_rsk<br /> in the TCP_ESTABLISHED state. [0]<br /> <br /> syzbot reused the server-side TCP Fast Open socket as a new client before<br /> the TFO socket completes 3WHS:<br /> <br /> 1. accept()<br /> 2. connect(AF_UNSPEC)<br /> 3. connect() to another destination<br /> <br /> As of accept(), sk-&gt;sk_state is TCP_SYN_RECV, and tcp_disconnect() changes<br /> it to TCP_CLOSE and makes connect() possible, which restarts timers.<br /> <br /> Since tcp_disconnect() forgot to clear tcp_sk(sk)-&gt;fastopen_rsk, the<br /> retransmit timer triggered the warning and the intended packet was not<br /> retransmitted.<br /> <br /> Let&amp;#39;s call reqsk_fastopen_remove() in tcp_disconnect().<br /> <br /> [0]:<br /> WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))<br /> Modules linked in:<br /> CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))<br /> Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e<br /> RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293<br /> RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017<br /> RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400<br /> RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8<br /> R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540<br /> R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0<br /> FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> tcp_write_timer (net/ipv4/tcp_timer.c:738)<br /> call_timer_fn (kernel/time/timer.c:1747)<br /> __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)<br /> timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)<br /> tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)<br /> __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))<br /> tmigr_handle_remote (kernel/time/timer_migration.c:1096)<br /> handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)<br /> irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)<br /> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: don&amp;#39;t fail igc_probe() on LED setup error<br /> <br /> When igc_led_setup() fails, igc_probe() fails and triggers kernel panic<br /> in free_netdev() since unregister_netdev() is not called. [1]<br /> This behavior can be tested using fault-injection framework, especially<br /> the failslab feature. [2]<br /> <br /> Since LED support is not mandatory, treat LED setup failures as<br /> non-fatal and continue probe with a warning message, consequently<br /> avoiding the kernel panic.<br /> <br /> [1]<br /> kernel BUG at net/core/dev.c:12047!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:free_netdev+0x278/0x2b0<br /> [...]<br /> Call Trace:<br /> <br /> igc_probe+0x370/0x910<br /> local_pci_probe+0x3a/0x80<br /> pci_device_probe+0xd1/0x200<br /> [...]<br /> <br /> [2]<br /> #!/bin/bash -ex<br /> <br /> FAILSLAB_PATH=/sys/kernel/debug/failslab/<br /> DEVICE=0000:00:05.0<br /> START_ADDR=$(grep " igc_led_setup" /proc/kallsyms \<br /> | awk &amp;#39;{printf("0x%s", $1)}&amp;#39;)<br /> END_ADDR=$(printf "0x%x" $((START_ADDR + 0x100)))<br /> <br /> echo $START_ADDR &gt; $FAILSLAB_PATH/require-start<br /> echo $END_ADDR &gt; $FAILSLAB_PATH/require-end<br /> echo 1 &gt; $FAILSLAB_PATH/times<br /> echo 100 &gt; $FAILSLAB_PATH/probability<br /> echo N &gt; $FAILSLAB_PATH/ignore-gfp-wait<br /> <br /> echo $DEVICE &gt; /sys/bus/pci/drivers/igc/bind

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: sunxi-ng: mp: Fix dual-divider clock rate readback<br /> <br /> When dual-divider clock support was introduced, the P divider offset was<br /> left out of the .recalc_rate readback function. This causes the clock<br /> rate to become bogus or even zero (possibly due to the P divider being<br /> 1, leading to a divide-by-zero).<br /> <br /> Fix this by incorporating the P divider offset into the calculation.