Export limit exceeded: 36130 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (36130 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-46728 | 1 Linux | 1 Linux Kernel | 2025-07-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check index for aux_rd_interval before using aux_rd_interval has size of 7 and should be checked. This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity. | ||||
| CVE-2024-44942 | 1 Linux | 1 Linux Kernel | 2025-07-11 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258 Call Trace: f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834 f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315 do_writepages+0x35b/0x870 mm/page-writeback.c:2612 __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650 writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941 wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117 wb_do_writeback fs/fs-writeback.c:2264 [inline] wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f2/0x390 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The root cause is: inline_data inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fs_bug_on() during dirty page writeback. Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing. | ||||
| CVE-2023-52625 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-07-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Refactor DMCUB enter/exit idle interface [Why] We can hang in place trying to send commands when the DMCUB isn't powered on. [How] We need to exit out of the idle state prior to sending a command, but the process that performs the exit also invokes a command itself. Fixing this issue involves the following: 1. Using a software state to track whether or not we need to start the process to exit idle or notify idle. It's possible for the hardware to have exited an idle state without driver knowledge, but entering one is always restricted to a driver allow - which makes the SW state vs HW state mismatch issue purely one of optimization, which should seldomly be hit, if at all. 2. Refactor any instances of exit/notify idle to use a single wrapper that maintains this SW state. This works simialr to dc_allow_idle_optimizations, but works at the DMCUB level and makes sure the state is marked prior to any notify/exit idle so we don't enter an infinite loop. 3. Make sure we exit out of idle prior to sending any commands or waiting for DMCUB idle. This patch takes care of 1/2. A future patch will take care of wrapping DMCUB command submission with calls to this new interface. | ||||
| CVE-2023-52485 | 1 Linux | 1 Linux Kernel | 2025-07-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wake DMCUB before sending a command [Why] We can hang in place trying to send commands when the DMCUB isn't powered on. [How] For functions that execute within a DC context or DC lock we can wrap the direct calls to dm_execute_dmub_cmd/list with code that exits idle power optimizations and reallows once we're done with the command submission on success. For DM direct submissions the DM will need to manage the enter/exit sequencing manually. We cannot invoke a DMCUB command directly within the DM execution helper or we can deadlock. | ||||
| CVE-2021-47275 | 1 Linux | 1 Linux Kernel | 2025-07-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bcache: avoid oversized read request in cache missing code path In the cache missing code path of cached device, if a proper location from the internal B+ tree is matched for a cache miss range, function cached_dev_cache_miss() will be called in cache_lookup_fn() in the following code block, [code block 1] 526 unsigned int sectors = KEY_INODE(k) == s->iop.inode 527 ? min_t(uint64_t, INT_MAX, 528 KEY_START(k) - bio->bi_iter.bi_sector) 529 : INT_MAX; 530 int ret = s->d->cache_miss(b, s, bio, sectors); Here s->d->cache_miss() is the call backfunction pointer initialized as cached_dev_cache_miss(), the last parameter 'sectors' is an important hint to calculate the size of read request to backing device of the missing cache data. Current calculation in above code block may generate oversized value of 'sectors', which consequently may trigger 2 different potential kernel panics by BUG() or BUG_ON() as listed below, 1) BUG_ON() inside bch_btree_insert_key(), [code block 2] 886 BUG_ON(b->ops->is_extents && !KEY_SIZE(k)); 2) BUG() inside biovec_slab(), [code block 3] 51 default: 52 BUG(); 53 return NULL; All the above panics are original from cached_dev_cache_miss() by the oversized parameter 'sectors'. Inside cached_dev_cache_miss(), parameter 'sectors' is used to calculate the size of data read from backing device for the cache missing. This size is stored in s->insert_bio_sectors by the following lines of code, [code block 4] 909 s->insert_bio_sectors = min(sectors, bio_sectors(bio) + reada); Then the actual key inserting to the internal B+ tree is generated and stored in s->iop.replace_key by the following lines of code, [code block 5] 911 s->iop.replace_key = KEY(s->iop.inode, 912 bio->bi_iter.bi_sector + s->insert_bio_sectors, 913 s->insert_bio_sectors); The oversized parameter 'sectors' may trigger panic 1) by BUG_ON() from the above code block. And the bio sending to backing device for the missing data is allocated with hint from s->insert_bio_sectors by the following lines of code, [code block 6] 926 cache_bio = bio_alloc_bioset(GFP_NOWAIT, 927 DIV_ROUND_UP(s->insert_bio_sectors, PAGE_SECTORS), 928 &dc->disk.bio_split); The oversized parameter 'sectors' may trigger panic 2) by BUG() from the agove code block. Now let me explain how the panics happen with the oversized 'sectors'. In code block 5, replace_key is generated by macro KEY(). From the definition of macro KEY(), [code block 7] 71 #define KEY(inode, offset, size) \ 72 ((struct bkey) { \ 73 .high = (1ULL << 63) | ((__u64) (size) << 20) | (inode), \ 74 .low = (offset) \ 75 }) Here 'size' is 16bits width embedded in 64bits member 'high' of struct bkey. But in code block 1, if "KEY_START(k) - bio->bi_iter.bi_sector" is very probably to be larger than (1<<16) - 1, which makes the bkey size calculation in code block 5 is overflowed. In one bug report the value of parameter 'sectors' is 131072 (= 1 << 17), the overflowed 'sectors' results the overflowed s->insert_bio_sectors in code block 4, then makes size field of s->iop.replace_key to be 0 in code block 5. Then the 0- sized s->iop.replace_key is inserted into the internal B+ tree as cache missing check key (a special key to detect and avoid a racing between normal write request and cache missing read request) as, [code block 8] 915 ret = bch_btree_insert_check_key(b, &s->op, &s->iop.replace_key); Then the 0-sized s->iop.replace_key as 3rd parameter triggers the bkey size check BUG_ON() in code block 2, and causes the kernel panic 1). Another ke ---truncated--- | ||||
| CVE-2025-47775 | 1 Bullfrogsec | 1 Bullfrog | 2025-07-11 | 6.2 Medium |
| Bullfrog is a GithHb Action to block unauthorized outbound traffic in GitHub workflows. Prior to version 0.8.4, using tcp breaks blocking and allows DNS exfiltration. This can result in sandbox bypass. Version 0.8.4 fixes the issue. | ||||
| CVE-2025-26481 | 1 Dell | 1 Powerscale Onefs | 2025-07-11 | 7.5 High |
| Dell PowerScale OneFS, versions 9.4.0.0 through 9.9.0.0, contains an uncontrolled resource consumption vulnerability. A remote unprivileged attacker could potentially exploit this vulnerability, leading to denial of service. | ||||
| CVE-2024-3584 | 1 Qdrant | 1 Qdrant | 2025-07-10 | 7.5 High |
| qdrant/qdrant version 1.9.0-dev is vulnerable to path traversal due to improper input validation in the `/collections/{name}/snapshots/upload` endpoint. By manipulating the `name` parameter through URL encoding, an attacker can upload a file to an arbitrary location on the system, such as `/root/poc.txt`. This vulnerability allows for the writing and overwriting of arbitrary files on the server, potentially leading to a full takeover of the system. The issue is fixed in version 1.9.0. | ||||
| CVE-2024-4287 | 1 Mintplexlabs | 1 Anythingllm | 2025-07-10 | 7.2 High |
| In mintplex-labs/anything-llm, a vulnerability exists due to improper input validation in the workspace update process. Specifically, the application fails to validate or format JSON data sent in an HTTP POST request to `/api/workspace/:workspace-slug/update`, allowing it to be executed as part of a database query without restrictions. This flaw enables users with a manager role to craft a request that includes nested write operations, effectively allowing them to create new Administrator accounts. | ||||
| CVE-2023-24932 | 1 Microsoft | 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more | 2025-07-10 | 6.7 Medium |
| Secure Boot Security Feature Bypass Vulnerability | ||||
| CVE-2023-29344 | 1 Microsoft | 3 365 Apps, Office, Office Long Term Servicing Channel | 2025-07-10 | 7.8 High |
| Microsoft Office Remote Code Execution Vulnerability | ||||
| CVE-2023-29325 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2025-07-10 | 8.1 High |
| Windows OLE Remote Code Execution Vulnerability | ||||
| CVE-2023-24904 | 1 Microsoft | 1 Windows Server 2008 | 2025-07-10 | 7.1 High |
| Windows Installer Elevation of Privilege Vulnerability | ||||
| CVE-2023-24881 | 1 Microsoft | 1 Teams | 2025-07-10 | 6.5 Medium |
| Microsoft Teams Information Disclosure Vulnerability | ||||
| CVE-2023-28290 | 1 Microsoft | 1 Remote Desktop App | 2025-07-10 | 5.3 Medium |
| Microsoft Remote Desktop app for Windows Information Disclosure Vulnerability | ||||
| CVE-2023-29350 | 1 Microsoft | 1 Edge Chromium | 2025-07-10 | 7.5 High |
| Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability | ||||
| CVE-2023-29354 | 1 Microsoft | 1 Edge Chromium | 2025-07-10 | 4.7 Medium |
| Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability | ||||
| CVE-2023-29343 | 1 Microsoft | 1 Windows Sysmon | 2025-07-10 | 7.8 High |
| SysInternals Sysmon for Windows Elevation of Privilege Vulnerability | ||||
| CVE-2023-29341 | 1 Microsoft | 1 Av1 Video Extension | 2025-07-10 | 7.8 High |
| AV1 Video Extension Remote Code Execution Vulnerability | ||||
| CVE-2023-29340 | 1 Microsoft | 1 Av1 Video Extension | 2025-07-10 | 7.8 High |
| AV1 Video Extension Remote Code Execution Vulnerability | ||||