| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Time-of-check time-of-use (toctou) race condition in Windows Virtualization-Based Security (VBS) Enclave allows an authorized attacker to bypass a security feature locally. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Serialize PCM mmap with buffer reallocation to fix page UAF
snd_pcm_hw_params() and snd_pcm_hw_free() guard buffer reallocation
with an mmap_count check performed under the PCM stream lock, but the
lock is released long before the buffer is actually freed:
snd_pcm_sync_stop(), constraint refinement and do_free_pages() all
happen in between. snd_pcm_mmap_data(), on the other hand, takes no
lock at all: it validates against the old buffer's state and
dma_bytes, remaps its pages into the VMA, and only then increments
mmap_count.
A concurrent mmap() can therefore slip in between the check and the
free. remap_pfn_range() installs writable PTEs for the old buffer's
pages without taking page references, and the subsequent
do_free_pages() returns those pages to the page allocator while the
VMA still maps them. This leaves a stale, writable mapping of freed
pages: a page-level use-after-free that can be leveraged for local
privilege escalation.
Make snd_pcm_mmap_data() participate in the buffer-access scheme
introduced for hw_params/hw_free: acquire runtime->buffer_accessing
before validating and remapping, and release it afterwards. Buffer
reallocation already fails with -EBUSY while accessors are active,
and the mmap side now fails with -EBUSY while a reallocation is in
progress, so the validate/remap sequence and the check/free sequence
can no longer interleave.
A reproducer that turns this race into a stale writable mapping of
the freed DMA buffer pages is available on request. |
| In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix readahead synchronisation issues by loading all folios upfront
There are some synchronisation issues that derive from the app thread
adding more folios to the rolling buffer whilst the collector thread is
looking at them or trying to clear them, such as determining the setting of
front_folio_order when the next folio hasn't been added yet,
The reason for the rolling buffer approach is that loading the buffer
upfront and then dropping all the refs just acquired is quite a slow
operation, and loading progressively allows some of the cost to be deferred
until after at least some of the I/O is started.
Instead, a better way is to load all the folios into the rolling buffer
upfront - and then drop the refs later, once the I/O is in progress. (Even
better would be for the refs not to be there at all.)
Fix this by changing the rolling buffer loader to load all the folios
selected by the VM for readahead upfront into the folio queue. The folio
queue is allocated a batch worth at a time as we don't know how many folios
are involved (the readahead_control struct, alas, has a page count, not a
folio count).
The folio refs acquired from readahead are then dropped in bulk once the
first subrequest is dispatched as it's quite a slow operation. The
collector waits for NETFS_RREQ_NEED_PUT_RA_REFS to be cleared so that it
doesn't unlock folios before the xarray has been scanned for them.
This simplifies the buffer handling later and isn't noticeably slower as
the xarray doesn't need to be modified and the folios are all already
pre-locked. |
| A security flaw has been discovered in a2aproject a2a-rs up to 0.4.4. The affected element is the function InMemoryTaskStore::update of the file a2a-server/src/task_store/inmemory.rs. The manipulation results in race condition. The attack may be performed from remote. The patch is identified as 7050c7d329238539424ee46440e23b91c4825bee. It is advisable to implement a patch to correct this issue. |
| filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the <path>.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue is fixed in version 4.2.1. |
| filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can break a stale marker after an attacker frees its own marker following the stale read, an honest contender creates a live successor on the reused inode, and the successor's modification time is not newer than the saved observation, causing the live marker to be removed and two holders to be admitted. This issue is fixed in version 4.2.1. |
| Use after free in Windows Storage allows an authorized attacker to elevate privileges locally. |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Connected Devices Platform Service allows an authorized attacker to elevate privileges locally. |
| In the Linux kernel, the following vulnerability has been resolved:
ntfs: take invalidate_lock in ntfs_setattr_size()
ntfs_setattr_size() updates i_size and resizes the on-disk attribute
without holding mapping->invalidate_lock. Page faults take the lock
shared, so a fault racing the resize can resolve a VCN against the
transient runlist state of ntfs_non_resident_attr_expand() and fail
with a spurious SIGBUS, and can interleave with the size-change
epilogue (truncate_pagecache(), i_size_write(),
pagecache_isize_extended()).
Take invalidate_lock exclusively around the whole resize after
inode_dio_wait(), matching the fallocate path and other filesystems
such as xfs, which wraps truncate in its mmaplock (= invalidate_lock). |
| Use after free in Windows Ancillary Function Driver for WinSock allows an authorized attacker to disclose information locally. |
| Race condition in the IPC component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. |
| filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock versions from 4.1.0 can reuse a stale observation when an attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, coarse or matching modification times preserve the observation, and an honest contender creates a fresh marker on the reused inode, causing that live marker to be removed as stale. This issue is fixed in version 4.2.1. |
| filelock is a platform-independent file lock for Python. Prior to 4.2.1, UnixFileLock can truncate a regular file renamed onto the lock path when another local user has actual rename permission, or hard-linked there under a permissive hard-link policy; when an explicit mode is requested, affected versions from 3.10.2 can also change that file's mode. This issue is fixed in version 4.2.1. |
| Use after free in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally. |
| Time-of-check time-of-use (toctou) race condition in Windows Hyper-V allows an authorized attacker to elevate privileges locally. |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Win32K allows an authorized attacker to elevate privileges locally. |
| A time-of-check time-of-use (TOCTOU) race condition combined with improper symbolic link handling in the privileged helper of TeamViewer Full Client and Host prior to version 15.83 for macOS allows a local attacker with low privileges to bypass installer package verification and install a malicious package. Successful exploitation can lead to local privilege escalation to root. |
| A security vulnerability has been detected in a2aproject a2a-java up to 1.2.0.Final. This impacts the function TaskManager.saveTaskEvent. The manipulation leads to race condition. The attack may be initiated remotely. Upgrading to version 1.3.0.Final will fix this issue. The identifier of the patch is 6b8e1e085c35e970ef0048901cd25850e4791ec2. The affected component should be upgraded. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: serialize vblank counter reads against GPU reset
The vblank counter callback reads display registers and scanout
position without holding reset_domain->sem. During GPU recovery,
display commit work can call the callback while reset owns the
semaphore for writing. The hardware access then triggers the
lockdep_assert_held() in amdgpu_device_skip_hw_access() and sets
TAINT_WARN when lockdep is enabled.
Try to acquire the reset semaphore for reading before accessing the
hardware, and hold it across the counter and scanout-position reads.
If reset is already in progress, return DRM's cached software vblank
count instead. This avoids blocking behind reset and avoids accessing
display hardware while it is being reset.
The cached count is less accurate than the hardware count, but is
used only when reset prevents a safe hardware read. This addresses
the reset-time warning from this vblank path; it does not suppress or
fix unrelated lockdep warnings.
(cherry picked from commit 51a4359f7431a4be5e42803c8bdaf7e0e5be2934) |
| Electrum before 4.7.2 contains a spending limit bypass vulnerability in the Nostr Wallet Connect plugin that allows malicious NWC clients to exceed daily_limit_sat by exploiting non-atomic budget checks and millisatoshi truncation. Attackers can send concurrent pay_invoice requests that pass budget_allows_spend() before add_to_budget() runs, or repeatedly pay msat amounts that are floored to whole satoshis, to drain funds beyond the limit. |
