Export limit exceeded: 37106 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Export limit exceeded: 37106 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Export limit exceeded: 37106 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Search Results (37106 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2024-55417 1 Thecontrolgroup 1 Voyager 2026-02-26 4.3 Medium
DevDojo Voyager through version 1.8.0 is vulnerable to bypassing the file type verification when an authenticated user uploads a file via /admin/media/upload. An authenticated user can upload a web shell causing arbitrary code execution on the server.
CVE-2025-22220 1 Vmware 2 Aria Operations For Logs, Cloud Foundation 2026-02-26 4.3 Medium
VMware Aria Operations for Logs contains a privilege escalation vulnerability. A malicious actor with non-administrative privileges and network access to Aria Operations for Logs API may be able to perform certain operations in the context of an admin user.
CVE-2025-30391 1 Microsoft 1 Dynamics 365 Customer Service 2026-02-26 8.1 High
Improper input validation in Microsoft Dynamics allows an unauthorized attacker to disclose information over a network.
CVE-2025-68358 1 Linux 1 Linux Kernel 2026-02-26 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix racy bitfield write in btrfs_clear_space_info_full() From the memory-barriers.txt document regarding memory barrier ordering guarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field. btrfs_space_info has a bitfield sharing an underlying word consisting of the fields full, chunk_alloc, and flush: struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ... Therefore, to be safe from parallel read-modify-writes losing a write to one of the bitfield members protected by a lock, all writes to all the bitfields must use the lock. They almost universally do, except for btrfs_clear_space_info_full() which iterates over the space_infos and writes out found->full = 0 without a lock. Imagine that we have one thread completing a transaction in which we finished deleting a block_group and are thus calling btrfs_clear_space_info_full() while simultaneously the data reclaim ticket infrastructure is running do_async_reclaim_data_space(): T1 T2 btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1 and now data_sinfo->flush is 1 but the reclaim worker has exited. This breaks the invariant that flush is 0 iff there is no work queued or running. Once this invariant is violated, future allocations that go into __reserve_bytes() will add tickets to space_info->tickets but will see space_info->flush is set to 1 and not queue the work. After this, they will block forever on the resulting ticket, as it is now impossible to kick the worker again. I also confirmed by looking at the assembly of the affected kernel that it is doing RMW operations. For example, to set the flush (3rd) bit to 0, the assembly is: andb $0xfb,0x60(%rbx) and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax) So I think this is really a bug on practical systems. I have observed a number of systems in this exact state, but am currently unable to reproduce it. Rather than leaving this footgun lying around for the future, take advantage of the fact that there is room in the struct anyway, and that it is already quite large and simply change the three bitfield members to bools. This avoids writes to space_info->full having any effect on ---truncated---
CVE-2025-30389 1 Microsoft 1 Azure Ai Bot Service 2026-02-26 8.7 High
Improper authorization in Azure Bot Framework SDK allows an unauthorized attacker to elevate privileges over a network.
CVE-2025-33074 1 Microsoft 1 Azure Functions 2026-02-26 7.5 High
Improper verification of cryptographic signature in Microsoft Azure Functions allows an authorized attacker to execute code over a network.
CVE-2025-30390 1 Microsoft 1 Azure Machine Learning 2026-02-26 9.9 Critical
Improper authorization in Azure allows an authorized attacker to elevate privileges over a network.
CVE-2025-30392 1 Microsoft 1 Azure Ai Bot Service 2026-02-26 9.8 Critical
Improper authorization in Azure Bot Framework SDK allows an unauthorized attacker to elevate privileges over a network.
CVE-2025-21416 1 Microsoft 1 Azure Virtual Desktop 2026-02-26 8.5 High
Missing authorization in Azure Virtual Desktop allows an authorized attacker to elevate privileges over a network.
CVE-2025-20671 2 Google, Mediatek 11 Android, Mt2718, Mt6878 and 8 more 2026-02-26 6.4 Medium
In thermal, there is a possible out of bounds write due to a race condition. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS09698599; Issue ID: MSV-3228.
CVE-2025-20668 2 Google, Mediatek 8 Android, Mt6878, Mt6897 and 5 more 2026-02-26 6.7 Medium
In scp, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege if a malicious actor has already obtained the System privilege. User interaction is not needed for exploitation. Patch ID: ALPS09625562; Issue ID: MSV-3027.
CVE-2025-2509 1 Google 1 Chrome Os 2026-02-26 7.8 High
Out-of-Bounds Read in Virglrenderer in ChromeOS 16093.57.0 allows a malicious guest VM to achieve arbitrary address access within the crosvm sandboxed process, potentially leading to VM escape via crafted vertex elements data triggering an out-of-bounds read in util_format_description.
CVE-2024-45554 1 Qualcomm 42 Fastconnect 6900, Fastconnect 6900 Firmware, Fastconnect 7800 and 39 more 2026-02-26 7.8 High
Memory corruption during concurrent SSR execution due to race condition on the global maps list.
CVE-2024-45564 1 Qualcomm 126 C-v2x 9150, C-v2x 9150 Firmware, Fastconnect 6800 and 123 more 2026-02-26 7.8 High
Memory corruption during concurrent access to server info object due to incorrect reference count update.
CVE-2024-45565 1 Qualcomm 8 Sdm429w, Sdm429w Firmware, Snapdragon 429 Mobile and 5 more 2026-02-26 7.8 High
Memory corruption when blob structure is modified by user-space after kernel verification.
CVE-2024-45566 1 Qualcomm 46 Fastconnect 6800, Fastconnect 6800 Firmware, Fastconnect 6900 and 43 more 2026-02-26 7.8 High
Memory corruption during concurrent buffer access due to modification of the reference count.
CVE-2024-45567 1 Qualcomm 28 Fastconnect 6900, Fastconnect 6900 Firmware, Fastconnect 7800 and 25 more 2026-02-26 7.8 High
Memory corruption while encoding JPEG format.
CVE-2024-45568 1 Qualcomm 26 Fastconnect 6900, Fastconnect 6900 Firmware, Fastconnect 7800 and 23 more 2026-02-26 6.7 Medium
Memory corruption due to improper bounds check while command handling in camera-kernel driver.
CVE-2024-45574 1 Qualcomm 8 Sdm429w, Sdm429w Firmware, Snapdragon 429 Mobile and 5 more 2026-02-26 7.8 High
Memory corruption during array access in Camera kernel due to invalid index from invalid command data.
CVE-2025-31722 1 Jenkins 1 Templating Engine 2026-02-26 8.8 High
In Jenkins Templating Engine Plugin 2.5.3 and earlier, libraries defined in folders are not subject to sandbox protection, allowing attackers with Item/Configure permission to execute arbitrary code in the context of the Jenkins controller JVM.