Total
2978 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-36884 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2026-08-10 | N/A | 7.5 HIGH |
| Windows Search Remote Code Execution Vulnerability | |||||
| CVE-2023-35378 | 1 Microsoft | 7 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 4 more | 2026-08-10 | N/A | 7.0 HIGH |
| Windows Projected File System Elevation of Privilege Vulnerability | |||||
| CVE-2022-41118 | 1 Microsoft | 9 Windows 10, Windows 11, Windows 7 and 6 more | 2026-08-10 | N/A | 7.5 HIGH |
| Windows Scripting Languages Remote Code Execution Vulnerability | |||||
| CVE-2022-41114 | 1 Microsoft | 3 Windows 10, Windows 11, Windows Server 2022 | 2026-08-10 | N/A | 7.0 HIGH |
| Windows Bind Filter Driver Elevation of Privilege Vulnerability | |||||
| CVE-2022-41100 | 1 Microsoft | 7 Windows 10, Windows 11, Windows 8.1 and 4 more | 2026-08-10 | N/A | 7.8 HIGH |
| Windows Advanced Local Procedure Call (ALPC) Elevation of Privilege Vulnerability | |||||
| CVE-2022-41093 | 1 Microsoft | 7 Windows 10, Windows 11, Windows 8.1 and 4 more | 2026-08-10 | N/A | 7.8 HIGH |
| Windows Advanced Local Procedure Call (ALPC) Elevation of Privilege Vulnerability | |||||
| CVE-2022-41090 | 1 Microsoft | 9 Windows 10, Windows 11, Windows 7 and 6 more | 2026-08-10 | N/A | 5.9 MEDIUM |
| Windows Point-to-Point Tunneling Protocol Denial of Service Vulnerability | |||||
| CVE-2022-41088 | 1 Microsoft | 7 Windows 10, Windows 11, Windows 8.1 and 4 more | 2026-08-10 | N/A | 8.1 HIGH |
| Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability | |||||
| CVE-2022-41086 | 1 Microsoft | 9 Windows 10, Windows 11, Windows 7 and 6 more | 2026-08-10 | N/A | 6.4 MEDIUM |
| Windows Group Policy Elevation of Privilege Vulnerability | |||||
| CVE-2022-41045 | 1 Microsoft | 10 Windows 10, Windows 11, Windows 7 and 7 more | 2026-08-10 | N/A | 7.8 HIGH |
| Windows Advanced Local Procedure Call (ALPC) Elevation of Privilege Vulnerability | |||||
| CVE-2022-41044 | 1 Microsoft | 2 Windows 7, Windows Server 2008 | 2026-08-10 | N/A | 8.1 HIGH |
| Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability | |||||
| CVE-2022-41039 | 1 Microsoft | 10 Windows 10, Windows 11, Windows 7 and 7 more | 2026-08-10 | N/A | 8.1 HIGH |
| Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability | |||||
| CVE-2022-38014 | 1 Microsoft | 2 Azure Iot Edge For Linux, Windows Subsystem For Linux | 2026-08-10 | N/A | 7.0 HIGH |
| Windows Subsystem for Linux (WSL2) Kernel Elevation of Privilege Vulnerability | |||||
| CVE-2021-34462 | 1 Microsoft | 3 Windows 10, Windows Server 2016, Windows Server 2019 | 2026-08-10 | 4.6 MEDIUM | 7.0 HIGH |
| Windows AppX Deployment Extensions Elevation of Privilege Vulnerability | |||||
| CVE-2023-6546 | 3 Fedoraproject, Linux, Redhat | 3 Fedora, Linux Kernel, Enterprise Linux | 2026-08-06 | N/A | 7.0 HIGH |
| A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate their privileges on the system. | |||||
| CVE-2023-6531 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-08-06 | N/A | 7.0 HIGH |
| A use-after-free flaw was found in the Linux Kernel due to a race problem in the unix garbage collector's deletion of SKB races with unix_stream_read_generic() on the socket that the SKB is queued on. | |||||
| CVE-2021-44733 | 5 Debian, Fedoraproject, Linux and 2 more | 20 Debian Linux, Fedora, Linux Kernel and 17 more | 2026-08-05 | 4.4 MEDIUM | 7.0 HIGH |
| A use-after-free exists in drivers/tee/tee_shm.c in the TEE subsystem in the Linux kernel through 5.15.11. This occurs because of a race condition in tee_shm_get_from_id during an attempt to free a shared memory object. | |||||
| CVE-2024-57893 | 1 Linux | 1 Linux Kernel | 2026-08-04 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: oss: Fix races at processing SysEx messages OSS sequencer handles the SysEx messages split in 6 bytes packets, and ALSA sequencer OSS layer tries to combine those. It stores the data in the internal buffer and this access is racy as of now, which may lead to the out-of-bounds access. As a temporary band-aid fix, introduce a mutex for serializing the process of the SysEx message packets. | |||||
| CVE-2024-56788 | 1 Linux | 1 Linux Kernel | 2026-08-04 | N/A | 7.5 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: net: ethernet: oa_tc6: fix tx skb race condition between reference pointers There are two skb pointers to manage tx skb's enqueued from n/w stack. waiting_tx_skb pointer points to the tx skb which needs to be processed and ongoing_tx_skb pointer points to the tx skb which is being processed. SPI thread prepares the tx data chunks from the tx skb pointed by the ongoing_tx_skb pointer. When the tx skb pointed by the ongoing_tx_skb is processed, the tx skb pointed by the waiting_tx_skb is assigned to ongoing_tx_skb and the waiting_tx_skb pointer is assigned with NULL. Whenever there is a new tx skb from n/w stack, it will be assigned to waiting_tx_skb pointer if it is NULL. Enqueuing and processing of a tx skb handled in two different threads. Consider a scenario where the SPI thread processed an ongoing_tx_skb and it moves next tx skb from waiting_tx_skb pointer to ongoing_tx_skb pointer without doing any NULL check. At this time, if the waiting_tx_skb pointer is NULL then ongoing_tx_skb pointer is also assigned with NULL. After that, if a new tx skb is assigned to waiting_tx_skb pointer by the n/w stack and there is a chance to overwrite the tx skb pointer with NULL in the SPI thread. Finally one of the tx skb will be left as unhandled, resulting packet missing and memory leak. - Consider the below scenario where the TXC reported from the previous transfer is 10 and ongoing_tx_skb holds an tx ethernet frame which can be transported in 20 TXCs and waiting_tx_skb is still NULL. tx_credits = 10; /* 21 are filled in the previous transfer */ ongoing_tx_skb = 20; waiting_tx_skb = NULL; /* Still NULL */ - So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true. - After oa_tc6_prepare_spi_tx_buf_for_tx_skbs() ongoing_tx_skb = 10; waiting_tx_skb = NULL; /* Still NULL */ - Perform SPI transfer. - Process SPI rx buffer to get the TXC from footers. - Now let's assume previously filled 21 TXCs are freed so we are good to transport the next remaining 10 tx chunks from ongoing_tx_skb. tx_credits = 21; ongoing_tx_skb = 10; waiting_tx_skb = NULL; - So, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) becomes true again. - In the oa_tc6_prepare_spi_tx_buf_for_tx_skbs() ongoing_tx_skb = NULL; waiting_tx_skb = NULL; - Now the below bad case might happen, Thread1 (oa_tc6_start_xmit) Thread2 (oa_tc6_spi_thread_handler) --------------------------- ----------------------------------- - if waiting_tx_skb is NULL - if ongoing_tx_skb is NULL - ongoing_tx_skb = waiting_tx_skb - waiting_tx_skb = skb - waiting_tx_skb = NULL ... - ongoing_tx_skb = NULL - if waiting_tx_skb is NULL - waiting_tx_skb = skb To overcome the above issue, protect the moving of tx skb reference from waiting_tx_skb pointer to ongoing_tx_skb pointer and assigning new tx skb to waiting_tx_skb pointer, so that the other thread can't access the waiting_tx_skb pointer until the current thread completes moving the tx skb reference safely. | |||||
| CVE-2024-56706 | 1 Linux | 1 Linux Kernel | 2026-08-04 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: s390/cpum_sf: Fix and protect memory allocation of SDBs with mutex Reservation of the PMU hardware is done at first event creation and is protected by a pair of mutex_lock() and mutex_unlock(). After reservation of the PMU hardware the memory required for the PMUs the event is to be installed on is allocated by allocate_buffers() and alloc_sampling_buffer(). This done outside of the mutex protection. Without mutex protection two or more concurrent invocations of perf_event_init() may run in parallel. This can lead to allocation of Sample Data Blocks (SDBs) multiple times for the same PMU. Prevent this and protect memory allocation of SDBs by mutex. | |||||