Total
6246 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-43758 | 3 Adobe, Apple, Microsoft | 3 Illustrator, Macos, Windows | 2024-09-13 | N/A | 7.8 HIGH |
| Illustrator versions 28.6, 27.9.5 and earlier are affected by a Use After Free 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-46696 | 1 Linux | 1 Linux Kernel | 2024-09-13 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: fix potential UAF in nfsd4_cb_getattr_release Once we drop the delegation reference, the fields embedded in it are no longer safe to access. Do that last. | |||||
| CVE-2024-46683 | 1 Linux | 1 Linux Kernel | 2024-09-13 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe: prevent UAF around preempt fence The fence lock is part of the queue, therefore in the current design anything locking the fence should then also hold a ref to the queue to prevent the queue from being freed. However, currently it looks like we signal the fence and then drop the queue ref, but if something is waiting on the fence, the waiter is kicked to wake up at some later point, where upon waking up it first grabs the lock before checking the fence state. But if we have already dropped the queue ref, then the lock might already be freed as part of the queue, leading to uaf. To prevent this, move the fence lock into the fence itself so we don't run into lifetime issues. Alternative might be to have device level lock, or only release the queue in the fence release callback, however that might require pushing to another worker to avoid locking issues. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2454 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2342 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2020 (cherry picked from commit 7116c35aacedc38be6d15bd21b2fc936eed0008b) | |||||
| CVE-2024-45013 | 1 Linux | 1 Linux Kernel | 2024-09-13 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nvme: move stopping keep-alive into nvme_uninit_ctrl() Commit 4733b65d82bd ("nvme: start keep-alive after admin queue setup") moves starting keep-alive from nvme_start_ctrl() into nvme_init_ctrl_finish(), but don't move stopping keep-alive into nvme_uninit_ctrl(), so keep-alive work can be started and keep pending after failing to start controller, finally use-after-free is triggered if nvme host driver is unloaded. This patch fixes kernel panic when running nvme/004 in case that connection failure is triggered, by moving stopping keep-alive into nvme_uninit_ctrl(). This way is reasonable because keep-alive is now started in nvme_init_ctrl_finish(). | |||||
| CVE-2024-38252 | 1 Microsoft | 12 Windows 10 1607, Windows 10 1809, Windows 10 21h1 and 9 more | 2024-09-13 | N/A | 7.8 HIGH |
| Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability | |||||
| CVE-2024-38253 | 1 Microsoft | 5 Windows 11 21h2, Windows 11 22h2, Windows 11 23h2 and 2 more | 2024-09-13 | N/A | 7.8 HIGH |
| Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability | |||||
| CVE-2024-43465 | 1 Microsoft | 5 365 Apps, Excel, Office and 2 more | 2024-09-13 | N/A | 7.8 HIGH |
| Microsoft Excel Elevation of Privilege Vulnerability | |||||
| CVE-2024-8639 | 1 Google | 2 Android, Chrome | 2024-09-13 | N/A | 8.8 HIGH |
| Use after free in Autofill in Google Chrome on Android prior to 128.0.6613.137 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2024-8638 | 1 Google | 1 Chrome | 2024-09-13 | N/A | 8.8 HIGH |
| Type Confusion in V8 in Google Chrome prior to 128.0.6613.137 allowed a remote attacker to potentially exploit object corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2024-8637 | 1 Google | 2 Android, Chrome | 2024-09-13 | N/A | 8.8 HIGH |
| Use after free in Media Router in Google Chrome on Android prior to 128.0.6613.137 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2024-8636 | 1 Google | 1 Chrome | 2024-09-13 | N/A | 8.8 HIGH |
| Heap buffer overflow in Skia in Google Chrome prior to 128.0.6613.137 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2024-44941 | 1 Linux | 1 Linux Kernel | 2024-09-12 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to cover read extent cache access with lock syzbot reports a f2fs bug as below: BUG: KASAN: slab-use-after-free in sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46 Read of size 4 at addr ffff8880739ab220 by task syz-executor200/5097 CPU: 0 PID: 5097 Comm: syz-executor200 Not tainted 6.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46 do_read_inode fs/f2fs/inode.c:509 [inline] f2fs_iget+0x33e1/0x46e0 fs/f2fs/inode.c:560 f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237 generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413 exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444 exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584 do_handle_to_path fs/fhandle.c:155 [inline] handle_to_path fs/fhandle.c:210 [inline] do_handle_open+0x495/0x650 fs/fhandle.c:226 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f We missed to cover sanity_check_extent_cache() w/ extent cache lock, so, below race case may happen, result in use after free issue. - f2fs_iget - do_read_inode - f2fs_init_read_extent_tree : add largest extent entry in to cache - shrink - f2fs_shrink_read_extent_tree - __shrink_extent_tree - __detach_extent_node : drop largest extent entry - sanity_check_extent_cache : access et->largest w/o lock let's refactor sanity_check_extent_cache() to avoid extent cache access and call it before f2fs_init_read_extent_tree() to fix this issue. | |||||
| CVE-2023-52907 | 1 Linux | 1 Linux Kernel | 2024-09-12 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame() Fix a use-after-free that occurs in hcd when in_urb sent from pn533_usb_send_frame() is completed earlier than out_urb. Its callback frees the skb data in pn533_send_async_complete() that is used as a transfer buffer of out_urb. Wait before sending in_urb until the callback of out_urb is called. To modify the callback of out_urb alone, separate the complete function of out_urb and ack_urb. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in dummy_timer Call Trace: memcpy (mm/kasan/shadow.c:65) dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352) transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972) arch_static_branch (arch/x86/include/asm/jump_label.h:27) static_key_false (include/linux/jump_label.h:207) timer_expire_exit (include/trace/events/timer.h:127) call_timer_fn (kernel/time/timer.c:1475) expire_timers (kernel/time/timer.c:1519) __run_timers (kernel/time/timer.c:1790) run_timer_softirq (kernel/time/timer.c:1803) | |||||
| CVE-2022-48911 | 1 Linux | 1 Linux Kernel | 2024-09-12 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_queue: fix possible use-after-free Eric Dumazet says: The sock_hold() side seems suspect, because there is no guarantee that sk_refcnt is not already 0. On failure, we cannot queue the packet and need to indicate an error. The packet will be dropped by the caller. v2: split skb prefetch hunk into separate change | |||||
| CVE-2022-48899 | 1 Linux | 1 Linux Kernel | 2024-09-11 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix GEM handle creation UAF Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object. | |||||
| CVE-2024-44978 | 1 Linux | 1 Linux Kernel | 2024-09-10 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe: Free job before xe_exec_queue_put Free job depends on job->vm being valid, the last xe_exec_queue_put can destroy the VM. Prevent UAF by freeing job before xe_exec_queue_put. (cherry picked from commit 32a42c93b74c8ca6d0915ea3eba21bceff53042f) | |||||
| CVE-2024-2937 | 1 Arm | 3 5th Gen Gpu Architecture Kernel Driver, Bifrost Gpu Kernel Driver, Valhall Gpu Kernel Driver | 2024-09-10 | N/A | 7.8 HIGH |
| Use After Free vulnerability in Arm Ltd Bifrost GPU Kernel Driver, Arm Ltd Valhall GPU Kernel Driver, Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a local non-privileged user to make improper GPU memory processing operations to gain access to already freed memory.This issue affects Bifrost GPU Kernel Driver: from r41p0 through r49p0; Valhall GPU Kernel Driver: from r41p0 through r49p0; Arm 5th Gen GPU Architecture Kernel Driver: from r41p0 through r49p0. | |||||
| CVE-2024-4607 | 1 Arm | 3 5th Gen Gpu Architecture Kernel Driver, Bifrost Gpu Kernel Driver, Valhall Gpu Kernel Driver | 2024-09-10 | N/A | 7.8 HIGH |
| Use After Free vulnerability in Arm Ltd Bifrost GPU Kernel Driver, Arm Ltd Valhall GPU Kernel Driver, Arm Ltd Arm 5th Gen GPU Architecture Kernel Driver allows a local non-privileged user to make improper GPU memory processing operations to gain access to already freed memory.This issue affects Bifrost GPU Kernel Driver: from r41p0 through r49p0; Valhall GPU Kernel Driver: from r41p0 through r49p0; Arm 5th Gen GPU Architecture Kernel Driver: from r41p0 through r49p0. | |||||
| CVE-2024-41160 | 1 Openatom | 1 Openharmony | 2024-09-09 | N/A | 8.8 HIGH |
| in OpenHarmony v4.1.0 and prior versions allow a local attacker cause the common permission is upgraded to root and sensitive information leak through use after free. | |||||
| CVE-2024-44964 | 1 Linux | 1 Linux Kernel | 2024-09-06 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: idpf: fix memory leaks and crashes while performing a soft reset The second tagged commit introduced a UAF, as it removed restoring q_vector->vport pointers after reinitializating the structures. This is due to that all queue allocation functions are performed here with the new temporary vport structure and those functions rewrite the backpointers to the vport. Then, this new struct is freed and the pointers start leading to nowhere. But generally speaking, the current logic is very fragile. It claims to be more reliable when the system is low on memory, but in fact, it consumes two times more memory as at the moment of running this function, there are two vports allocated with their queues and vectors. Moreover, it claims to prevent the driver from running into "bad state", but in fact, any error during the rebuild leaves the old vport in the partially allocated state. Finally, if the interface is down when the function is called, it always allocates a new queue set, but when the user decides to enable the interface later on, vport_open() allocates them once again, IOW there's a clear memory leak here. Just don't allocate a new queue set when performing a reset, that solves crashes and memory leaks. Readd the old queue number and reopen the interface on rollback - that solves limbo states when the device is left disabled and/or without HW queues enabled. | |||||