Filtered by vendor Linux
Subscriptions
Total
17084 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| 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-2021-47253 | 1 Linux | 1 Linux Kernel | 2025-07-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential memory leak in DMUB hw_init [Why] On resume we perform DMUB hw_init which allocates memory: dm_resume->dm_dmub_hw_init->dc_dmub_srv_create->kzalloc That results in memory leak in suspend/resume scenarios. [How] Allocate memory for the DC wrapper to DMUB only if it was not allocated before. No need to reallocate it on suspend/resume. | ||||
| CVE-2020-36775 | 1 Linux | 1 Linux Kernel | 2025-07-11 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential deadlock Using f2fs_trylock_op() in f2fs_write_compressed_pages() to avoid potential deadlock like we did in f2fs_write_single_data_page(). | ||||
| CVE-2025-2073 | 2 Google, Linux | 2 Chrome Os, Linux Kernel | 2025-07-11 | 8.8 High |
| Out-of-Bounds Read in netfilter/ipset in Linux Kernel ChromeOS [6.1, 5.15, 5.10, 5.4, 4.19] allows a local attacker with low privileges to trigger an out-of-bounds read, potentially leading to information disclosure | ||||
| CVE-2025-1290 | 2 Google, Linux | 2 Chrome Os, Linux Kernel | 2025-07-11 | 8.1 High |
| A race condition Use-After-Free vulnerability exists in the virtio_transport_space_update function within the Kernel 5.4 on ChromeOS. Concurrent allocation and freeing of the virtio_vsock_sock structure during an AF_VSOCK connect syscall can occur before a worker thread accesses it resulting in a dangling pointer and potential kernel code execution. | ||||
| CVE-2024-27070 | 1 Linux | 1 Linux Kernel | 2025-07-10 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free issue in f2fs_filemap_fault syzbot reports a f2fs bug as below: BUG: KASAN: slab-use-after-free in f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49 Read of size 8 at addr ffff88807bb22680 by task syz-executor184/5058 CPU: 0 PID: 5058 Comm: syz-executor184 Not tainted 6.7.0-syzkaller-09928-g052d534373b7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x163/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x170 mm/kasan/report.c:601 f2fs_filemap_fault+0xd1/0x2c0 fs/f2fs/file.c:49 __do_fault+0x131/0x450 mm/memory.c:4376 do_shared_fault mm/memory.c:4798 [inline] do_fault mm/memory.c:4872 [inline] do_pte_missing mm/memory.c:3745 [inline] handle_pte_fault mm/memory.c:5144 [inline] __handle_mm_fault+0x23b7/0x72b0 mm/memory.c:5285 handle_mm_fault+0x27e/0x770 mm/memory.c:5450 do_user_addr_fault arch/x86/mm/fault.c:1364 [inline] handle_page_fault arch/x86/mm/fault.c:1507 [inline] exc_page_fault+0x456/0x870 arch/x86/mm/fault.c:1563 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:570 The root cause is: in f2fs_filemap_fault(), vmf->vma may be not alive after filemap_fault(), so it may cause use-after-free issue when accessing vmf->vma->vm_flags in trace_f2fs_filemap_fault(). So it needs to keep vm_flags in separated temporary variable for tracepoint use. | ||||
| CVE-2025-0158 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-08 | 5.5 Medium |
| IBM EntireX 11.1 could allow a local user to cause a denial of service due to an unhandled error and fault isolation. | ||||
| CVE-2025-0759 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-08 | 3.3 Low |
| IBM EntireX 11.1 could allow a local user to unintentionally modify data timestamp integrity due to improper shared resource synchronization. | ||||
| CVE-2024-43498 | 4 Apple, Linux, Microsoft and 1 more | 6 Macos, Linux Kernel, .net and 3 more | 2025-07-08 | 9.8 Critical |
| .NET and Visual Studio Remote Code Execution Vulnerability | ||||
| CVE-2024-43485 | 4 Apple, Linux, Microsoft and 1 more | 10 Macos, Linux Kernel, .net and 7 more | 2025-07-08 | 7.5 High |
| .NET and Visual Studio Denial of Service Vulnerability | ||||
| CVE-2024-43484 | 4 Apple, Linux, Microsoft and 1 more | 26 Macos, Linux Kernel, .net and 23 more | 2025-07-08 | 7.5 High |
| .NET, .NET Framework, and Visual Studio Denial of Service Vulnerability | ||||
| CVE-2024-43483 | 4 Apple, Linux, Microsoft and 1 more | 26 Macos, Linux Kernel, .net and 23 more | 2025-07-08 | 7.5 High |
| .NET, .NET Framework, and Visual Studio Denial of Service Vulnerability | ||||
| CVE-2024-43601 | 2 Linux, Microsoft | 2 Linux Kernel, Visual Studio Code | 2025-07-08 | 7.8 High |
| Visual Studio Code for Linux Remote Code Execution Vulnerability | ||||
| CVE-2024-38229 | 4 Apple, Linux, Microsoft and 1 more | 6 Macos, Linux Kernel, .net and 3 more | 2025-07-08 | 8.1 High |
| .NET and Visual Studio Remote Code Execution Vulnerability | ||||
| CVE-2024-43480 | 2 Linux, Microsoft | 2 Linux Kernel, Azure Service Fabric | 2025-07-08 | 6.6 Medium |
| Azure Service Fabric for Linux Remote Code Execution Vulnerability | ||||
| CVE-2022-23278 | 4 Apple, Google, Linux and 1 more | 11 Macos, Android, Linux Kernel and 8 more | 2025-07-08 | 5.9 Medium |
| Microsoft Defender for Endpoint Spoofing Vulnerability | ||||
| CVE-2024-56467 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
| IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||
| CVE-2024-56493 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
| IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||
| CVE-2024-56494 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
| IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||
| CVE-2024-56495 | 3 Ibm, Linux, Microsoft | 3 Entirex, Linux Kernel, Windows | 2025-07-07 | 3.3 Low |
| IBM EntireX 11.1 could allow a local user to obtain sensitive information when a detailed technical error message is returned. This information could be used in further attacks against the system. | ||||