Total
12644 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-58084 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool() Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq completion variable initialization") introduced a write barrier in probe function to store global '__scm' variable. We all known barriers are paired (see memory-barriers.txt: "Note that write barriers should normally be paired with read or address-dependency barriers"), therefore accessing it from concurrent contexts requires read barrier. Previous commit added such barrier in qcom_scm_is_available(), so let's use that directly. Lack of this read barrier can result in fetching stale '__scm' variable value, NULL, and dereferencing it. Note that barrier in qcom_scm_is_available() satisfies here the control dependency. | ||||
| CVE-2024-57952 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Revert "libfs: fix infinite directory reads for offset dir" The current directory offset allocator (based on mtree_alloc_cyclic) stores the next offset value to return in octx->next_offset. This mechanism typically returns values that increase monotonically over time. Eventually, though, the newly allocated offset value wraps back to a low number (say, 2) which is smaller than other already- allocated offset values. Yu Kuai <yukuai3@huawei.com> reports that, after commit 64a7ce76fb90 ("libfs: fix infinite directory reads for offset dir"), if a directory's offset allocator wraps, existing entries are no longer visible via readdir/getdents because offset_readdir() stops listing entries once an entry's offset is larger than octx->next_offset. These entries vanish persistently -- they can be looked up, but will never again appear in readdir(3) output. The reason for this is that the commit treats directory offsets as monotonically increasing integer values rather than opaque cookies, and introduces this comparison: if (dentry2offset(dentry) >= last_index) { On 64-bit platforms, the directory offset value upper bound is 2^63 - 1. Directory offsets will monotonically increase for millions of years without wrapping. On 32-bit platforms, however, LONG_MAX is 2^31 - 1. The allocator can wrap after only a few weeks (at worst). Revert commit 64a7ce76fb90 ("libfs: fix infinite directory reads for offset dir") to prepare for a fix that can work properly on 32-bit systems and might apply to recent LTS kernels where shmem employs the simple_offset mechanism. | ||||
| CVE-2024-56768 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix bpf_get_smp_processor_id() on !CONFIG_SMP On x86-64 calling bpf_get_smp_processor_id() in a kernel with CONFIG_SMP disabled can trigger the following bug, as pcpu_hot is unavailable: [ 8.471774] BUG: unable to handle page fault for address: 00000000936a290c [ 8.471849] #PF: supervisor read access in kernel mode [ 8.471881] #PF: error_code(0x0000) - not-present page Fix by inlining a return 0 in the !CONFIG_SMP case. | ||||
| CVE-2024-53219 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: virtiofs: use pages instead of pointer for kernel direct IO When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: <TASK> ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... </TASK> ---[ end trace 0000000000000000 ]--- The warning is triggered as follows: 1) syscall finit_module() handles the module insertion and it invokes kernel_read_file() to read the content of the module first. 2) kernel_read_file() allocates a 10MB buffer by using vmalloc() and passes it to kernel_read(). kernel_read() constructs a kvec iter by using iov_iter_kvec() and passes it to fuse_file_read_iter(). 3) virtio-fs disables the cache, so fuse_file_read_iter() invokes fuse_direct_io(). As for now, the maximal read size for kvec iter is only limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, so fuse_direct_io() doesn't split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in out_args[0] of a fuse request and passes the fuse request to virtio_fs_wake_pending_and_unlock(). 4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() to queue the request. Because virtiofs need DMA-able address, so virtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL; 5) virtio_fs_enqueue_req() will retry the memory allocation in a kworker, but it won't help, because kmalloc() will always return NULL due to the abnormal size and finit_module() will hang forever. A feasible solution is to limit the value of max_read for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc->max_write in kernel. So instead of limiting both the values of max_read and max_write in kernel, introducing use_pages_for_kvec_io in fuse_conn and setting it as true in virtiofs. When use_pages_for_kvec_io is enabled, fuse will use pages instead of pointer to pass the KVEC_IO data. After switching to pages for KVEC_IO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}_kernel_vmap_range() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuse_args_pages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fuse_get_user_pages() for write operations and the invalidation in fuse_release_user_pages() for read operations. It may seem necessary to introduce another fie ---truncated--- | ||||
| CVE-2025-22011 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ARM: dts: bcm2711: Fix xHCI power-domain During s2idle tests on the Raspberry CM4 the VPU firmware always crashes on xHCI power-domain resume: root@raspberrypi:/sys/power# echo freeze > state [ 70.724347] xhci_suspend finished [ 70.727730] xhci_plat_suspend finished [ 70.755624] bcm2835-power bcm2835-power: Power grafx off [ 70.761127] USB: Set power to 0 [ 74.653040] USB: Failed to set power to 1 (-110) This seems to be caused because of the mixed usage of raspberrypi-power and bcm2835-power at the same time. So avoid the usage of the VPU firmware power-domain driver, which prevents the VPU crash. | ||||
| CVE-2025-52544 | 1 Copeland | 8 E3 Supervisory Controller Firmware, Site Supervisor Bx 860-1240, Site Supervisor Bxe 860-1245 and 5 more | 2025-10-01 | 7.5 High |
| E3 Site Supervisor Control (firmware version < 2.31F01) has a floor plan feature that allows for an unauthenticated attacker to upload floor plan files. By uploading a specially crafted floor plan file, an attacker can access any file from the E3 file system. | ||||
| CVE-2025-52547 | 1 Copeland | 8 E3 Supervisory Controller Firmware, Site Supervisor Bx 860-1240, Site Supervisor Bxe 860-1245 and 5 more | 2025-10-01 | 7.5 High |
| E3 Site Supervisor Control (firmware version < 2.31F01) MGW contains an API call that lacks input validation. An attacker can use this command to continuously crash the application services. | ||||
| CVE-2025-38049 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors Commit 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid") added logic that causes resctrl to search for the CLOSID with the fewest dirty cache lines when creating a new control group, if requested by the arch code. This depends on the values read from the llc_occupancy counters. The logic is applicable to architectures where the CLOSID effectively forms part of the monitoring identifier and so do not allow complete freedom to choose an unused monitoring identifier for a given CLOSID. This support missed that some platforms may not have these counters. This causes a NULL pointer dereference when creating a new control group as the array was not allocated by dom_data_init(). As this feature isn't necessary on platforms that don't have cache occupancy monitors, add this to the check that occurs when a new control group is allocated. | ||||
| CVE-2025-22012 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Revert "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu" There are reports that the pagetable walker cache coherency is not a given across the spectrum of SDM845/850 devices, leading to lock-ups and resets. It works fine on some devices (like the Dragonboard 845c, but not so much on the Lenovo Yoga C630). This unfortunately looks like a fluke in firmware development, where likely somewhere in the vast hypervisor stack, a change to accommodate for this was only introduced after the initial software release (which often serves as a baseline for products). Revert the change to avoid additional guesswork around crashes. This reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805. | ||||
| CVE-2025-1556 | 1 Westboy | 1 Cicadascms | 2025-10-01 | 4.7 Medium |
| A vulnerability, which was classified as problematic, has been found in westboy CicadasCMS 1.0. This issue affects some unknown processing of the file /system of the component Template Management. The manipulation leads to deserialization. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2024-1243 | 1 Wazuh | 1 Wazuh | 2025-10-01 | 7.2 High |
| Improper input validation in the Wazuh agent for Windows prior to version 4.8.0 allows an attacker with control over the Wazuh server or agent key to configure the agent to connect to a malicious UNC path. This results in the leakage of the machine account NetNTLMv2 hash, which can be relayed for remote code execution or used to escalate privileges to SYSTEM via AD CS certificate forging and other similar attacks. | ||||
| CVE-2024-36958 | 2 Linux, Netapp | 15 Linux Kernel, Converged Systems Advisor Agent, H300s and 12 more | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix nfsd4_encode_fattr4() crasher Ensure that args.acl is initialized early. It is used in an unconditional call to kfree() on the way out of nfsd4_encode_fattr4(). | ||||
| CVE-2022-48715 | 1 Linux | 1 Linux Kernel | 2025-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe Running tests with a debug kernel shows that bnx2fc_recv_frame() is modifying the per_cpu lport stats counters in a non-mpsafe way. Just boot a debug kernel and run the bnx2fc driver with the hardware enabled. [ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_ [ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B [ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 1391.699183] Call Trace: [ 1391.699188] dump_stack_lvl+0x57/0x7d [ 1391.699198] check_preemption_disabled+0xc8/0xd0 [ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc] [ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180 [ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc] [ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc] [ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc] [ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc] [ 1391.699258] kthread+0x364/0x420 [ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50 [ 1391.699268] ? set_kthread_struct+0x100/0x100 [ 1391.699273] ret_from_fork+0x22/0x30 Restore the old get_cpu/put_cpu code with some modifications to reduce the size of the critical section. | ||||
| CVE-2025-7060 | 1 Monitorr | 1 Monitorr | 2025-10-01 | 4.1 Medium |
| A vulnerability was found in Monitorr up to 1.7.6m. It has been classified as problematic. This affects an unknown part of the file assets/config/_installation/mkdbajax.php of the component Installer. The manipulation of the argument datadir leads to improper input validation. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2024-21544 | 1 Spatie | 1 Browsershot | 2025-10-01 | 8.6 High |
| Versions of the package spatie/browsershot before 5.0.1 are vulnerable to Improper Input Validation due to improper URL validation in the setUrl method. An attacker can exploit this vulnerability by using leading whitespace (%20) before the file:// protocol, resulting in Local File Inclusion, which allows the attacker to read sensitive files on the server. | ||||
| CVE-2024-21549 | 1 Spatie | 1 Browsershot | 2025-10-01 | 8.6 High |
| Versions of the package spatie/browsershot before 5.0.3 are vulnerable to Improper Input Validation due to improper URL validation through the setUrl method. An attacker can exploit this vulnerability by utilizing view-source:file://, which allows for arbitrary file reading on a local file. **Note:** This is a bypass of the fix for [CVE-2024-21544](https://security.snyk.io/vuln/SNYK-PHP-SPATIEBROWSERSHOT-8496745). | ||||
| CVE-2022-28224 | 1 Tigera | 2 Calico, Calico Enterprise | 2025-09-30 | 5.5 Medium |
| Clusters using Calico (version 3.22.1 and below), Calico Enterprise (version 3.12.0 and below), may be vulnerable to route hijacking with the floating IP feature. Due to insufficient validation, a privileged attacker may be able to set a floating IP annotation to a pod even if the feature is not enabled. This may allow the attacker to intercept and reroute traffic to their compromised pod. | ||||
| CVE-2024-1714 | 1 Sailpoint | 1 Identityiq | 2025-09-30 | 7.1 High |
| An issue exists in all supported versions of IdentityIQ Lifecycle Manager that can result if an entitlement with a value containing leading or trailing whitespace is requested by an authenticated user in an access request. | ||||
| CVE-2020-27337 | 1 Treck | 1 Ipv6 | 2025-09-30 | 7.3 High |
| An issue was discovered in Treck IPv6 before 6.0.1.68. Improper Input Validation in the IPv6 component allows an unauthenticated remote attacker to cause an Out of Bounds Write, and possibly a Denial of Service via network access. | ||||
| CVE-2020-27336 | 1 Treck | 1 Ipv6 | 2025-09-30 | 3.7 Low |
| An issue was discovered in Treck IPv6 before 6.0.1.68. Improper input validation in the IPv6 component when handling a packet sent by an unauthenticated remote attacker could result in an out-of-bounds read of up to three bytes via network access. | ||||