Total
12136 CVE
CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
---|---|---|---|---|---|
CVE-2024-6259 | 1 Zephyrproject | 1 Zephyr | 2024-09-19 | N/A | 6.5 MEDIUM |
BT: HCI: adv_ext_report Improper discarding in adv_ext_report | |||||
CVE-2024-6137 | 1 Zephyrproject | 1 Zephyr | 2024-09-19 | N/A | 6.5 MEDIUM |
BT: Classic: SDP OOB access in get_att_search_list | |||||
CVE-2024-45181 | 2 Microsoft, Wibu | 2 Windows, Wibukey | 2024-09-18 | N/A | 7.8 HIGH |
An issue was discovered in WibuKey64.sys in WIBU-SYSTEMS WibuKey before v6.70 and fixed in v.6.70. An improper bounds check allows crafted packets to cause an arbitrary address write, resulting in kernel memory corruption. | |||||
CVE-2024-39378 | 3 Adobe, Apple, Microsoft | 3 Audition, Mac Os X, Windows | 2024-09-18 | N/A | 7.8 HIGH |
Audition versions 24.4.1, 23.6.6 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | |||||
CVE-2024-0110 | 1 Nvidia | 1 Cuda Toolkit | 2024-09-18 | N/A | 7.8 HIGH |
NVIDIA CUDA Toolkit contains a vulnerability in command `cuobjdump` where a user may cause an out-of-bound write by passing in a malformed ELF file. A successful exploit of this vulnerability may lead to code execution or denial of service. | |||||
CVE-2024-44093 | 1 Google | 1 Android | 2024-09-18 | N/A | 7.8 HIGH |
In ppmp_unprotect_buf of drm/code/drm_fw.c, there is a possible memory corruption due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | |||||
CVE-2024-44094 | 1 Google | 1 Android | 2024-09-18 | N/A | 7.8 HIGH |
In ppmp_protect_mfcfw_buf of code/drm_fw.c, there is a possible memory corruption due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | |||||
CVE-2024-7965 | 2 Google, Microsoft | 2 Chrome, Edge Chromium | 2024-09-18 | N/A | 8.8 HIGH |
Inappropriate implementation in V8 in Google Chrome prior to 128.0.6613.84 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | |||||
CVE-2024-45695 | 1 Dlink | 2 Dir-x4860, Dir-x4860 Firmware | 2024-09-17 | N/A | 9.8 CRITICAL |
The web service of certain models of D-Link wireless routers contains a Stack-based Buffer Overflow vulnerability, which allows unauthenticated remote attackers to exploit this vulnerability to execute arbitrary code on the device. | |||||
CVE-2023-22351 | 2024-09-16 | N/A | 6.1 MEDIUM | ||
Out-of-bounds write in UEFI firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access. | |||||
CVE-2024-39384 | 3 Adobe, Apple, Microsoft | 3 Premiere Pro, Macos, Windows | 2024-09-16 | N/A | 7.8 HIGH |
Premiere Pro versions 24.5, 23.6.8 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | |||||
CVE-2024-39377 | 3 Adobe, Apple, Microsoft | 3 Media Encoder, Macos, Windows | 2024-09-16 | N/A | 7.8 HIGH |
Media Encoder versions 24.5, 23.6.8 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | |||||
CVE-2024-43760 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2024-09-13 | N/A | 7.8 HIGH |
Photoshop Desktop versions 24.7.4, 25.11 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | |||||
CVE-2024-45108 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2024-09-13 | N/A | 7.8 HIGH |
Photoshop Desktop versions 24.7.4, 25.11 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | |||||
CVE-2024-45109 | 3 Adobe, Apple, Microsoft | 3 Photoshop, Macos, Windows | 2024-09-13 | N/A | 7.8 HIGH |
Photoshop Desktop versions 24.7.4, 25.11 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | |||||
CVE-2024-39381 | 3 Adobe, Apple, Microsoft | 3 After Effects, Macos, Windows | 2024-09-13 | N/A | 7.8 HIGH |
After Effects versions 23.6.6, 24.5 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | |||||
CVE-2024-41859 | 3 Adobe, Apple, Microsoft | 3 After Effects, Macos, Windows | 2024-09-13 | N/A | 7.8 HIGH |
After Effects versions 23.6.6, 24.5 and earlier are affected by an out-of-bounds write vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file. | |||||
CVE-2024-45020 | 1 Linux | 1 Linux Kernel | 2024-09-13 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a kernel verifier crash in stacksafe() Daniel Hodges reported a kernel verifier crash when playing with sched-ext. Further investigation shows that the crash is due to invalid memory access in stacksafe(). More specifically, it is the following code: if (exact != NOT_EXACT && old->stack[spi].slot_type[i % BPF_REG_SIZE] != cur->stack[spi].slot_type[i % BPF_REG_SIZE]) return false; The 'i' iterates old->allocated_stack. If cur->allocated_stack < old->allocated_stack the out-of-bound access will happen. To fix the issue add 'i >= cur->allocated_stack' check such that if the condition is true, stacksafe() should fail. Otherwise, cur->stack[spi].slot_type[i % BPF_REG_SIZE] memory access is legal. | |||||
CVE-2024-45022 | 1 Linux | 1 Linux Kernel | 2024-09-13 | 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-45023 | 1 Linux | 1 Linux Kernel | 2024-09-13 | N/A | 7.1 HIGH |
In the Linux kernel, the following vulnerability has been resolved: md/raid1: Fix data corruption for degraded array with slow disk read_balance() will avoid reading from slow disks as much as possible, however, if valid data only lands in slow disks, and a new normal disk is still in recovery, unrecovered data can be read: raid1_read_request read_balance raid1_should_read_first -> return false choose_best_rdev -> normal disk is not recovered, return -1 choose_bb_rdev -> missing the checking of recovery, return the normal disk -> read unrecovered data Root cause is that the checking of recovery is missing in choose_bb_rdev(). Hence add such checking to fix the problem. Also fix similar problem in choose_slow_rdev(). |