| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| csync2 uses insecure temporary directories when compiled with C99 or later, allowing for TOCTOU style attacks on the temporary directories. |
| A race condition vulnerability in Palo Alto Networks Prisma® Browser enables a locally authenticated non-admin user to bypass certain access and data control policies. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: core: Avoid bitfield RMW for claim/retune flags
Move claimed and retune control flags out of the bitfield word to
avoid unrelated RMW side effects in asynchronous contexts.
The host->claimed bit shared a word with retune flags. Writes to claimed
in __mmc_claim_host() or retune_now in mmc_mq_queue_rq() can overwrite
other bits when concurrent updates happen in other contexts, triggering
spurious WARN_ON(!host->claimed). Convert claimed, can_retune,
retune_now and retune_paused to bool to remove shared-word coupling. |
| OpenClaw before 2026.4.22 contains a time-of-check/time-of-use race condition in OpenShell sandbox filesystem writes that allows attackers to redirect writes outside the intended mount root. Attackers can exploit symlink swaps during filesystem operations to bypass sandbox restrictions and write files outside the local mount root. |
| OpenClaw before 2026.4.22 contains a time-of-check/time-of-use race condition in the OpenShell filesystem bridge that allows attackers to read files outside the intended mount root. Attackers can exploit symlink swaps during filesystem operations to bypass sandbox restrictions and access unauthorized file contents. |
| A memory corruption vulnerability was addressed with improved locking. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.5 and iPadOS 26.5, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5, tvOS 26.5, visionOS 26.5, watchOS 26.5. An attacker may be able to cause unexpected app termination. |
| When sed is invoked with both -i (in-place edit) and --follow-symlinks, the function open_next_file() performs two separate, non-atomic filesystem operations on the same path:
1. resolves symlink to its target and stores the resolved path for determining when output is written,
2. opens the original symlink path (not the resolved one) to read the file.
Between these two calls there is a race window. If an attacker atomically replaces the symlink with a different target during that window, sed will: read content from the new (attacker-chosen) symlink target and write the processed result to the path recorded in step 1. This can lead to arbitrary file overwrite with attacker-controlled content in the context of the sed process.
This issue was fixed in version 4.10. |
| A race condition was addressed with additional validation. This issue is fixed in macOS Tahoe 26.4. An app may be able to access sensitive user data. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring/zcrx: fix user_ref race between scrub and refill paths
The io_zcrx_put_niov_uref() function uses a non-atomic
check-then-decrement pattern (atomic_read followed by separate
atomic_dec) to manipulate user_refs. This is serialized against other
callers by rq_lock, but io_zcrx_scrub() modifies the same counter with
atomic_xchg() WITHOUT holding rq_lock.
On SMP systems, the following race exists:
CPU0 (refill, holds rq_lock) CPU1 (scrub, no rq_lock)
put_niov_uref:
atomic_read(uref) - 1
// window opens
atomic_xchg(uref, 0) - 1
return_niov_freelist(niov) [PUSH #1]
// window closes
atomic_dec(uref) - wraps to -1
returns true
return_niov(niov)
return_niov_freelist(niov) [PUSH #2: DOUBLE-FREE]
The same niov is pushed to the freelist twice, causing free_count to
exceed nr_iovs. Subsequent freelist pushes then perform an out-of-bounds
write (a u32 value) past the kvmalloc'd freelist array into the adjacent
slab object.
Fix this by replacing the non-atomic read-then-dec in
io_zcrx_put_niov_uref() with an atomic_try_cmpxchg loop that atomically
tests and decrements user_refs. This makes the operation safe against
concurrent atomic_xchg from scrub without requiring scrub to acquire
rq_lock.
[pavel: removed a warning and a comment] |
| A race condition in Ivanti Secure Access Client before 22.8R6 allows a locally authenticated user to escalate privileges to SYSTEM |
| A race condition was addressed with additional validation. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.5 and iPadOS 26.5, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5, tvOS 26.5, watchOS 26.5. An app may be able to cause unexpected system termination. |
| In the Linux kernel, the following vulnerability has been resolved:
net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets
When the FarSync T-series card is being detached, the fst_card_info is
deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task
may still be running or pending, leading to use-after-free bugs when the
already freed fst_card_info is accessed in fst_process_tx_work_q() or
fst_process_int_work_q().
A typical race condition is depicted below:
CPU 0 (cleanup) | CPU 1 (tasklet)
| fst_start_xmit()
fst_remove_one() | tasklet_schedule()
unregister_hdlc_device()|
| fst_process_tx_work_q() //handler
kfree(card) //free | do_bottom_half_tx()
| card-> //use
The following KASAN trace was captured:
==================================================================
BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00
Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32
...
Call Trace:
<IRQ>
dump_stack_lvl+0x55/0x70
print_report+0xcb/0x5d0
? do_bottom_half_tx+0xb88/0xd00
kasan_report+0xb8/0xf0
? do_bottom_half_tx+0xb88/0xd00
do_bottom_half_tx+0xb88/0xd00
? _raw_spin_lock_irqsave+0x85/0xe0
? __pfx__raw_spin_lock_irqsave+0x10/0x10
? __pfx___hrtimer_run_queues+0x10/0x10
fst_process_tx_work_q+0x67/0x90
tasklet_action_common+0x1fa/0x720
? hrtimer_interrupt+0x31f/0x780
handle_softirqs+0x176/0x530
__irq_exit_rcu+0xab/0xe0
sysvec_apic_timer_interrupt+0x70/0x80
...
Allocated by task 41 on cpu 3 at 72.330843s:
kasan_save_stack+0x24/0x50
kasan_save_track+0x17/0x60
__kasan_kmalloc+0x7f/0x90
fst_add_one+0x1a5/0x1cd0
local_pci_probe+0xdd/0x190
pci_device_probe+0x341/0x480
really_probe+0x1c6/0x6a0
__driver_probe_device+0x248/0x310
driver_probe_device+0x48/0x210
__device_attach_driver+0x160/0x320
bus_for_each_drv+0x101/0x190
__device_attach+0x198/0x3a0
device_initial_probe+0x78/0xa0
pci_bus_add_device+0x81/0xc0
pci_bus_add_devices+0x7e/0x190
enable_slot+0x9b9/0x1130
acpiphp_check_bridge.part.0+0x2e1/0x460
acpiphp_hotplug_notify+0x36c/0x3c0
acpi_device_hotplug+0x203/0xb10
acpi_hotplug_work_fn+0x59/0x80
...
Freed by task 41 on cpu 1 at 75.138639s:
kasan_save_stack+0x24/0x50
kasan_save_track+0x17/0x60
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x43/0x70
kfree+0x135/0x410
fst_remove_one+0x2ca/0x540
pci_device_remove+0xa6/0x1d0
device_release_driver_internal+0x364/0x530
pci_stop_bus_device+0x105/0x150
pci_stop_and_remove_bus_device+0xd/0x20
disable_slot+0x116/0x260
acpiphp_disable_and_eject_slot+0x4b/0x190
acpiphp_hotplug_notify+0x230/0x3c0
acpi_device_hotplug+0x203/0xb10
acpi_hotplug_work_fn+0x59/0x80
...
The buggy address belongs to the object at ffff88800aad1000
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 28 bytes inside of
freed 1024-byte region
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x100000000000040(head|node=0|zone=1)
page_type: f5(slab)
raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000
head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff
head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88800aad1000: fa fb
---truncated--- |
| A race condition exists in PaperCut MF when processing badge-swipe data from certain HP multifunction devices. Under specific network conditions involving dropped packets and out-of-order sequence counters, the server may incorrectly process fragmented data chunks. If a sequence reset notification fails to reach the server, the server may reject the initial data chunk while erroneously accepting subsequent chunks before a connection reset completes.
This leads to the registration of a truncated badge ID string. While this typically results in an authentication failure, the vulnerability is compounded in environments utilizing custom badge-ID post-processing scripts. In such configurations, the truncated string may be transformed into a valid ID belonging to a different user, leading to unauthorized session establishment (Incorrect User Login) on the device. |
| In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_skbedit: fix divide-by-zero in tcf_skbedit_hash()
Commit 38a6f0865796 ("net: sched: support hash selecting tx queue")
added SKBEDIT_F_TXQ_SKBHASH support. The inclusive range size is
computed as:
mapping_mod = queue_mapping_max - queue_mapping + 1;
The range size can be 65536 when the requested range covers all possible
u16 queue IDs (e.g. queue_mapping=0 and queue_mapping_max=U16_MAX).
That value cannot be represented in a u16 and previously wrapped to 0,
so tcf_skbedit_hash() could trigger a divide-by-zero:
queue_mapping += skb_get_hash(skb) % params->mapping_mod;
Compute mapping_mod in a wider type and reject ranges larger than U16_MAX
to prevent params->mapping_mod from becoming 0 and avoid the crash. |
| A race condition was addressed with additional validation. This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, iOS 26.5 and iPadOS 26.5, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5, visionOS 26.5. An app may be able to access sensitive user data. |
| The base directory (`spring.cloud.config.server.git.basedir`) used by the Spring Cloud Config Server to clone Git repositories to is susceptible to time-of-check-time-of-use (TOCTOU) attacks.
Spring Cloud Config 3.1.x: affected from 3.1.0 through 3.1.13 (inclusive); upgrade to 3.1.14 or greater (Enterprise Support Only). Spring Cloud Config 4.1.x: affected from 4.1.0 through 4.1.9 (inclusive); upgrade to 4.1.10 or greater (Enterprise Support Only). Spring Cloud Config 4.2.x: affected from 4.2.0 through 4.2.6 (inclusive); upgrade to 4.2.7 or greater (Enterprise Support Only). Spring Cloud Config 4.3.x: affected from 4.3.0 through 4.3.2 (inclusive); upgrade to 4.3.3 or greater. Spring Cloud Config 5.0.x: affected from 5.0.0 through 5.0.2 (inclusive); upgrade to 5.0.3 or greater. |
| A race condition was addressed with improved handling of symbolic links. This issue is fixed in macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5. An app may be able to access Contacts without user consent. |
| An issue was discovered in the Shared Account Synchronization component of PaperCut MF (version 25.0.4). The application allows administrative users to configure a source path for account data synchronization.
Due to a lack of proper path validation and sanitization, an authenticated user with administrative privileges can specify arbitrary file paths on the local file system. This allows for the enumeration of directory structures and the unauthorized reading of sensitive text-based configuration or system files.
When the synchronization process is triggered, the application attempts to parse the contents of the specified file, subsequently exposing the data within the application's account management interface. This vulnerability could lead to the disclosure of sensitive system information or configuration details, depending on the permissions of the service account under which the application is running. |
| In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix potential warning in trace_printk_seq during ftrace_dump
When calling ftrace_dump_one() concurrently with reading trace_pipe,
a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a race
condition.
The issue occurs because:
CPU0 (ftrace_dump) CPU1 (reader)
echo z > /proc/sysrq-trigger
!trace_empty(&iter)
trace_iterator_reset(&iter) <- len = size = 0
cat /sys/kernel/tracing/trace_pipe
trace_find_next_entry_inc(&iter)
__find_next_entry
ring_buffer_empty_cpu <- all empty
return NULL
trace_printk_seq(&iter.seq)
WARN_ON_ONCE(s->seq.len >= s->seq.size)
In the context between trace_empty() and trace_find_next_entry_inc()
during ftrace_dump, the ring buffer data was consumed by other readers.
This caused trace_find_next_entry_inc to return NULL, failing to populate
`iter.seq`. At this point, due to the prior trace_iterator_reset, both
`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,
the WARN_ON_ONCE condition is triggered.
Move the trace_printk_seq() into the if block that checks to make sure the
return value of trace_find_next_entry_inc() is non-NULL in
ftrace_dump_one(), ensuring the 'iter.seq' is properly populated before
subsequent operations. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix race between quota disable and quota rescan ioctl
There's a race between a task disabling quotas and another running the
rescan ioctl that can result in a use-after-free of qgroup records from
the fs_info->qgroup_tree rbtree.
This happens as follows:
1) Task A enters btrfs_ioctl_quota_rescan() -> btrfs_qgroup_rescan();
2) Task B enters btrfs_quota_disable() and calls
btrfs_qgroup_wait_for_completion(), which does nothing because at that
point fs_info->qgroup_rescan_running is false (it wasn't set yet by
task A);
3) Task B calls btrfs_free_qgroup_config() which starts freeing qgroups
from fs_info->qgroup_tree without taking the lock fs_info->qgroup_lock;
4) Task A enters qgroup_rescan_zero_tracking() which starts iterating
the fs_info->qgroup_tree tree while holding fs_info->qgroup_lock,
but task B is freeing qgroup records from that tree without holding
the lock, resulting in a use-after-free.
Fix this by taking fs_info->qgroup_lock at btrfs_free_qgroup_config().
Also at btrfs_qgroup_rescan() don't start the rescan worker if quotas
were already disabled. |
