Vulnerabilities

OneBlog v2.3.6 was discovered to contain a template injection vulnerability via the template management department.

PHPGurukul Small CRM 3.0 is vulnerable to Cross Site Scripting (XSS) via a crafted payload injected into the name in the profile.php.

A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. This vulnerability affects the function bfd_malloc of the file libbfd.c of the component ld. The manipulation leads to memory leak. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

A vulnerability was found in GNU Binutils 2.43. It has been rated as problematic. This issue affects the function xmemdup of the file xmemdup.c of the component ld. The manipulation leads to memory leak. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

PAM-PKCS#11 is a Linux-PAM login module that allows a X.509 certificate based user login. Prior to version 0.6.13, if cert_policy is set to none (the default value), then pam_pkcs11 will only check if the user is capable of logging into the token. An attacker may create a different token with the user's public data (e.g. the user's certificate) and a PIN known to the attacker. If no signature with the private key is required, then the attacker may now login as user with that created token. The default to *not* check the private key's signature has been changed with commit commi6638576892b59a99389043c90a1e7dd4d783b921, so that all versions starting with pam_pkcs11-0.6.0 should be affected. As a workaround, in `pam_pkcs11.conf`, set at least `cert_policy = signature;`.

OpenProject is open-source, web-based project management software. In versions prior to 15.2.1, the application fails to properly sanitize user input before displaying it in the Group Management section. Groups created with HTML script tags are not properly escaped before rendering them in a project. The issue has been resolved in OpenProject version 15.2.1. Those who are unable to upgrade may apply the patch manually.

Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Starting in version 0.3.2 and prior to versions 0.3.8, 0.4.19, and 0.5.6, there is a possibility for denial of service by memory exhaustion in `net-imap`'s response parser. At any time while the client is connected, a malicious server can send can send highly compressed `uid-set` data which is automatically read by the client's receiver thread. The response parser uses `Range#to_a` to convert the `uid-set` data into arrays of integers, with no limitation on the expanded size of the ranges. Versions 0.3.8, 0.4.19, 0.5.6, and higher fix this issue. Additional details for proper configuration of fixed versions and backward compatibility are available in the GitHub Security Advisory.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachestat: fix page cache statistics permission checking<br /> <br /> When the &amp;#39;cachestat()&amp;#39; system call was added in commit cf264e1329fb<br /> ("cachestat: implement cachestat syscall"), it was meant to be a much<br /> more convenient (and performant) version of mincore() that didn&amp;#39;t need<br /> mapping things into the user virtual address space in order to work.<br /> <br /> But it ended up missing the "check for writability or ownership" fix for<br /> mincore(), done in commit 134fca9063ad ("mm/mincore.c: make mincore()<br /> more conservative").<br /> <br /> This just adds equivalent logic to &amp;#39;cachestat()&amp;#39;, modified for the file<br /> context (rather than vma).

PAM-PKCS#11 is a Linux-PAM login module that allows a X.509 certificate based user login. In versions 0.6.12 and prior, the pam_pkcs11 module segfaults when a user presses ctrl-c/ctrl-d when they are asked for a PIN. When a user enters no PIN at all, `pam_get_pwd` will never initialize the password buffer pointer and as such `cleanse` will try to dereference an uninitialized pointer. On my system this pointer happens to have the value 3 most of the time when running sudo and as such it will segfault. The most likely impact to a system affected by this issue is an availability impact due to a daemon that uses PAM crashing. As of time of publication, a patch for the issue is unavailable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: zswap: properly synchronize freeing resources during CPU hotunplug<br /> <br /> In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the<br /> current CPU at the beginning of the operation is retrieved and used<br /> throughout. However, since neither preemption nor migration are disabled,<br /> it is possible that the operation continues on a different CPU.<br /> <br /> If the original CPU is hotunplugged while the acomp_ctx is still in use,<br /> we run into a UAF bug as some of the resources attached to the acomp_ctx<br /> are freed during hotunplug in zswap_cpu_comp_dead() (i.e. <br /> acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).<br /> <br /> The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use<br /> crypto_acomp API for hardware acceleration") when the switch to the<br /> crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was<br /> retrieved using get_cpu_ptr() which disables preemption and makes sure the<br /> CPU cannot go away from under us. Preemption cannot be disabled with the<br /> crypto_acomp API as a sleepable context is needed.<br /> <br /> Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating<br /> and freeing resources with compression/decompression paths. Make sure<br /> that acomp_ctx.req is NULL when the resources are freed. In the<br /> compression/decompression paths, check if acomp_ctx.req is NULL after<br /> acquiring the mutex (meaning the CPU was offlined) and retry on the new<br /> CPU.<br /> <br /> The initialization of acomp_ctx.mutex is moved from the CPU hotplug<br /> callback to the pool initialization where it belongs (where the mutex is<br /> allocated). In addition to adding clarity, this makes sure that CPU<br /> hotplug cannot reinitialize a mutex that is already locked by<br /> compression/decompression.<br /> <br /> Previously a fix was attempted by holding cpus_read_lock() [1]. This<br /> would have caused a potential deadlock as it is possible for code already<br /> holding the lock to fall into reclaim and enter zswap (causing a<br /> deadlock). A fix was also attempted using SRCU for synchronization, but<br /> Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug<br /> notifiers [2].<br /> <br /> Alternative fixes that were considered/attempted and could have worked:<br /> - Refcounting the per-CPU acomp_ctx. This involves complexity in<br /> handling the race between the refcount dropping to zero in<br /> zswap_[de]compress() and the refcount being re-initialized when the<br /> CPU is onlined.<br /> - Disabling migration before getting the per-CPU acomp_ctx [3], but<br /> that&amp;#39;s discouraged and is a much bigger hammer than needed, and could<br /> result in subtle performance issues.<br /> <br /> [1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/<br /> [2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/<br /> [3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/<br /> <br /> [yosryahmed@google.com: remove comment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/platform: check the bounds of read/write syscalls<br /> <br /> count and offset are passed from user space and not checked, only<br /> offset is capped to 40 bits, which can be used to read/write out of<br /> bounds of the device.