Export limit exceeded: 48707 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (8856 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-80661 | 1 Linux | 1 Linux Kernel | 2026-08-29 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ufs: core: tracing: Do not dereference pointers in TP_printk() The trace events in drivers/ufs/core/ufs_trace.h were converted to take a pointer to the hba structure as an argument for the tracepoint and then in TP_printk() the printing of the dev_name from the ring buffer was converted to using the dev dereferenced pointer from the hba saved pointer. This is not allowed as the TP_printk() is executed at the time the trace event is read from /sys/kernel/tracing/trace file. That can happen literally, seconds, minutes, hours, weeks, days, or even months later! There is no guarantee that the hba pointer will still exist by the time it is dereferenced when the "trace" file is read. Instead, save the device name from the hba pointer at the time the tracepoint is called and place it into the ring buffer event. Then the TP_printk() can read the name directly from the ring buffer and remove the possibility that it will read a freed pointer and crash the kernel. This was detected when testing the trace event code that looks for TP_printk() parameters doing illegal derferences[1] [1] https://lore.kernel.org/all/20260630184836.74d477b6@gandalf.local.home/ | ||||
| CVE-2026-80716 | 1 Linux | 1 Linux Kernel | 2026-08-29 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: wake linked drain waiters on unlink snd_pcm_drain() on a linked stream parks an on-stack wait entry on the drained peer's runtime->sleep, and after schedule_timeout() removes it only if that peer is still found in the caller's group. If group membership changes during the wait and the sleep ends by signal or timeout (so autoremove_wake_function() does not run), finish_wait() is skipped and snd_pcm_drain() returns with the entry still queued on that stream's sleep list; a later wake_up() then walks a freed stack frame. This is reachable by unlinking either the drained or the draining stream. Unlike the close path (snd_pcm_drop() -> snd_pcm_post_stop()), snd_pcm_unlink() never wakes the sleep queues. Wake every group member under the group lock before the membership change, so a linked drainer is released and drops its entry while the streams are still grouped. The window was opened when snd_pcm_link_rwsem stopped being held across the wait and the removal became conditional on group membership (see Fixes). The later switch to finish_wait() kept that conditional removal, so the signal/timeout case remained. | ||||
| CVE-2026-80681 | 1 Linux | 1 Linux Kernel | 2026-08-29 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: vxlan: re-fetch eth header after route_shortcircuit() Before route_shortcircuit(), the eth header pointer is cached from eth_hdr(skb). Inside route_shortcircuit(), pskb_may_pull() can be called, which may reallocate skb->head. In this case, returning to vxlan_xmit() leaves the cached eth pointer pointing to freed memory, leading to a use-after-free when dereferencing eth->h_dest. Fix this by updating eth = eth_hdr(skb) after calling route_shortcircuit(). | ||||
| CVE-2026-26447 | 2026-08-28 | 7.5 High | ||
| Stomper 5e2741e is vulnerable to Use-After-Free. When a single client repeatedly issues SUBSCRIBE commands for the same destination over one connection and then closes that connection, the broker performs incorrect cleanup of its internal subscription structures. This results in a heap use-after-free during StompClient destruction, causing the broker process to crash. An unauthenticated client can exploit this to reliably trigger a denial of service. | ||||
| CVE-2026-26448 | 2026-08-28 | 9.8 Critical | ||
| Stomper 5e2741e is vulnerable to Use-After-Free. When a client sends multiple CONNECT frames on the same TCP connection, and subsequently another client (or a later connection) sends SEND frames to a destination previously subscribed on that connection, the broker may dereference a pointer to a StompStreamSocket object that has already been freed. This results in a heap use-after-free and process crash. Because the protocol does not authenticate or restrict such sequences by default. | ||||
| CVE-2026-19316 | 1 Watchguard | 1 Fireware Os | 2026-08-28 | N/A |
| A double-free vulnerability in the WatchGuard Fireware OS iked process allows a remote unauthenticated attacker to create a Denial of Service (DoS) condition in VPN processing by sending specially crafted network traffic. | ||||
| CVE-2026-80654 | 1 Linux | 1 Linux Kernel | 2026-08-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: soc: xilinx: Shutdown and free rx mailbox channel A mbox rx channel is requested using mbox_request_channel_byname() in probe. In remove callback, the rx mailbox channel is cleaned up when the rx_chan is NULL due to incorrect condition check. The mailbox channel is not shutdown and it can receive messages even after the device removal. This leads to use after free. Also the channel resources are not freed. Fix this by checking the rx_chan correctly. | ||||
| CVE-2026-77235 | 2 Amazon, Freertos | 2 Freertos, Freertos-kernel | 2026-08-27 | 7.3 High |
| Missing privilege verification in the secure context cleanup handler in FreeRTOS-Kernel before 11.3.1 might allow local users to cause a use-after-free condition in secure-world memory via the SVC handler for secure context deallocation. To remediate this issue, users should upgrade to version 11.3.1 or later. | ||||
| CVE-2026-79183 | 1 Google | 1 Chrome | 2026-08-27 | 8.8 High |
| Use after free in Accessibility in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to execute arbitrary code outside the sandbox via UI Interaction. (Chromium security severity: High) | ||||
| CVE-2026-18299 | 1 Gstreamer | 1 Gstreamer | 2026-08-27 | 8.8 High |
| GStreamer rtpsbcdepay Use-After-Free Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GStreamer. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the processing of RTP payload elements. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-29787. | ||||
| CVE-2026-79194 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-08-27 | 8.1 High |
| Use after free in Chromoting in Google Chrome on on Windows prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code outside the sandbox via crafted network traffic. (Chromium security severity: High) | ||||
| CVE-2026-79187 | 1 Google | 1 Chrome | 2026-08-27 | 8.8 High |
| Use after free in WebRTC in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-79150 | 2 Apple, Google | 2 Macos, Chrome | 2026-08-27 | 9.6 Critical |
| Use after free in Views in Google Chrome on on Mac prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Critical) | ||||
| CVE-2026-79149 | 1 Google | 1 Chrome | 2026-08-27 | 9.6 Critical |
| Use after free in ANGLE in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-79140 | 2 Apple, Google | 2 Macos, Chrome | 2026-08-27 | 9.6 Critical |
| Use after free in Views in Google Chrome on on Mac prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-79128 | 2 Apple, Google | 2 Macos, Chrome | 2026-08-27 | 9.6 Critical |
| Use after free in Views in Google Chrome on on Mac prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-79129 | 1 Google | 2 Android, Chrome | 2026-08-27 | 9.6 Critical |
| Use after free in Sessions in Google Chrome on on Android prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to execute arbitrary code outside the sandbox via UI Interaction. (Chromium security severity: Medium) | ||||
| CVE-2026-74637 | 1 Linux | 1 Linux Kernel | 2026-08-27 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix group leader use-after-free after sibling detach perf_group_detach() handles leader and sibling detach differently. When the group leader is detached, all siblings are promoted to singleton events and their group_leader pointer is reset to themselves. When a sibling is detached, it is removed from the leader's sibling_list, but its group_leader pointer is left pointing at the old leader. That is harmless when the sibling is being closed and freed immediately, as in the DETACH_DEAD path. It is not safe when the sibling is detached but kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the sibling is removed from the context, while its file descriptor can still keep it alive. A typical failing sequence is: - A group contains leader L and sibling S. - CPU hot-unplug detaches S with DETACH_GROUP, removing it from L->sibling_list but leaving S->group_leader == L. - L is later closed and freed. - A PERF_IOC_FLAG_GROUP ioctl on S follows S->group_leader and dereferences the freed leader. This was reproduced by running the perf event fuzzer, CPU hotplug, and a stress workload concurrently: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT pc : perf_ioctl+0x34c/0xc68 x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908) Call trace: perf_ioctl+0x34c/0xc68 (P) __arm64_sys_ioctl+0xa0/0xf4 invoke_syscall+0x58/0xe4 el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x40/0xc0 el0t_64_sync_handler+0x68/0xdc el0t_64_sync+0x1c4/0x1c8 The fault happened in perf_ioctl(), where perf_event_for_each() follows the stale group_leader pointer and perf_event_for_each_child() then dereferences the freed leader's context. Fix the use-after-free by promoting the detached sibling to a singleton. Also fix __event_disable() cgroup accounting and event state change. | ||||
| CVE-2026-64216 | 1 Linux | 1 Linux Kernel | 2026-08-27 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix potential UAF in netfs_unlock_abandoned_read_pages() netfs_unlock_abandoned_read_pages(rreq) accesses the index of the folios it is wanting to unlock and compares that to rreq->no_unlock_folio so that it doesn't unlock a folio being read for netfs_perform_write() or netfs_write_begin(). However, given that netfs_unlock_abandoned_read_pages() is called _after_ NETFS_RREQ_IN_PROGRESS is cleared, the one folio that it's not allowed to dereference is the one specified by ->no_unlock_folio as ownership immediately reverts to the caller. Fix this by storing the folio pointer instead and using that rather than the index. Also fix netfs_unlock_read_folio() where the same applies. | ||||
| CVE-2026-79039 | 2 Apple, Google | 2 Iphone Os, Chrome | 2026-08-27 | 8.1 High |
| Use after free in Mobile in Google Chrome on on iOS prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code outside the sandbox via crafted network traffic. (Chromium security severity: High) | ||||