Total
32214 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-2646 | 1 Tp-link | 2 Archer C7, Archer C7 Firmware | 2025-01-24 | 5.0 MEDIUM | 4.5 MEDIUM |
| A vulnerability has been found in TP-Link Archer C7v2 v2_en_us_180114 and classified as problematic. Affected by this vulnerability is an unknown functionality of the component GET Request Parameter Handler. The manipulation leads to denial of service. The attack can only be done within the local network. The associated identifier of this vulnerability is VDB-228775. NOTE: The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2023-24540 | 1 Golang | 1 Go | 2025-01-24 | N/A | 9.8 CRITICAL |
| Not all valid JavaScript whitespace characters are considered to be whitespace. Templates containing whitespace characters outside of the character set "\t\n\f\r\u0020\u2028\u2029" in JavaScript contexts that also contain actions may not be properly sanitized during execution. | |||||
| CVE-2023-20717 | 2 Google, Mediatek | 26 Android, Mt6768, Mt6769 and 23 more | 2025-01-24 | N/A | 4.1 MEDIUM |
| In vcu, there is a possible leak of dma buffer due to a race condition. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07645185; Issue ID: ALPS07645185. | |||||
| CVE-2021-0877 | 1 Google | 1 Android | 2025-01-24 | N/A | 9.8 CRITICAL |
| Product: AndroidVersions: Android SoCAndroid ID: A-273754094 | |||||
| CVE-2024-10312 | 1 Exclusiveaddons | 1 Exclusive Addons For Elementor | 2025-01-24 | N/A | 4.3 MEDIUM |
| The Exclusive Addons for Elementor plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 2.7.4 via the render function in elements/tabs/tabs.php. This makes it possible for authenticated attackers, with Contributor-level access and above, to extract sensitive private, pending, and draft template data. | |||||
| CVE-2024-50010 | 1 Linux | 1 Linux Kernel | 2025-01-24 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 ("exec: move S_ISREG() check earlier") 0fd338b2d2cd ("exec: move path_noexec() check earlier") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check] | |||||
| CVE-2024-49926 | 1 Linux | 1 Linux Kernel | 2025-01-24 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: <TASK> ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 </TASK> Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ] | |||||
| CVE-2024-44949 | 1 Linux | 1 Linux Kernel | 2025-01-24 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: parisc: fix a possible DMA corruption ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be possible that two unrelated 16-byte allocations share a cache line. If one of these allocations is written using DMA and the other is written using cached write, the value that was written with DMA may be corrupted. This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 - that's the largest possible cache line size. As different parisc microarchitectures have different cache line size, we define arch_slab_minalign(), cache_line_size() and dma_get_cache_alignment() so that the kernel may tune slab cache parameters dynamically, based on the detected cache line size. | |||||
| CVE-2023-2088 | 1 Redhat | 1 Openstack | 2025-01-24 | N/A | 6.5 MEDIUM |
| A flaw was found in OpenStack due to an inconsistency between Cinder and Nova. This issue can be triggered intentionally or by accident. A remote, authenticated attacker could exploit this vulnerability by detaching one of their volumes from Cinder. The highest impact is to confidentiality. | |||||
| CVE-2022-48853 | 1 Linux | 1 Linux Kernel | 2025-01-24 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: swiotlb: fix info leak with DMA_FROM_DEVICE The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204. A short description of what happens follows: 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device. 2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO. 3) For the rest of the story we keep ignoring that we have a TUR, so the device won't touch the buffer we prepare as if the we had a DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device and the buffer allocated by SG is mapped by the function virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here scatter-gather and not scsi generics). This mapping involves bouncing via the swiotlb (we need swiotlb to do virtio in protected guest like s390 Secure Execution, or AMD SEV). 4) When the SCSI TUR is done, we first copy back the content of the second (that is swiotlb) bounce buffer (which most likely contains some previous IO data), to the first bounce buffer, which contains all zeros. Then we copy back the content of the first bounce buffer to the user-space buffer. 5) The test case detects that the buffer, which it zero-initialized, ain't all zeros and fails. One can argue that this is an swiotlb problem, because without swiotlb we leak all zeros, and the swiotlb should be transparent in a sense that it does not affect the outcome (if all other participants are well behaved). Copying the content of the original buffer into the swiotlb buffer is the only way I can think of to make swiotlb transparent in such scenarios. So let's do just that if in doubt, but allow the driver to tell us that the whole mapped buffer is going to be overwritten, in which case we can preserve the old behavior and avoid the performance impact of the extra bounce. | |||||
| CVE-2022-47879 | 1 Jedox | 2 Jedox, Jedox Cloud | 2025-01-24 | N/A | 7.5 HIGH |
| A Remote Code Execution (RCE) vulnerability in /be/rpc.php in Jedox 2020.2.5 allows remote authenticated users to load arbitrary PHP classes from the 'rtn' directory and execute its methods. | |||||
| CVE-2021-47035 | 1 Linux | 1 Linux Kernel | 2025-01-24 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Remove WO permissions on second-level paging entries When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don't want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration. | |||||
| CVE-2024-5913 | 1 Paloaltonetworks | 1 Pan-os | 2025-01-24 | N/A | 6.1 MEDIUM |
| An improper input validation vulnerability in Palo Alto Networks PAN-OS software enables an attacker with the ability to tamper with the physical file system to elevate privileges. | |||||
| CVE-2024-28193 | 1 Yooooomi | 1 Your Spotify | 2025-01-24 | N/A | 6.5 MEDIUM |
| your_spotify is an open source, self hosted Spotify tracking dashboard. YourSpotify version <1.8.0 allows users to create a public token in the settings, which can be used to provide guest-level access to the information of that specific user in YourSpotify. The /me API endpoint discloses Spotify API access and refresh tokens to guest users. Attackers with access to a public token for guest access to YourSpotify can therefore obtain access to Spotify API tokens of YourSpotify users. As a consequence, attackers may extract profile information, information about listening habits, playlists and other information from the corresponding Spotify profile. In addition, the attacker can pause and resume playback in the Spotify app at will. This issue has been resolved in version 1.8.0. Users are advised to upgrade. There are no known workarounds for this issue. | |||||
| CVE-2024-44195 | 1 Apple | 1 Macos | 2025-01-23 | N/A | 7.5 HIGH |
| A logic issue was addressed with improved validation. This issue is fixed in macOS Sequoia 15.1. An app may be able to read arbitrary files. | |||||
| CVE-2024-47760 | 1 Glpi-project | 1 Glpi | 2025-01-23 | N/A | 8.8 HIGH |
| GLPI is a free asset and IT management software package. Starting in version 9.1.0 and prior to version 10.0.17, a technician with an access to the API can take control of an account with higher privileges. Version 10.0.17 contains a patch for this issue. | |||||
| CVE-2024-23314 | 1 F5 | 13 Big-ip Access Policy Manager, Big-ip Advanced Firewall Manager, Big-ip Analytics and 10 more | 2025-01-23 | N/A | 7.5 HIGH |
| When HTTP/2 is configured on BIG-IP or BIG-IP Next SPK systems, undisclosed responses can cause the Traffic Management Microkernel (TMM) to terminate. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated | |||||
| CVE-2023-36761 | 1 Microsoft | 4 365 Apps, Office, Office Long Term Servicing Channel and 1 more | 2025-01-23 | N/A | 6.5 MEDIUM |
| Microsoft Word Information Disclosure Vulnerability | |||||
| CVE-2023-36874 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2025-01-23 | N/A | 7.8 HIGH |
| Windows Error Reporting Service Elevation of Privilege Vulnerability | |||||
| CVE-2023-43748 | 1 Intel | 1 Graphics Performance Analyzers Framework | 2025-01-23 | N/A | 7.8 HIGH |
| Improper access control in some Intel(R) GPA Framework software installers before version 2023.3 may allow an authenticated user to potentially enable escalation of privilege via local access. | |||||