Vulnerabilidades

*** Pendiente de traducción *** Insufficient escaping in the report scheduler within Checkmk

*** Pendiente de traducción *** Use of an insecure temporary directory in the Windows License plugin for the Checkmk Windows Agent allows Privilege Escalation. This issue affects Checkmk: from 2.4.0 before 2.4.0p13, from 2.3.0 before 2.3.0p38, from 2.2.0 before 2.2.0p46, and all versions of 2.1.0 (EOL).

*** Pendiente de traducción *** Potential use of sensitive information in GET requests in Checkmk GmbH's Checkmk versions

*** Pendiente de traducción *** Apache Flink CDC version 3.4.0 was vulnerable to a SQL injection via maliciously crafted identifiers eg. crafted database name or crafted table name. Even through only the logged-in database user can trigger the attack, we recommend users update Flink CDC version to 3.5.0 which address this issue.

*** Pendiente de traducción *** IBM Aspera Faspex 5.0.0 through 5.0.13.1 could allow a privileged user to cause a denial of service from improperly validated API input due to excessive resource consumption.

*** Pendiente de traducción *** IBM Aspera 5.0.0 through 5.0.13.1 <br /> <br /> could disclose sensitive user information from the system to an authenticated user due to an observable discrepancy of returned data.

*** Pendiente de traducción *** A flaw was found in the integration of Active Directory and the System Security Services Daemon (SSSD) on Linux systems. In default configurations, the Kerberos local authentication plugin (sssd_krb5_localauth_plugin) is enabled, but a fallback to the an2ln plugin is possible. This fallback allows an attacker with permission to modify certain AD attributes (such as userPrincipalName or samAccountName) to impersonate privileged users, potentially resulting in unauthorized access or privilege escalation on domain-joined Linux hosts.

*** Pendiente de traducción *** IBM Aspera Faspex 5.0.0 through 5.0.13.1 uses a cross-domain policy file that includes domains that should not be trusted.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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()