Concurrent execution using shared resource with improper synchronization ('race condition') in Capability Access Management Service (camsvc) allows an authorized attacker to elevate privileges locally.
Concurrent execution using shared resource with improper synchronization ('race condition') in Capability Access Management Service (camsvc) allows an authorized attacker to elevate privileges locally.
Race condition in LoginUIFramework in Apple Mac OS X 10.7.x before 10.7.4, when the Guest account is enabled, allows physically proximate attackers to login to arbitrary accounts by entering the account name and no password.
Concurrent execution using shared resource with improper synchronization ('race condition') in Graphics Kernel allows an authorized attacker to elevate privileges locally.
Race condition in the initialization routine in blued in Bluetooth in Apple Mac OS X before 10.7.4 allows local users to gain privileges via vectors involving a temporary file.
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Subsystem for Linux allows an authorized attacker to elevate privileges locally.
Race condition in the Passcode Lock feature in Apple iOS before 5.1 allows physically proximate attackers to bypass intended passcode requirements via a slide-to-dial gesture.
Race condition in ASP firmware could allow less privileged x86 code to perform ASP SMM (System Management Mode) operations.
Concurrent execution using shared resource with improper synchronization ('race condition') in Graphics Kernel allows an authorized attacker to elevate privileges locally.
Sophos SafeGuard Enterprise Device Encryption 5.x through 5.50.8.13, Sophos SafeGuard Easy Device Encryption Client 5.50.x, and Sophos Disk Encryption 5.50.x have a delay before removal of (1) out-of-date credentials and (2) invalid credentials, which allows physically proximate attackers to defeat the full-disk encryption feature by leveraging knowledge of these credentials.
SQLiteODBC 0.9996, as packaged for certain Linux distributions as 0.9996-4, has a race condition leading to root privilege escalation because any user can replace a /tmp/sqliteodbc$$ file with new contents that cause loading of an arbitrary library.
An issue was discovered in Xen through 4.9.x allowing x86 PV guest OS users to execute arbitrary code on the host OS because of a race condition that can cause a stale TLB entry.
An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a denial of service or possibly gain privileges because of missing memory barriers in read-write unlock paths. The read-write unlock paths don't contain a memory barrier. On Arm, this means a processor is allowed to re-order the memory access with the preceding ones. In other words, the unlock may be seen by another processor before all the memory accesses within the "critical" section. As a consequence, it may be possible to have a writer executing a critical section at the same time as readers or another writer. In other words, many of the assumptions (e.g., a variable cannot be modified after a check) in the critical sections are not safe anymore. The read-write locks are used in hypercalls (such as grant-table ones), so a malicious guest could exploit the race. For instance, there is a small window where Xen can leak memory if XENMAPSPACE_grant_table is used concurrently. A malicious guest may be able to leak memory, or cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded.
Race condition occurs while calling user space ioctl from two different threads can results to use after free issue in video in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables
A race between command submission and destroying the context can cause an invalid context being added to the list leads to use after free issue. in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables
An issue was discovered on Samsung mobile devices with O(8.x), P(9.0), and Q(10.0) (S.LSI chipsets) software. There are race conditions in the hdcp2 driver. The Samsung ID is SVE-2019-16296 (February 2020).
The session index variable in PCM host voice audio driver initialized before PCM open, accessed during event callback from ADSP and reset during PCM close may lead to race condition between event callback - PCM close and reset session index causing memory corruption.
u'Two threads running simultaneously from user space can lead to race condition in fastRPC driver' in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking in Agatti, APQ8053, Bitra, IPQ4019, IPQ5018, IPQ6018, IPQ8064, IPQ8074, Kamorta, MDM9607, MSM8953, Nicobar, QCA6390, QCS404, QCS405, QCS610, Rennell, SA515M, SA6155P, SA8155P, Saipan, SC8180X, SDA845, SDM429, SDM429W, SDM632, SDM660, SDX55, SM6150, SM7150, SM8150, SM8250, SXR2130
Race condition in HAL layer while processing callback objects received from HIDL due to lack of synchronization between accessing objects in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables
Possible race condition during async fastrpc session after sending RPC message due to the fastrpc ctx gets free during async session in Snapdragon Compute, Snapdragon Industrial IOT, Snapdragon Mobile
Use after free due to race condition when reopening the device driver repeatedly in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking
In HalCamera::requestNewFrame of HalCamera.cpp, there is a possible use-after-free 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.Product: AndroidVersions: Android-11Android ID: A-169282240
In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.
Windows PrintWorkflowUserSvc Elevation of Privilege Vulnerability
Insecure creation of temporary directories in tmate-ssh-server 2.3.0 allows a local attacker to compromise the integrity of session handling.
Microsoft Office Elevation of Privilege Vulnerability
Windows PrintWorkflowUserSvc Elevation of Privilege Vulnerability
Windows Kernel Elevation of Privilege Vulnerability
A race condition existed in the snapd 2.54.2 snap-confine binary when preparing a private mount namespace for a snap. This could allow a local attacker to gain root privileges by bind-mounting their own contents inside the snap's private mount namespace and causing snap-confine to execute arbitrary code and hence gain privilege escalation. Fixed in snapd versions 2.54.3+18.04, 2.54.3+20.04 and 2.54.3+21.10.1
Race condition in the tee (sys_tee) system call in the Linux kernel 2.6.17 through 2.6.17.6 might allow local users to cause a denial of service (system crash), obtain sensitive information (kernel memory contents), or gain privileges via unspecified vectors related to a potentially dropped ipipe lock during a race between two pipe readers.
In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.
In the Linux kernel 4.19 through 5.6.7 on the s390 platform, code execution may occur because of a race condition, as demonstrated by code in enable_sacf_uaccess in arch/s390/lib/uaccess.c that fails to protect against a concurrent page table upgrade, aka CID-3f777e19d171. A crash could also occur.
In loadSoundModel and related functions of SoundTriggerHwService.cpp, there is 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.Product: AndroidVersions: Android-10Android ID: A-136005905
In the Android kernel in the video driver there is a use after free 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.
In binder_thread_release of binder.c, there is a possible use after free 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.Product: AndroidVersions: Android kernelAndroid ID: A-145286050References: Upstream kernel
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.
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.
A validation issue existed in the handling of symlinks. This issue was addressed with improved validation of symlinks. This issue is fixed in macOS Mojave 10.14.5. A local user may be able to load unsigned kernel extensions.
In the netlink driver, 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.Product: AndroidVersions: Android kernelAndroid ID: A-65025077
Race condition in the pkexec utility and polkitd daemon in PolicyKit (aka polkit) 0.96 allows local users to gain privileges by executing a setuid program from pkexec, related to the use of the effective user ID instead of the real user ID.
In the Linux kernel before 5.17.3, fs/io_uring.c has a use-after-free due to a race condition in io_uring timeouts. This can be triggered by a local user who has no access to any user namespace; however, the race condition perhaps can only be exploited infrequently.
Race condition in mount.vmhgfs in the VMware Host Guest File System (HGFS) in VMware Workstation 7.1.x before 7.1.4, VMware Player 3.1.x before 3.1.4, VMware Fusion 3.1.x before 3.1.3, VMware ESXi 3.5 through 4.1, and VMware ESX 3.0.3 through 4.1 allows guest OS users to gain privileges on the guest OS by mounting a filesystem on top of an arbitrary directory.
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Fix race between namespace cleanup and gc in the list:set type Lion Ackermann reported that there is a race condition between namespace cleanup in ipset and the garbage collection of the list:set type. The namespace cleanup can destroy the list:set type of sets while the gc of the set type is waiting to run in rcu cleanup. The latter uses data from the destroyed set which thus leads use after free. The patch contains the following parts: - When destroying all sets, first remove the garbage collectors, then wait if needed and then destroy the sets. - Fix the badly ordered "wait then remove gc" for the destroy a single set case. - Fix the missing rcu locking in the list:set type in the userspace test case. - Use proper RCU list handlings in the list:set type. The patch depends on c1193d9bbbd3 (netfilter: ipset: Add list flush to cancel_gc).
A race condition in chown_one() of systemd allows an attacker to cause systemd to set arbitrary permissions on arbitrary files. Affected releases are systemd versions up to and including 239.
Local privilege escalation due to race condition on application startup. The following products are affected: Acronis Cyber Protect Home Office (macOS) before build 39605, Acronis True Image 2021 (macOS) before build 39287
Windows Resource Manager PSM Service Extension Elevation of Privilege Vulnerability
Windows Resource Manager PSM Service Extension Elevation of Privilege Vulnerability
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Fix use after free in lineinfo_changed_notify The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines. Here is the typical stack when issue happened: [free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule() [use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway. To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain.
Possible use-after-free issue due to a race condition while calling camera ioctl concurrently in Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables in MSM8909W, QCS405, QCS605, Qualcomm 215, SD 425, SD 439 / SD 429, SD 450, SD 625, SD 632, SD 665, SD 675, SD 712 / SD 710 / SD 670, SD 730, SD 845 / SD 850, SD 855, SDM439, SDX24
In the Easel driver, there is possible memory corruption due to race conditions. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-112312381