Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix incorrect io_kiocb reference in io_link_skb<br /> <br /> In io_link_skb function, there is a bug where prev_notif is incorrectly<br /> assigned using &amp;#39;nd&amp;#39; instead of &amp;#39;prev_nd&amp;#39;. This causes the context<br /> validation check to compare the current notification with itself instead<br /> of comparing it with the previous notification.<br /> <br /> Fix by using the correct prev_nd parameter when obtaining prev_notif.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix untrusted unsigned subtract<br /> <br /> Fix the following Smatch static checker warning:<br /> <br /> net/rxrpc/rxgk_app.c:65 rxgk_yfs_decode_ticket()<br /> warn: untrusted unsigned subtract. &amp;#39;ticket_len - 10 * 4&amp;#39;<br /> <br /> by prechecking the length of what we&amp;#39;re trying to extract in two places in<br /> the token and decoding for a response packet.<br /> <br /> Also use sizeof() on the struct we&amp;#39;re extracting rather specifying the size<br /> numerically to be consistent with the other related statements.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/amd/pgtbl: Fix possible race while increase page table level<br /> <br /> The AMD IOMMU host page table implementation supports dynamic page table levels<br /> (up to 6 levels), starting with a 3-level configuration that expands based on<br /> IOVA address. The kernel maintains a root pointer and current page table level<br /> to enable proper page table walks in alloc_pte()/fetch_pte() operations.<br /> <br /> The IOMMU IOVA allocator initially starts with 32-bit address and onces its<br /> exhuasted it switches to 64-bit address (max address is determined based<br /> on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU<br /> driver increases page table level.<br /> <br /> But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads<br /> pgtable-&gt;[root/mode] without lock. So its possible that in exteme corner case,<br /> when increase_address_space() is updating pgtable-&gt;[root/mode], fetch_pte()<br /> reads wrong page table level (pgtable-&gt;mode). It does compare the value with<br /> level encoded in page table and returns NULL. This will result is<br /> iommu_unmap ops to fail and upper layer may retry/log WARN_ON.<br /> <br /> CPU 0 CPU 1<br /> ------ ------<br /> map pages unmap pages<br /> alloc_pte() -&gt; increase_address_space() iommu_v1_unmap_pages() -&gt; fetch_pte()<br /> pgtable-&gt;root = pte (new root value)<br /> READ pgtable-&gt;[mode/root]<br /> Reads new root, old mode<br /> Updates mode (pgtable-&gt;mode += 1)<br /> <br /> Since Page table level updates are infrequent and already synchronized with a<br /> spinlock, implement seqcount to enable lock-free read operations on the read path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: acpi: initialize acpi_gpio_info struct<br /> <br /> Since commit 7c010d463372 ("gpiolib: acpi: Make sure we fill struct<br /> acpi_gpio_info"), uninitialized acpi_gpio_info struct are passed to<br /> __acpi_find_gpio() and later in the call stack info-&gt;quirks is used in<br /> acpi_populate_gpio_lookup. This breaks the i2c_hid_cpi driver:<br /> <br /> [ 58.122916] i2c_hid_acpi i2c-UNIW0001:00: HID over i2c has not been provided an Int IRQ<br /> [ 58.123097] i2c_hid_acpi i2c-UNIW0001:00: probe with driver i2c_hid_acpi failed with error -22<br /> <br /> Fix this by initializing the acpi_gpio_info pass to __acpi_find_gpio()

In Flowmon versions prior to 12.5.5, a vulnerability has been identified that allows a user with administrator privileges and access to the management interface to execute additional unintended commands within scripts intended for troubleshooting purposes.

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.