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."

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.

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;`.

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).

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Assign job pointer to NULL before signaling the fence<br /> <br /> In commit e4b5ccd392b9 ("drm/v3d: Ensure job pointer is set to NULL<br /> after job completion"), we introduced a change to assign the job pointer<br /> to NULL after completing a job, indicating job completion.<br /> <br /> However, this approach created a race condition between the DRM<br /> scheduler workqueue and the IRQ execution thread. As soon as the fence is<br /> signaled in the IRQ execution thread, a new job starts to be executed.<br /> This results in a race condition where the IRQ execution thread sets the<br /> job pointer to NULL simultaneously as the `run_job()` function assigns<br /> a new job to the pointer.<br /> <br /> This race condition can lead to a NULL pointer dereference if the IRQ<br /> execution thread sets the job pointer to NULL after `run_job()` assigns<br /> it to the new job. When the new job completes and the GPU emits an<br /> interrupt, `v3d_irq()` is triggered, potentially causing a crash.<br /> <br /> [ 466.310099] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0<br /> [ 466.318928] Mem abort info:<br /> [ 466.321723] ESR = 0x0000000096000005<br /> [ 466.325479] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 466.330807] SET = 0, FnV = 0<br /> [ 466.333864] EA = 0, S1PTW = 0<br /> [ 466.337010] FSC = 0x05: level 1 translation fault<br /> [ 466.341900] Data abort info:<br /> [ 466.344783] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 466.350285] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 466.355350] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 466.360677] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000089772000<br /> [ 466.367140] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 466.375875] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> [ 466.382163] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device algif_hash algif_skcipher af_alg bnep binfmt_misc vc4 snd_soc_hdmi_codec drm_display_helper cec brcmfmac_wcc spidev rpivid_hevc(C) drm_client_lib brcmfmac hci_uart drm_dma_helper pisp_be btbcm brcmutil snd_soc_core aes_ce_blk v4l2_mem2mem bluetooth aes_ce_cipher snd_compress videobuf2_dma_contig ghash_ce cfg80211 gf128mul snd_pcm_dmaengine videobuf2_memops ecdh_generic sha2_ce ecc videobuf2_v4l2 snd_pcm v3d sha256_arm64 rfkill videodev snd_timer sha1_ce libaes gpu_sched snd videobuf2_common sha1_generic drm_shmem_helper mc rp1_pio drm_kms_helper raspberrypi_hwmon spi_bcm2835 gpio_keys i2c_brcmstb rp1 raspberrypi_gpiomem rp1_mailbox rp1_adc nvmem_rmem uio_pdrv_genirq uio i2c_dev drm ledtrig_pattern drm_panel_orientation_quirks backlight fuse dm_mod ip_tables x_tables ipv6<br /> [ 466.458429] CPU: 0 UID: 1000 PID: 2008 Comm: chromium Tainted: G C 6.13.0-v8+ #18<br /> [ 466.467336] Tainted: [C]=CRAP<br /> [ 466.470306] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)<br /> [ 466.476157] pstate: 404000c9 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 466.483143] pc : v3d_irq+0x118/0x2e0 [v3d]<br /> [ 466.487258] lr : __handle_irq_event_percpu+0x60/0x228<br /> [ 466.492327] sp : ffffffc080003ea0<br /> [ 466.495646] x29: ffffffc080003ea0 x28: ffffff80c0c94200 x27: 0000000000000000<br /> [ 466.502807] x26: ffffffd08dd81d7b x25: ffffff80c0c94200 x24: ffffff8003bdc200<br /> [ 466.509969] x23: 0000000000000001 x22: 00000000000000a7 x21: 0000000000000000<br /> [ 466.517130] x20: ffffff8041bb0000 x19: 0000000000000001 x18: 0000000000000000<br /> [ 466.524291] x17: ffffffafadfb0000 x16: ffffffc080000000 x15: 0000000000000000<br /> [ 466.531452] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ 466.538613] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffd08c527eb0<br /> [ 466.545777] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 466.552941] x5 : ffffffd08c4100d0 x4 : ffffffafadfb0000 x3 : ffffffc080003f70<br /> [ 466.560102] x2 : ffffffc0829e8058 x1 : 0000000000000001 x0 : 0000000000000000<br /> [ 466.567263] Call trace:<br /> [ 466.569711] v3d_irq+0x118/0x2e0 [v3d] (P)<br /> [ 466.<br /> ---truncated---