Total
1660 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-2608 | 2 Fedoraproject, Google | 3 Fedora, Chrome, Chrome Os | 2024-08-03 | 8.8 High |
| Use after free in Overview Mode in Google Chrome on Chrome OS prior to 104.0.5112.79 allowed a remote attacker who convinced a user to engage in specific user interactions to potentially exploit heap corruption via specific UI interactions. | ||||
| CVE-2022-2617 | 2 Fedoraproject, Google | 2 Fedora, Chrome | 2024-08-03 | 8.8 High |
| Use after free in Extensions API in Google Chrome prior to 104.0.5112.79 allowed an attacker who convinced a user to install a malicious extension to potentially exploit heap corruption via specific UI interactions. | ||||
| CVE-2022-2609 | 2 Fedoraproject, Google | 3 Fedora, Chrome, Chrome Os | 2024-08-03 | 8.8 High |
| Use after free in Nearby Share in Google Chrome on Chrome OS prior to 104.0.5112.79 allowed a remote attacker who convinced a user to engage in specific user interactions to potentially exploit heap corruption via specific UI interactions. | ||||
| CVE-2022-2607 | 2 Fedoraproject, Google | 3 Fedora, Chrome, Chrome Os | 2024-08-03 | 8.8 High |
| Use after free in Tab Strip in Google Chrome on Chrome OS prior to 104.0.5112.79 allowed a remote attacker who convinced a user to engage in specific user interactions to potentially exploit heap corruption via specific UI interactions. | ||||
| CVE-2022-2583 | 1 Gobase Project | 1 Gobase | 2024-08-03 | 3.7 Low |
| A race condition can cause incorrect HTTP request routing. | ||||
| CVE-2022-2590 | 1 Linux | 1 Linux Kernel | 2024-08-03 | 7.0 High |
| A race condition was found in the way the Linux kernel's memory subsystem handled the copy-on-write (COW) breakage of private read-only shared memory mappings. This flaw allows an unprivileged, local user to gain write access to read-only memory mappings, increasing their privileges on the system. | ||||
| CVE-2022-2160 | 3 Fedoraproject, Google, Microsoft | 3 Fedora, Chrome, Windows | 2024-08-03 | 6.5 Medium |
| Insufficient policy enforcement in DevTools in Google Chrome on Windows prior to 103.0.5060.53 allowed an attacker who convinced a user to install a malicious extension to obtain potentially sensitive information from a user's local files via a crafted HTML page. | ||||
| CVE-2022-1729 | 3 Linux, Netapp, Redhat | 9 Linux Kernel, Hci Baseboard Management Controller, Enterprise Linux and 6 more | 2024-08-03 | 7.0 High |
| A race condition was found the Linux kernel in perf_event_open() which can be exploited by an unprivileged user to gain root privileges. The bug allows to build several exploit primitives such as kernel address information leak, arbitrary execution, etc. | ||||
| CVE-2022-1462 | 3 Debian, Linux, Redhat | 5 Debian Linux, Linux Kernel, Enterprise Linux and 2 more | 2024-08-03 | 6.3 Medium |
| An out-of-bounds read flaw was found in the Linux kernel’s TeleTYpe subsystem. The issue occurs in how a user triggers a race condition using ioctls TIOCSPTLCK and TIOCGPTPEER and TIOCSTI and TCXONC with leakage of memory in the flush_to_ldisc function. This flaw allows a local user to crash the system or read unauthorized random data from memory. | ||||
| CVE-2022-1247 | 3 Fedoraproject, Linux, Redhat | 3 Fedora, Linux Kernel, Enterprise Linux | 2024-08-02 | 7.0 High |
| An issue found in linux-kernel that leads to a race condition in rose_connect(). The rose driver uses rose_neigh->use to represent how many objects are using the rose_neigh. When a user wants to delete a rose_route via rose_ioctl(), the rose driver calls rose_del_node() and removes neighbours only if their “count” and “use” are zero. | ||||
| CVE-2022-1195 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2024-08-02 | 5.5 Medium |
| A use-after-free vulnerability was found in the Linux kernel in drivers/net/hamradio. This flaw allows a local attacker with a user privilege to cause a denial of service (DOS) when the mkiss or sixpack device is detached and reclaim resources early. | ||||
| CVE-2022-1048 | 4 Debian, Linux, Netapp and 1 more | 22 Debian Linux, Linux Kernel, H300e and 19 more | 2024-08-02 | 7.0 High |
| A use-after-free flaw was found in the Linux kernel’s sound subsystem in the way a user triggers concurrent calls of PCM hw_params. The hw_free ioctls or similar race condition happens inside ALSA PCM for other ioctls. This flaw allows a local user to crash or potentially escalate their privileges on the system. | ||||
| CVE-2022-0279 | 1 Bologer | 1 Anycomment | 2024-08-02 | 3.1 Low |
| The AnyComment WordPress plugin before 0.2.18 is affected by a race condition when liking/disliking a comment/reply, which could allow any authenticated user to quickly raise their rating or lower the rating of other users | ||||
| CVE-2022-0207 | 2 Ovirt, Redhat | 6 Vdsm, Enterprise Linux, Rhev Hypervisor and 3 more | 2024-08-02 | 4.7 Medium |
| A race condition was found in vdsm. Functionality to obfuscate sensitive values in log files that may lead to values being stored in clear text. | ||||
| CVE-2023-52872 | 2024-08-02 | 4.1 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix race condition in status line change on dead connections gsm_cleanup_mux() cleans up the gsm by closing all DLCIs, stopping all timers, removing the virtual tty devices and clearing the data queues. This procedure, however, may cause subsequent changes of the virtual modem status lines of a DLCI. More data is being added the outgoing data queue and the deleted kick timer is restarted to handle this. At this point many resources have already been removed by the cleanup procedure. Thus, a kernel panic occurs. Fix this by proving in gsm_modem_update() that the cleanup procedure has not been started and the mux is still alive. Note that writing to a virtual tty is already protected by checks against the DLCI specific connection state. | ||||
| CVE-2023-52740 | 2024-08-02 | 4.1 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: powerpc/64s/interrupt: Fix interrupt exit race with security mitigation switch The RFI and STF security mitigation options can flip the interrupt_exit_not_reentrant static branch condition concurrently with the interrupt exit code which tests that branch. Interrupt exit tests this condition to set MSR[EE|RI] for exit, then again in the case a soft-masked interrupt is found pending, to recover the MSR so the interrupt can be replayed before attempting to exit again. If the condition changes between these two tests, the MSR and irq soft-mask state will become corrupted, leading to warnings and possible crashes. For example, if the branch is initially true then false, MSR[EE] will be 0 but PACA_IRQ_HARD_DIS clear and EE may not get enabled, leading to warnings in irq_64.c. | ||||
| CVE-2023-52720 | 2024-08-02 | 4.1 Medium | ||
| Race condition vulnerability in the soundtrigger module Impact: Successful exploitation of this vulnerability will affect availability. | ||||
| CVE-2023-52786 | 2024-08-02 | 4.7 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: ext4: fix racy may inline data check in dio write syzbot reports that the following warning from ext4_iomap_begin() triggers as of the commit referenced below: if (WARN_ON_ONCE(ext4_has_inline_data(inode))) return -ERANGE; This occurs during a dio write, which is never expected to encounter an inode with inline data. To enforce this behavior, ext4_dio_write_iter() checks the current inline state of the inode and clears the MAY_INLINE_DATA state flag to either fall back to buffered writes, or enforce that any other writers in progress on the inode are not allowed to create inline data. The problem is that the check for existing inline data and the state flag can span a lock cycle. For example, if the ilock is originally locked shared and subsequently upgraded to exclusive, another writer may have reacquired the lock and created inline data before the dio write task acquires the lock and proceeds. The commit referenced below loosens the lock requirements to allow some forms of unaligned dio writes to occur under shared lock, but AFAICT the inline data check was technically already racy for any dio write that would have involved a lock cycle. Regardless, lift clearing of the state bit to the same lock critical section that checks for preexisting inline data on the inode to close the race. | ||||
| CVE-2023-52645 | 1 Linux | 1 Linux Kernel | 2024-08-02 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: pmdomain: mediatek: fix race conditions with genpd If the power domains are registered first with genpd and *after that* the driver attempts to power them on in the probe sequence, then it is possible that a race condition occurs if genpd tries to power them on in the same time. The same is valid for powering them off before unregistering them from genpd. Attempt to fix race conditions by first removing the domains from genpd and *after that* powering down domains. Also first power up the domains and *after that* register them to genpd. | ||||
| CVE-2023-52609 | 2024-08-02 | 4.1 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: binder: fix race between mmput() and do_exit() Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A. Task A | Task B ------------------+------------------ mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() | In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead). This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. All the associated death notifications will also be delayed until then. In order to fix this use mmput_async() that will schedule the work in the corresponding mm->async_put_work WQ instead of Task A. | ||||