Export limit exceeded: 414481 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 414481 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3299 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-65358 | 1 Apple | 7 Ios And Ipados, Ipados, Iphone Os and 4 more | 2026-09-20 | 4.7 Medium |
| A race condition was addressed with improved state handling. This issue is fixed in iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, tvOS 27, visionOS 27, watchOS 27. An app may be able to cause unexpected system termination. | ||||
| CVE-2026-65401 | 1 Apple | 1 Macos | 2026-09-20 | 5.5 Medium |
| A race condition was addressed with improved state handling. This issue is fixed in macOS Golden Gate 27, macOS Tahoe 26.7. An app may be able to cause unexpected system termination. | ||||
| CVE-2026-84562 | 1 Apple | 1 Macos | 2026-09-20 | 4.7 Medium |
| A race condition was addressed with additional validation. This issue is fixed in macOS Tahoe 26.6. An app may be able to access protected user data. | ||||
| CVE-2026-65415 | 1 Apple | 7 Ios And Ipados, Ipados, Iphone Os and 4 more | 2026-09-20 | 8.1 High |
| A race condition was addressed with additional validation. This issue is fixed in iOS 27 and iPadOS 27, macOS Golden Gate 27, tvOS 27, visionOS 27, watchOS 27. A local user may be able to cause unexpected system termination or read kernel memory. | ||||
| CVE-2026-84607 | 1 Apple | 7 Ios And Ipados, Ipados, Iphone Os and 4 more | 2026-09-20 | 7.8 High |
| A race condition was addressed with improved state management. This issue is fixed in iOS 26.7 and iPadOS 26.7, iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, tvOS 27, visionOS 27, watchOS 27. A sandboxed app may be able to execute arbitrary code with kernel privileges. | ||||
| CVE-2026-84522 | 1 Apple | 1 Macos | 2026-09-20 | 5.9 Medium |
| A race condition was addressed with improved state management. This issue is fixed in macOS Golden Gate 27. An app may be able to access sensitive user data. | ||||
| CVE-2026-43690 | 1 Apple | 1 Macos | 2026-09-20 | 4.7 Medium |
| A race condition was addressed with improved locking. This issue is fixed in macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7. A local user may be able to read kernel memory. | ||||
| CVE-2026-84630 | 1 Apple | 7 Ios And Ipados, Ipados, Iphone Os and 4 more | 2026-09-20 | 4.7 Medium |
| A race condition was addressed with improved state handling. This issue is fixed in iOS 26.7 and iPadOS 26.7, iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, tvOS 27, visionOS 27, watchOS 27. An app may be able to cause unexpected system termination. | ||||
| CVE-2026-64717 | 1 Apple | 7 Ios And Ipados, Ipados, Iphone Os and 4 more | 2026-09-20 | 6.3 Medium |
| A race condition was addressed with improved state handling. This issue is fixed in iOS 18.7.10 and iPadOS 18.7.10, iOS 26.6 and iPadOS 26.6, macOS Sequoia 15.7.8, macOS Tahoe 26.6, tvOS 26.6, visionOS 26.6, watchOS 26.6. An app may be able to cause unexpected system termination or corrupt kernel memory. | ||||
| CVE-2026-84492 | 1 Apple | 7 Ios And Ipados, Ipados, Iphone Os and 4 more | 2026-09-20 | 4.7 Medium |
| A race condition was addressed with improved state handling. This issue is fixed in iOS 26.7 and iPadOS 26.7, iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, tvOS 27, visionOS 27, watchOS 27. An app may be able to cause unexpected system termination. | ||||
| CVE-2026-58728 | 1 Google | 1 Android | 2026-09-20 | 7 High |
| In ARM64_TLBI of mmu.h, there is a possible memory corruption due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-58734 | 1 Google | 1 Android | 2026-09-20 | 7 High |
| In google_mba_recv_msg of google_mba_poll.c, there is a possible out-of-bounds write due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-56988 | 1 Google | 1 Android | 2026-09-20 | 6.4 Medium |
| In multiple functions of bluetooth_cco.cc, there is a possible use-after-free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-58701 | 1 Google | 1 Android | 2026-09-20 | 7 High |
| In trusty_dputc of generic-arm64-smcall.c, there is a possible out-of-bounds write due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-58716 | 1 Google | 1 Android | 2026-09-20 | 6.7 Medium |
| In multiple locations, there is a possible time-of-check to time-of-use due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-58724 | 1 Google | 1 Android | 2026-09-20 | 7 High |
| In multiple locations, there is a possible use-after-free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2026-90092 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference. l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking: [Task 1] [Task 2] l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */ Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races. Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case. | ||||
| CVE-2026-91723 | 1 Google | 1 Chrome | 2026-09-20 | 4.2 Medium |
| Race condition in WebAppInstalls in Google Chrome prior to 153.0.8010.47 allowed a remote attacker to spoof UI elements via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-90081 | 1 Linux | 1 Linux Kernel | 2026-09-20 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net/rds: use wq_has_sleeper() in rds_cong_map_updated() rds_cong_map_updated() runs after a peer's congestion map has been rewritten (by rds_tcp_cong_recv() and rds_ib_cong_recv(), or the clear-all in the loopback and IB send-completion paths). It bumps rds_cong_generation and then checks waitqueue_active() on map->m_waitq and on rds_poll_waitq to decide whether anyone needs waking. atomic_inc() carries no ordering and waitqueue_active() is a plain load, so nothing orders the map and generation stores before the wait queue reads. The waiters do the mirror image: rds_cong_wait() adds itself to m_waitq and then tests the port bit, and rds_poll() registers on rds_poll_waitq and then reads the generation. That is the store-buffering pattern described above waitqueue_active() in include/linux/wait.h - the updater can observe an empty wait queue while the waiter still observes the port as congested, and no wake-up is issued. rds_cong_wait() is an interruptible sleep with no timeout, so a sender blocked on a congested port stays blocked until the next congestion update from that peer arrives or a signal is delivered. A poll() waiter misses the map-updated notification the same way. Use wq_has_sleeper(), which is waitqueue_active() preceded by the required full barrier, as rds_tcp_state_change() already does for the same pattern. | ||||
| CVE-2026-90176 | 1 Linux | 1 Linux Kernel | 2026-09-20 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: Do not skip lock checks for single-byte ranges check_lock_range() uses inclusive ranges. Its callers pass the end offset as start + length - 1, so start == end represents a valid single-byte range rather than an empty range. The start == end shortcut therefore skips mandatory byte-range lock checks for one-byte reads, writes, copychunk operations and one-byte truncate ranges. A conflicting lock covering that byte is not checked and the operation is allowed to proceed. Remove the shortcut. The truncate size == inode->i_size case is already handled by only calling check_lock_range() when the new size differs from the current file size. | ||||