Export limit exceeded: 10107 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10107 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-79275 | 1 Google | 1 Chrome | 2026-08-31 | 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-80680 | 1 Linux | 1 Linux Kernel | 2026-08-29 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: i2c: amd-mp2: Unregister callback on adapter add failure amd_mp2_register_cb() stores the platform I2C context in the MP2 PCI driver's callback table before the adapter is registered. If i2c_add_adapter() fails, probe returns and devres frees the context, but the PCI driver can still dereference the stale pointer from its IRQ and system-sleep callbacks. Unregister the callback before returning the adapter registration error. | ||||
| 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-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-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-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) | ||||
| CVE-2026-79026 | 1 Google | 1 Chrome | 2026-08-27 | 9.6 Critical |
| Use after free in Extensions in Google Chrome prior to 152.0.7977.65 allowed a remote attacker leveraging social engineering to potentially execute arbitrary code outside the sandbox via a crafted Chrome extension. (Chromium security severity: High) | ||||
| CVE-2026-79119 | 1 Google | 1 Chrome | 2026-08-27 | 8.8 High |
| Use after free in PDF in Google Chrome prior to 152.0.7977.65 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted PDF file. (Chromium security severity: Low) | ||||