| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Apache Traffic Server accepts characters that are not allowed for HTTP field names and forwards malformed requests to origin servers. This can be utilized for request smuggling and may also lead cache poisoning if the origin servers are vulnerable.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.10, from 9.0.0 through 9.2.4.
Users are recommended to upgrade to version 8.1.11 or 9.2.5, which fixes the issue. |
| samlify is a Node.js library for SAML single sign-on. A Signature Wrapping attack has been found in samlify prior to version 2.10.0, allowing an attacker to forge a SAML Response to authenticate as any user. An attacker would need a signed XML document by the identity provider. Version 2.10.0 fixes the issue. |
| containerd is an open-source container runtime. A bug was found in the containerd's CRI implementation where containerd, starting in version 2.0.1 and prior to version 2.0.5, doesn't put usernamespaced containers under the Kubernetes' cgroup hierarchy, therefore some Kubernetes limits are not honored. This may cause a denial of service of the Kubernetes node. This bug has been fixed in containerd 2.0.5+ and 2.1.0+. Users should update to these versions to resolve the issue. As a workaround, disable usernamespaced pods in Kubernetes temporarily. |
| An SQL injection vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to execute unauthorized code or commands.
We have already fixed the vulnerability in the following version:
Qsync Central 4.5.0.7 ( 2025/04/23 ) and later |
| An SQL injection vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to execute unauthorized code or commands.
We have already fixed the vulnerability in the following version:
Qsync Central 4.5.0.7 ( 2025/04/23 ) and later |
| A double-free could have occurred in `vpx_codec_enc_init_multi` after a failed allocation when initializing the encoder for WebRTC. This could have caused memory corruption and a potentially exploitable crash. This vulnerability affects Thunderbird < 139 and Thunderbird < 128.11. |
| A vulnerability was found in whuan132 AIBattery up to 1.0.9. The affected element is an unknown function of the file AIBatteryHelper/XPC/BatteryXPCService.swift of the component com.collweb.AIBatteryHelper. The manipulation results in missing authentication. The attack requires a local approach. The exploit has been made public and could be used. |
| NVIDIA Megatron-LM for all platforms contains a vulnerability in the tools component, where an attacker may exploit a code injection issue. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, information disclosure, and data tampering. |
| NVIDIA Megatron-LM for all platforms contains a vulnerability in the megatron/training/
arguments.py component where an attacker could cause a code injection issue by providing a malicious input. A successful exploit of this vulnerability may lead to code execution, escalation of privileges, information disclosure, and data tampering. |
| An improper certificate validation vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to compromise the security of the system.
We have already fixed the vulnerability in the following version:
Qsync Central 4.5.0.7 ( 2025/04/23 ) and later |
| An improper certificate validation vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to compromise the security of the system.
We have already fixed the vulnerability in the following version:
Qsync Central 4.5.0.7 ( 2025/04/23 ) and later |
| In the Linux kernel, the following vulnerability has been resolved:
clk: clk-loongson2: Fix memory corruption bug in struct loongson2_clk_provider
Some heap space is allocated for the flexible structure `struct
clk_hw_onecell_data` and its flexible-array member `hws` through
the composite structure `struct loongson2_clk_provider` in function
`loongson2_clk_probe()`, as shown below:
289 struct loongson2_clk_provider *clp;
...
296 for (p = data; p->name; p++)
297 clks_num++;
298
299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num),
300 GFP_KERNEL);
Then some data is written into the flexible array:
350 clp->clk_data.hws[p->id] = hw;
This corrupts `clk_lock`, which is the spinlock variable immediately
following the `clk_data` member in `struct loongson2_clk_provider`:
struct loongson2_clk_provider {
void __iomem *base;
struct device *dev;
struct clk_hw_onecell_data clk_data;
spinlock_t clk_lock; /* protect access to DIV registers */
};
The problem is that the flexible structure is currently placed in the
middle of `struct loongson2_clk_provider` instead of at the end.
Fix this by moving `struct clk_hw_onecell_data clk_data;` to the end of
`struct loongson2_clk_provider`. Also, add a code comment to help
prevent this from happening again in case new members are added to the
structure in the future.
This change also fixes the following -Wflex-array-member-not-at-end
warning:
drivers/clk/clk-loongson2.c:32:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] |
| Coolify versions prior to v4.0.0-beta.420.6 are vulnerable to a remote code execution vulnerability in the application deployment workflow. The platform allows authenticated users, with low-level member privileges, to inject arbitrary Docker Compose directives during project creation. By crafting a malicious service definition that mounts the host root filesystem, an attacker can gain full root access to the underlying server. |
| In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Properly hide first-in-list PCIe extended capability
There are cases where a PCIe extended capability should be hidden from
the user. For example, an unknown capability (i.e., capability with ID
greater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally
chosen to be hidden from the user.
Hiding a capability is done by virtualizing and modifying the 'Next
Capability Offset' field of the previous capability so it points to the
capability after the one that should be hidden.
The special case where the first capability in the list should be hidden
is handled differently because there is no previous capability that can
be modified. In this case, the capability ID and version are zeroed
while leaving the next pointer intact. This hides the capability and
leaves an anchor for the rest of the capability list.
However, today, hiding the first capability in the list is not done
properly if the capability is unknown, as struct
vfio_pci_core_device->pci_config_map is set to the capability ID during
initialization but the capability ID is not properly checked later when
used in vfio_config_do_rw(). This leads to the following warning [1] and
to an out-of-bounds access to ecap_perms array.
Fix it by checking cap_id in vfio_config_do_rw(), and if it is greater
than PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct
read only access instead of the ecap_perms array.
Note that this is safe since the above is the only case where cap_id can
exceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which
are already checked before).
[1]
WARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]
CPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1
(snip)
Call Trace:
<TASK>
? show_regs+0x69/0x80
? __warn+0x8d/0x140
? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]
? report_bug+0x18f/0x1a0
? handle_bug+0x63/0xa0
? exc_invalid_op+0x19/0x70
? asm_exc_invalid_op+0x1b/0x20
? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]
? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]
vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]
vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]
vfio_device_fops_read+0x27/0x40 [vfio]
vfs_read+0xbd/0x340
? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]
? __rseq_handle_notify_resume+0xa4/0x4b0
__x64_sys_pread64+0x96/0xc0
x64_sys_call+0x1c3d/0x20d0
do_syscall_64+0x4d/0x120
entry_SYSCALL_64_after_hwframe+0x76/0x7e |
| Coolify versions prior to v4.0.0-beta.420.7 are vulnerable to a remote code execution vulnerability in the project deployment workflow. The platform allows authenticated users, with low-level member privileges, to inject arbitrary shell commands via the Git Repository field during project creation. By submitting a crafted repository string containing command injection syntax, an attacker can execute arbitrary commands on the underlying host system, resulting in full server compromise. |
| In the Linux kernel, the following vulnerability has been resolved:
kobject_uevent: Fix OOB access within zap_modalias_env()
zap_modalias_env() wrongly calculates size of memory block to move, so
will cause OOB memory access issue if variable MODALIAS is not the last
one within its @env parameter, fixed by correcting size to memmove. |
| In the Linux kernel, the following vulnerability has been resolved:
swiotlb: Fix double-allocation of slots due to broken alignment handling
Commit bbb73a103fbb ("swiotlb: fix a braino in the alignment check fix"),
which was a fix for commit 0eee5ae10256 ("swiotlb: fix slot alignment
checks"), causes a functional regression with vsock in a virtual machine
using bouncing via a restricted DMA SWIOTLB pool.
When virtio allocates the virtqueues for the vsock device using
dma_alloc_coherent(), the SWIOTLB search can return page-unaligned
allocations if 'area->index' was left unaligned by a previous allocation
from the buffer:
# Final address in brackets is the SWIOTLB address returned to the caller
| virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800)
| virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800)
| virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800)
This ends badly (typically buffer corruption and/or a hang) because
swiotlb_alloc() is expecting a page-aligned allocation and so blindly
returns a pointer to the 'struct page' corresponding to the allocation,
therefore double-allocating the first half (2KiB slot) of the 4KiB page.
Fix the problem by treating the allocation alignment separately to any
additional alignment requirements from the device, using the maximum
of the two as the stride to search the buffer slots and taking care
to ensure a minimum of page-alignment for buffers larger than a page.
This also resolves swiotlb allocation failures occuring due to the
inclusion of ~PAGE_MASK in 'iotlb_align_mask' for large allocations and
resulting in alignment requirements exceeding swiotlb_max_mapping_size(). |
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| In the Linux kernel, the following vulnerability has been resolved:
tty: serial: fsl_lpuart: disable dma rx/tx use flags in lpuart_dma_shutdown
lpuart_dma_shutdown tears down lpuart dma, but lpuart_flush_buffer can
still occur which in turn tries to access dma apis if lpuart_dma_tx_use
flag is true. At this point since dma is torn down, these dma apis can
abort. Set lpuart_dma_tx_use and the corresponding rx flag
lpuart_dma_rx_use to false in lpuart_dma_shutdown so that dmas are not
accessed after they are relinquished.
Otherwise, when try to kill btattach, kernel may panic. This patch may
fix this issue.
root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200
^C[ 90.182296] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
[ 90.189806] Modules linked in: moal(O) mlan(O)
[ 90.194258] CPU: 0 PID: 503 Comm: btattach Tainted: G O 5.15.32-06136-g34eecdf2f9e4 #37
[ 90.203554] Hardware name: NXP i.MX8ULP 9X9 EVK (DT)
[ 90.208513] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 90.215470] pc : fsl_edma3_disable_request+0x8/0x60
[ 90.220358] lr : fsl_edma3_terminate_all+0x34/0x20c
[ 90.225237] sp : ffff800013f0bac0
[ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800
[ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24: ffff000008404a00
[ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000
[ 90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000
[ 90.257078] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 90.264211] x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000040
[ 90.271344] x11: ffff00000600c248 x10: ffff800013f0bb10 x9 : ffff000057bcb090
[ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804
[ 90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480
[ 90.292742] x2 : ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800
[ 90.299876] Call trace:
[ 90.302321] fsl_edma3_disable_request+0x8/0x60
[ 90.306851] lpuart_flush_buffer+0x40/0x160
[ 90.311037] uart_flush_buffer+0x88/0x120
[ 90.315050] tty_driver_flush_buffer+0x20/0x30
[ 90.319496] hci_uart_flush+0x44/0x90
[ 90.323162] +0x34/0x12c
[ 90.327253] tty_ldisc_close+0x38/0x70
[ 90.331005] tty_ldisc_release+0xa8/0x190
[ 90.335018] tty_release_struct+0x24/0x8c
[ 90.339022] tty_release+0x3ec/0x4c0
[ 90.342593] __fput+0x70/0x234
[ 90.345652] ____fput+0x14/0x20
[ 90.348790] task_work_run+0x84/0x17c
[ 90.352455] do_exit+0x310/0x96c
[ 90.355688] do_group_exit+0x3c/0xa0
[ 90.359259] __arm64_sys_exit_group+0x1c/0x20
[ 90.363609] invoke_syscall+0x48/0x114
[ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc
[ 90.372068] do_el0_svc+0x2c/0x94
[ 90.375379] el0_svc+0x28/0x80
[ 90.378438] el0t_64_sync_handler+0xa8/0x130
[ 90.382711] el0t_64_sync+0x1a0/0x1a4
[ 90.386376] Code: 17ffffda d503201f d503233f f9409802 (b9400041)
[ 90.392467] ---[ end trace 2f60524b4a43f1f6 ]---
[ 90.397073] note: btattach[503] exited with preempt_count 1
[ 90.402636] Fixing recursive fault but reboot is needed! |
| In the Linux kernel, the following vulnerability has been resolved:
padata: Always leave BHs disabled when running ->parallel()
A deadlock can happen when an overloaded system runs ->parallel() in the
context of the current task:
padata_do_parallel
->parallel()
pcrypt_aead_enc/dec
padata_do_serial
spin_lock(&reorder->lock) // BHs still enabled
<interrupt>
...
__do_softirq
...
padata_do_serial
spin_lock(&reorder->lock)
It's a bug for BHs to be on in _do_serial as Steffen points out, so
ensure they're off in the "current task" case like they are in
padata_parallel_worker to avoid this situation. |
