Total
12879 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-46689 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 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 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 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-03 | N/A | 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 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 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-03 | N/A | 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-03 | N/A | 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-03 | N/A | 5.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-03 | N/A | 7.8 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-03 | N/A | 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-03 | N/A | 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-30441 | 1 Apple | 1 Xcode | 2025-11-03 | N/A | 5.5 MEDIUM |
| This issue was addressed through improved state management. This issue is fixed in Xcode 16.3. An app may be able to overwrite arbitrary files. | |||||
| CVE-2025-26598 | 3 Redhat, Tigervnc, X.org | 4 Enterprise Linux, Tigervnc, X Server and 1 more | 2025-11-03 | N/A | 7.8 HIGH |
| An out-of-bounds write flaw was found in X.Org and Xwayland. The function GetBarrierDevice() searches for the pointer device based on its device ID and returns the matching value, or supposedly NULL, if no match was found. However, the code will return the last element of the list if no matching device ID is found, which can lead to out-of-bounds memory access. | |||||
| CVE-2025-26596 | 3 Redhat, Tigervnc, X.org | 4 Enterprise Linux, Tigervnc, X Server and 1 more | 2025-11-03 | N/A | 7.8 HIGH |
| A heap overflow flaw was found in X.Org and Xwayland. The computation of the length in XkbSizeKeySyms() differs from what is written in XkbWriteKeySyms(), which may lead to a heap-based buffer overflow. | |||||
| CVE-2025-26595 | 3 Redhat, Tigervnc, X.org | 4 Enterprise Linux, Tigervnc, X Server and 1 more | 2025-11-03 | N/A | 7.8 HIGH |
| A buffer overflow flaw was found in X.Org and Xwayland. The code in XkbVModMaskText() allocates a fixed-sized buffer on the stack and copies the names of the virtual modifiers to that buffer. The code fails to check the bounds of the buffer and would copy the data regardless of the size. | |||||
| CVE-2025-24273 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 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-03 | N/A | 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-03 | N/A | 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 | 1 Apple | 7 Ipados, Iphone Os, Macos and 4 more | 2025-11-03 | N/A | 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 | 1 Macos | 2025-11-03 | N/A | 5.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-03 | N/A | 5.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. | |||||