ReportizFlow
Filtered by vendor
Subscriptions
Total
13126 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-46725 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix out-of-bounds write warning Check the ring type value to fix the out-of-bounds write warning | ||||
| CVE-2024-46713 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: perf/aux: Fix AUX buffer serialization Ole reported that event->mmap_mutex is strictly insufficient to serialize the AUX buffer, add a per RB mutex to fully serialize it. Note that in the lock order comment the perf_event::mmap_mutex order was already wrong, that is, it nesting under mmap_lock is not new with this patch. | ||||
| CVE-2024-46689 | 1 Linux | 1 Linux Kernel | 2025-11-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: soc: qcom: cmd-db: Map shared memory as WC, not WB Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. | ||||
| CVE-2024-45026 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error recovery leading to data corruption on ESE devices Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing. The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format. The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart. Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode. Also remove the check for file protected since this is not a valid ESE handling case. | ||||
| CVE-2024-45025 | 1 Linux | 1 Linux Kernel | 2025-11-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset(). Reproducer added to tools/testing/selftests/core/close_range_test.c | ||||
| CVE-2024-45022 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-11-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0 The __vmap_pages_range_noflush() assumes its argument pages** contains pages with the same page shift. However, since commit e9c3cda4d86e ("mm, vmalloc: fix high order __GFP_NOFAIL allocations"), if gfp_flags includes __GFP_NOFAIL with high order in vm_area_alloc_pages() and page allocation failed for high order, the pages** may contain two different page shifts (high order and order-0). This could lead __vmap_pages_range_noflush() to perform incorrect mappings, potentially resulting in memory corruption. Users might encounter this as follows (vmap_allow_huge = true, 2M is for PMD_SIZE): kvmalloc(2M, __GFP_NOFAIL|GFP_X) __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP) vm_area_alloc_pages(order=9) ---> order-9 allocation failed and fallback to order-0 vmap_pages_range() vmap_pages_range_noflush() __vmap_pages_range_noflush(page_shift = 21) ----> wrong mapping happens We can remove the fallback code because if a high-order allocation fails, __vmalloc_node_range_noprof() will retry with order-0. Therefore, it is unnecessary to fallback to order-0 here. Therefore, fix this by removing the fallback code. | ||||
| CVE-2024-44977 | 1 Linux | 1 Linux Kernel | 2025-11-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Validate TA binary size Add TA binary size validation to avoid OOB write. (cherry picked from commit c0a04e3570d72aaf090962156ad085e37c62e442) | ||||
| CVE-2024-44938 | 1 Linux | 1 Linux Kernel | 2025-11-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: jfs: Fix shift-out-of-bounds in dbDiscardAG When searching for the next smaller log2 block, BLKSTOL2() returned 0, causing shift exponent -1 to be negative. This patch fixes the issue by exiting the loop directly when negative shift is found. | ||||
| CVE-2024-44284 | 1 Apple | 1 Macos | 2025-11-04 | 6.5 Medium |
| An out-of-bounds write issue was addressed with improved input validation. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. Parsing a maliciously crafted file may lead to an unexpected app termination. | ||||
| CVE-2024-44277 | 1 Apple | 4 Ipados, Iphone Os, Tvos and 1 more | 2025-11-04 | 7.7 High |
| The issue was addressed with improved memory handling. This issue is fixed in iOS 18.1 and iPadOS 18.1, visionOS 2.1, tvOS 18.1. An app may be able to cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2025-30464 | 1 Apple | 1 Macos | 2025-11-04 | 7.8 High |
| An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. An app may be able to cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2025-30446 | 1 Apple | 1 Macos | 2025-11-04 | 6.5 Medium |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. A malicious app with root privileges may be able to modify the contents of system files. | ||||
| CVE-2025-24273 | 1 Apple | 1 Macos | 2025-11-04 | 9.8 Critical |
| An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in macOS Ventura 13.7.5, macOS Sequoia 15.4, macOS Sonoma 14.7.5. An app may be able to cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2025-24257 | 1 Apple | 4 Ipados, Iphone Os, Macos and 1 more | 2025-11-04 | 7.1 High |
| An out-of-bounds write issue was addressed with improved input validation. This issue is fixed in visionOS 2.4, iOS 18.4 and iPadOS 18.4, macOS Sequoia 15.4. An app may be able to cause unexpected system termination or write kernel memory. | ||||
| CVE-2024-44245 | 1 Apple | 4 Ipados, Iphone Os, Macos and 1 more | 2025-11-04 | 7.1 High |
| The issue was addressed with improved memory handling. This issue is fixed in iPadOS 17.7.3, visionOS 2.2, macOS Sequoia 15.2, iOS 18.2 and iPadOS 18.2, macOS Sonoma 14.7.2. An app may be able to cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2024-44244 | 2 Apple, Redhat | 13 Ipados, Iphone Os, Macos and 10 more | 2025-11-04 | 4.3 Medium |
| A memory corruption issue was addressed with improved input validation. This issue is fixed in iOS 18.1 and iPadOS 18.1, watchOS 11.1, visionOS 2.1, tvOS 18.1, macOS Sequoia 15.1, Safari 18.1. Processing maliciously crafted web content may lead to an unexpected process crash. | ||||
| CVE-2024-44237 | 1 Apple | 2 Mac Os, Macos | 2025-11-04 | 6.5 Medium |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. Processing a maliciously crafted file may lead to unexpected app termination. | ||||
| CVE-2024-44236 | 1 Apple | 1 Macos | 2025-11-04 | 6.5 Medium |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. Processing a maliciously crafted file may lead to unexpected app termination. | ||||
| CVE-2024-44218 | 1 Apple | 4 Ios, Ipados, Iphone Os and 1 more | 2025-11-04 | 7.8 High |
| This issue was addressed with improved checks. This issue is fixed in iOS 17.7.1 and iPadOS 17.7.1, macOS Sonoma 14.7.1, iOS 18.1 and iPadOS 18.1. Processing a maliciously crafted file may lead to heap corruption. | ||||
| CVE-2024-43839 | 1 Linux | 1 Linux Kernel | 2025-11-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bna: adjust 'name' buf size of bna_tcb and bna_ccb structures To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there. For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16 And replace sprintf with snprintf. Detected using the static analysis tool - Svace. | ||||