Total
2370 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-20835 | 3 Google, Linuxfoundation, Mediatek | 9 Android, Yocto, Iot Yocto and 6 more | 2026-06-17 | N/A | 6.4 MEDIUM |
| In camsys, 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. Patch ID: ALPS07341261; Issue ID: ALPS07326570. | |||||
| CVE-2023-20834 | 2 Google, Mediatek | 11 Android, Mt6879, Mt6886 and 8 more | 2026-06-17 | N/A | 6.4 MEDIUM |
| In pda, 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. Patch ID: ALPS07608514; Issue ID: ALPS07608514. | |||||
| CVE-2023-20827 | 2 Google, Mediatek | 32 Android, Mt6761, Mt6762 and 29 more | 2026-06-17 | N/A | 6.4 MEDIUM |
| In ims service, there is a possible memory corruption 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. Patch ID: ALPS07937105; Issue ID: ALPS07937105. | |||||
| CVE-2023-20801 | 3 Google, Linuxfoundation, Mediatek | 9 Android, Yocto, Mt6879 and 6 more | 2026-06-17 | N/A | 6.4 MEDIUM |
| In imgsys, 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. Patch ID: ALPS07420968; Issue ID: ALPS07420968. | |||||
| CVE-2023-20771 | 2 Google, Mediatek | 11 Android, Mt6580, Mt6739 and 8 more | 2026-06-17 | N/A | 6.4 MEDIUM |
| In display, there is a possible memory corruption 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. Patch ID: ALPS07671046; Issue ID: ALPS07671046. | |||||
| CVE-2023-20750 | 2 Google, Mediatek | 23 Android, Mt6835, Mt6886 and 20 more | 2026-06-17 | N/A | 4.1 MEDIUM |
| In swpm, there is a possible out of bounds write due to a race condition. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07780926; Issue ID: ALPS07780928. | |||||
| CVE-2023-20736 | 3 Google, Linuxfoundation, Mediatek | 23 Android, Iot-yocto, Yocto and 20 more | 2026-06-17 | N/A | 6.4 MEDIUM |
| In vcu, 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. Patch ID: ALPS07645149; Issue ID: ALPS07645189. | |||||
| CVE-2023-20687 | 2 Google, Mediatek | 5 Android, Mt6879, Mt6895 and 2 more | 2026-06-17 | N/A | 6.4 MEDIUM |
| In display drm, there is a possible double 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. Patch ID: ALPS07570772; Issue ID: ALPS07570772. | |||||
| CVE-2023-20686 | 2 Google, Mediatek | 5 Android, Mt6879, Mt6895 and 2 more | 2026-06-17 | N/A | 6.4 MEDIUM |
| In display drm, there is a possible double 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. Patch ID: ALPS07570826; Issue ID: ALPS07570826. | |||||
| CVE-2023-20685 | 2 Google, Mediatek | 11 Android, Mt6789, Mt6855 and 8 more | 2026-06-17 | N/A | 6.4 MEDIUM |
| In vdec, 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. Patch ID: ALPS07608575; Issue ID: ALPS07608575. | |||||
| CVE-2023-20684 | 2 Google, Mediatek | 11 Android, Mt6789, Mt6855 and 8 more | 2026-06-17 | N/A | 6.4 MEDIUM |
| In vdec, 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. Patch ID: ALPS07671069; Issue ID: ALPS07671069. | |||||
| CVE-2023-20571 | 1 Amd | 142 Ryzen 3 5100, Ryzen 3 5100 Firmware, Ryzen 3 5125c and 139 more | 2026-06-17 | N/A | 8.1 HIGH |
| A race condition in System Management Mode (SMM) code may allow an attacker using a compromised user space to leverage CVE-2018-8897 potentially resulting in privilege escalation. | |||||
| CVE-2023-1672 | 3 Fedoraproject, Redhat, Tang Project | 3 Fedora, Enterprise Linux, Tang | 2026-06-17 | N/A | 5.3 MEDIUM |
| A race condition exists in the Tang server functionality for key generation and key rotation. This flaw results in a small time window where Tang private keys become readable by other processes on the same host. | |||||
| CVE-2023-1582 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 4.7 MEDIUM |
| A race problem was found in fs/proc/task_mmu.c in the memory management sub-component in the Linux kernel. This issue may allow a local attacker with user privilege to cause a denial of service. | |||||
| CVE-2023-1285 | 1 Mitsubishielectric | 2 Gc-enet-com, Gc-enet-com Firmware | 2026-06-17 | N/A | 7.5 HIGH |
| Signal Handler Race Condition vulnerability in Mitsubishi Electric India GC-ENET-COM whose first 2 digits of 11-digit serial number of unit are "16" allows a remote unauthenticated attacker to cause a denial-of-service (DoS) condition in Ethernet communication by sending a large number of specially crafted packets to any UDP port when GC-ENET-COM is configured as a Modbus TCP Server. The communication resumes only when the power of the main unit is turned off and on or when the GC-ENET-COM is hot-swapped from the main unit. | |||||
| CVE-2023-0739 | 1 Answer | 1 Answer | 2026-06-17 | N/A | 6.8 MEDIUM |
| Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') in GitHub repository answerdev/answer prior to 1.0.4. | |||||
| CVE-2022-50379 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between quota enable and quota rescan ioctl When enabling quotas, at btrfs_quota_enable(), after committing the transaction, we change fs_info->quota_root to point to the quota root we created and set BTRFS_FS_QUOTA_ENABLED at fs_info->flags. Then we try to start the qgroup rescan worker, first by initializing it with a call to qgroup_rescan_init() - however if that fails we end up freeing the quota root but we leave fs_info->quota_root still pointing to it, this can later result in a use-after-free somewhere else. We have previously set the flags BTRFS_FS_QUOTA_ENABLED and BTRFS_QGROUP_STATUS_FLAG_ON, so we can only fail with -EINPROGRESS at btrfs_quota_enable(), which is possible if someone already called the quota rescan ioctl, and therefore started the rescan worker. So fix this by ignoring an -EINPROGRESS and asserting we can't get any other error. | |||||
| CVE-2022-50373 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix race in lowcomms This patch fixes a race between queue_work() in _dlm_lowcomms_commit_msg() and srcu_read_unlock(). The queue_work() can take the final reference of a dlm_msg and so msg->idx can contain garbage which is signaled by the following warning: [ 676.237050] ------------[ cut here ]------------ [ 676.237052] WARNING: CPU: 0 PID: 1060 at include/linux/srcu.h:189 dlm_lowcomms_commit_msg+0x41/0x50 [ 676.238945] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common iTCO_wdt iTCO_vendor_support qxl kvm_intel drm_ttm_helper vmw_vsock_virtio_transport kvm vmw_vsock_virtio_transport_common ttm irqbypass crc32_pclmul joydev crc32c_intel serio_raw drm_kms_helper vsock virtio_scsi virtio_console virtio_balloon snd_pcm drm syscopyarea sysfillrect sysimgblt snd_timer fb_sys_fops i2c_i801 lpc_ich snd i2c_smbus soundcore pcspkr [ 676.244227] CPU: 0 PID: 1060 Comm: lock_torture_wr Not tainted 5.19.0-rc3+ #1546 [ 676.245216] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 676.246460] RIP: 0010:dlm_lowcomms_commit_msg+0x41/0x50 [ 676.247132] Code: fe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 <0f> 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 [ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282 [ 676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006 [ 676.250713] RDX: 0000000000000000 RSI: ffffffffbccf3a10 RDI: ffffffffbcc7b62e [ 676.251610] RBP: ffffa401c18ffc70 R08: 0000000000000001 R09: 0000000000000001 [ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000005 [ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480 [ 676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000 [ 676.255239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0 [ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 676.258397] PKRU: 55555554 [ 676.258729] Call Trace: [ 676.259063] <TASK> [ 676.259354] dlm_midcomms_commit_mhandle+0xcc/0x110 [ 676.259964] queue_bast+0x8b/0xb0 [ 676.260423] grant_pending_locks+0x166/0x1b0 [ 676.261007] _unlock_lock+0x75/0x90 [ 676.261469] unlock_lock.isra.57+0x62/0xa0 [ 676.262009] dlm_unlock+0x21e/0x330 [ 676.262457] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 676.263183] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 676.263815] ? preempt_count_sub+0xba/0x100 [ 676.264361] ? complete+0x1d/0x60 [ 676.264777] lock_torture_writer+0xb8/0x150 [dlm_locktorture] [ 676.265555] kthread+0x10a/0x130 [ 676.266007] ? kthread_complete_and_exit+0x20/0x20 [ 676.266616] ret_from_fork+0x22/0x30 [ 676.267097] </TASK> [ 676.267381] irq event stamp: 9579855 [ 676.267824] hardirqs last enabled at (9579863): [<ffffffffbb14e6f8>] __up_console_sem+0x58/0x60 [ 676.268896] hardirqs last disabled at (9579872): [<ffffffffbb14e6dd>] __up_console_sem+0x3d/0x60 [ 676.270008] softirqs last enabled at (9579798): [<ffffffffbc200349>] __do_softirq+0x349/0x4c7 [ 676.271438] softirqs last disabled at (9579897): [<ffffffffbb0d54c0>] irq_exit_rcu+0xb0/0xf0 [ 676.272796] ---[ end trace 0000000000000000 ]--- I reproduced this warning with dlm_locktorture test which is currently not upstream. However this patch fix the issue by make a additional refcount between dlm_lowcomms_new_msg() and dlm_lowcomms_commit_msg(). In case of the race the kref_put() in dlm_lowcomms_commit_msg() will be the final put. | |||||
| CVE-2022-50350 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix a race condition between login_work and the login thread In case a malicious initiator sends some random data immediately after a login PDU; the iscsi_target_sk_data_ready() callback will schedule the login_work and, at the same time, the negotiation may end without clearing the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are required to complete the login). The login has been completed but the login_work function will find the LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling itself; at this point, if the initiator drops the connection, the iscsit_conn structure will be freed, login_work will dereference a released socket structure and the kernel crashes. BUG: kernel NULL pointer dereference, address: 0000000000000230 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod] RIP: 0010:_raw_read_lock_bh+0x15/0x30 Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0 Fix this bug by forcing login_work to stop after the login has been completed and the socket callbacks have been restored. Add a comment to clearify the return values of iscsi_target_do_login() | |||||
| CVE-2022-50339 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 7.0 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: avoid hci_dev_test_and_set_flag() in mgmt_init_hdev() syzbot is again reporting attempt to cancel uninitialized work at mgmt_index_removed() [1], for setting of HCI_MGMT flag from mgmt_init_hdev() from hci_mgmt_cmd() from hci_sock_sendmsg() can race with testing of HCI_MGMT flag from mgmt_index_removed() from hci_sock_bind() due to lack of serialization via hci_dev_lock(). Since mgmt_init_hdev() is called with mgmt_chan_list_lock held, we can safely split hci_dev_test_and_set_flag() into hci_dev_test_flag() and hci_dev_set_flag(). Thus, in order to close this race, set HCI_MGMT flag after INIT_DELAYED_WORK() completed. This is a local fix based on mgmt_chan_list_lock. Lack of serialization via hci_dev_lock() might be causing different race conditions somewhere else. But a global fix based on hci_dev_lock() should deserve a future patch. | |||||