| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent concurrent access to IPSec ASO context
The query or updating IPSec offload object is through Access ASO WQE.
The driver uses a single mlx5e_ipsec_aso struct for each PF, which
contains a shared DMA-mapped context for all ASO operations.
A race condition exists because the ASO spinlock is released before
the hardware has finished processing WQE. If a second operation is
initiated immediately after, it overwrites the shared context in the
DMA area.
When the first operation's completion is processed later, it reads
this corrupted context, leading to unexpected behavior and incorrect
results.
This commit fixes the race by introducing a private context within
each IPSec offload object. The shared ASO context is now copied to
this private context while the ASO spinlock is held. Subsequent
processing uses this saved, per-object context, ensuring its integrity
is maintained. |
| Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Stylemix MasterStudy LMS masterstudy-lms-learning-management-system allows Leveraging Race Conditions.This issue affects MasterStudy LMS: from n/a through <= 3.6.20. |
| In the Linux kernel, the following vulnerability has been resolved:
gpiolib: fix race condition for gdev->srcu
If two drivers were calling gpiochip_add_data_with_key(), one may be
traversing the srcu-protected list in gpio_name_to_desc(), meanwhile
other has just added its gdev in gpiodev_add_to_list_unlocked().
This creates a non-mutexed and non-protected timeframe, when one
instance is dereferencing and using &gdev->srcu, before the other
has initialized it, resulting in crash:
[ 4.935481] Unable to handle kernel paging request at virtual address ffff800272bcc000
[ 4.943396] Mem abort info:
[ 4.943400] ESR = 0x0000000096000005
[ 4.943403] EC = 0x25: DABT (current EL), IL = 32 bits
[ 4.943407] SET = 0, FnV = 0
[ 4.943410] EA = 0, S1PTW = 0
[ 4.943413] FSC = 0x05: level 1 translation fault
[ 4.943416] Data abort info:
[ 4.943418] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 4.946220] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 4.955261] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 4.955268] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000038e6c000
[ 4.961449] [ffff800272bcc000] pgd=0000000000000000
[ 4.969203] , p4d=1000000039739003
[ 4.979730] , pud=0000000000000000
[ 4.980210] phandle (CPU): 0x0000005e, phandle (BE): 0x5e000000 for node "reset"
[ 4.991736] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
...
[ 5.121359] pc : __srcu_read_lock+0x44/0x98
[ 5.131091] lr : gpio_name_to_desc+0x60/0x1a0
[ 5.153671] sp : ffff8000833bb430
[ 5.298440]
[ 5.298443] Call trace:
[ 5.298445] __srcu_read_lock+0x44/0x98
[ 5.309484] gpio_name_to_desc+0x60/0x1a0
[ 5.320692] gpiochip_add_data_with_key+0x488/0xf00
5.946419] ---[ end trace 0000000000000000 ]---
Move initialization code for gdev fields before it is added to
gpio_devices, with adjacent initialization code.
Adjust goto statements to reflect modified order of operations
[Bartosz: fixed a build issue, removed stray newline] |
| OpenClaw before 2026.3.31 contains a time-of-check-time-of-use race condition in the remote filesystem bridge readFile function that allows sandbox escape. Attackers can exploit the separate path validation and file read operations to bypass sandbox restrictions and read arbitrary files. |
| Perl threads have a working directory race condition where file operations may target unintended paths.
If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running.
This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit.
The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6 |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: remove refcounting in expectation dumpers
Same pattern as previous patch: do not keep the expectation object
alive via refcount, only store a cookie value and then use that
as the skip hint for dump resumption.
AFAICS this has the same issue as the one resolved in the conntrack
dumper, when we do
if (!refcount_inc_not_zero(&exp->use))
to increment the refcount, there is a chance that exp == last, which
causes a double-increment of the refcount and subsequent memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
timekeeping: Adjust the leap state for the correct auxiliary timekeeper
When __do_ajdtimex() was introduced to handle adjtimex for any
timekeeper, this reference to tk_core was not updated. When called on an
auxiliary timekeeper, the core timekeeper would be updated incorrectly.
This gets caught by the lock debugging diagnostics because the
timekeepers sequence lock gets written to without holding its
associated spinlock:
WARNING: include/linux/seqlock.h:226 at __do_adjtimex+0x394/0x3b0, CPU#2: test/125
aux_clock_adj (kernel/time/timekeeping.c:2979)
__do_sys_clock_adjtime (kernel/time/posix-timers.c:1161 kernel/time/posix-timers.c:1173)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)
Update the correct auxiliary timekeeper. |
| In the Linux kernel, the following vulnerability has been resolved:
net/ena: fix missing lock when update devlink params
Fix assert lock warning while calling devl_param_driverinit_value_set()
in ena.
WARNING: net/devlink/core.c:261 at devl_assert_locked+0x62/0x90, CPU#0: kworker/0:0/9
CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.19.0-rc2+ #1 PREEMPT(lazy)
Hardware name: Amazon EC2 m8i-flex.4xlarge/, BIOS 1.0 10/16/2017
Workqueue: events work_for_cpu_fn
RIP: 0010:devl_assert_locked+0x62/0x90
Call Trace:
<TASK>
devl_param_driverinit_value_set+0x15/0x1c0
ena_devlink_alloc+0x18c/0x220 [ena]
? __pfx_ena_devlink_alloc+0x10/0x10 [ena]
? trace_hardirqs_on+0x18/0x140
? lockdep_hardirqs_on+0x8c/0x130
? __raw_spin_unlock_irqrestore+0x5d/0x80
? __raw_spin_unlock_irqrestore+0x46/0x80
? devm_ioremap_wc+0x9a/0xd0
ena_probe+0x4d2/0x1b20 [ena]
? __lock_acquire+0x56a/0xbd0
? __pfx_ena_probe+0x10/0x10 [ena]
? local_clock+0x15/0x30
? __lock_release.isra.0+0x1c9/0x340
? mark_held_locks+0x40/0x70
? lockdep_hardirqs_on_prepare.part.0+0x92/0x170
? trace_hardirqs_on+0x18/0x140
? lockdep_hardirqs_on+0x8c/0x130
? __raw_spin_unlock_irqrestore+0x5d/0x80
? __raw_spin_unlock_irqrestore+0x46/0x80
? __pfx_ena_probe+0x10/0x10 [ena]
......
</TASK> |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Printer Association Object allows an authorized attacker to elevate privileges locally. |
| node-tar,a Tar for Node.js, has a race condition vulnerability in versions up to and including 7.5.3. This is due to an incomplete handling of Unicode path collisions in the `path-reservations` system. On case-insensitive or normalization-insensitive filesystems (such as macOS APFS, In which it has been tested), the library fails to lock colliding paths (e.g., `ß` and `ss`), allowing them to be processed in parallel. This bypasses the library's internal concurrency safeguards and permits Symlink Poisoning attacks via race conditions. The library uses a `PathReservations` system to ensure that metadata checks and file operations for the same path are serialized. This prevents race conditions where one entry might clobber another concurrently. This is a Race Condition which enables Arbitrary File Overwrite. This vulnerability affects users and systems using node-tar on macOS (APFS/HFS+). Because of using `NFD` Unicode normalization (in which `ß` and `ss` are different), conflicting paths do not have their order properly preserved under filesystems that ignore Unicode normalization (e.g., APFS (in which `ß` causes an inode collision with `ss`)). This enables an attacker to circumvent internal parallelization locks (`PathReservations`) using conflicting filenames within a malicious tar archive. The patch in version 7.5.4 updates `path-reservations.js` to use a normalization form that matches the target filesystem's behavior (e.g., `NFKD`), followed by first `toLocaleLowerCase('en')` and then `toLocaleUpperCase('en')`. As a workaround, users who cannot upgrade promptly, and who are programmatically using `node-tar` to extract arbitrary tarball data should filter out all `SymbolicLink` entries (as npm does) to defend against arbitrary file writes via this file system entry name collision issue. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/shmem, swap: fix race of truncate and swap entry split
The helper for shmem swap freeing is not handling the order of swap
entries correctly. It uses xa_cmpxchg_irq to erase the swap entry, but it
gets the entry order before that using xa_get_order without lock
protection, and it may get an outdated order value if the entry is split
or changed in other ways after the xa_get_order and before the
xa_cmpxchg_irq.
And besides, the order could grow and be larger than expected, and cause
truncation to erase data beyond the end border. For example, if the
target entry and following entries are swapped in or freed, then a large
folio was added in place and swapped out, using the same entry, the
xa_cmpxchg_irq will still succeed, it's very unlikely to happen though.
To fix that, open code the Xarray cmpxchg and put the order retrieval and
value checking in the same critical section. Also, ensure the order won't
exceed the end border, skip it if the entry goes across the border.
Skipping large swap entries crosses the end border is safe here. Shmem
truncate iterates the range twice, in the first iteration,
find_lock_entries already filtered such entries, and shmem will swapin the
entries that cross the end border and partially truncate the folio (split
the folio or at least zero part of it). So in the second loop here, if we
see a swap entry that crosses the end order, it must at least have its
content erased already.
I observed random swapoff hangs and kernel panics when stress testing
ZSWAP with shmem. After applying this patch, all problems are gone. |
| Dell PowerScale OneFS, versions 9.5.0.0 through 9.5.1.5, versions 9.6.0.0 through 9.7.1.10, versions 9.8.0.0 through 9.10.1.3, versions starting from 9.11.0.0 and prior to 9.13.0.0, contains a Time-of-check Time-of-use (TOCTOU) race condition vulnerability. A low privileged attacker with adjacent network access could potentially exploit this vulnerability, leading to denial of service. |
| Time-of-check time-of-use (toctou) race condition in Windows Kernel Memory allows an authorized attacker to elevate privileges locally. |
| MeetingHub developed by HAMASTAR Technology has an Arbitrary File Read vulnerability, allowing unauthenticated remote attackers to exploit Absolute Path Traversal to download arbitrary system files. |
| Rufus is a utility that helps format and create bootable USB flash drives. Versions 4.11 and below contain a race condition (TOCTOU) in src/net.c during the creation, validation, and execution of the Fido PowerShell script. Since Rufus runs with elevated privileges (Administrator) but writes the script to the %TEMP% directory (writeable by standard users) without locking the file, a local attacker can replace the legitimate script with a malicious one between the file write operation and the execution step. This allows arbitrary code execution with Administrator privileges. This issue has been fixed in version 4.12_BETA. |
| In the Linux kernel, the following vulnerability has been resolved:
serial: Fix not set tty->port race condition
Revert commit bfc467db60b7 ("serial: remove redundant
tty_port_link_device()") because the tty_port_link_device() is not
redundant: the tty->port has to be confured before we call
uart_configure_port(), otherwise user-space can open console without TTY
linked to the driver.
This tty_port_link_device() was added explicitly to avoid this exact
issue in commit fb2b90014d78 ("tty: link tty and port before configuring
it as console"), so offending commit basically reverted the fix saying
it is redundant without addressing the actual race condition presented
there.
Reproducible always as tty->port warning on Qualcomm SoC with most of
devices disabled, so with very fast boot, and one serial device being
the console:
printk: legacy console [ttyMSM0] enabled
printk: legacy console [ttyMSM0] enabled
printk: legacy bootconsole [qcom_geni0] disabled
printk: legacy bootconsole [qcom_geni0] disabled
------------[ cut here ]------------
tty_init_dev: ttyMSM driver does not set tty->port. This would crash the kernel. Fix the driver!
WARNING: drivers/tty/tty_io.c:1414 at tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1
Modules linked in: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6
CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S 6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT
Tainted: [S]=CPU_OUT_OF_SPEC
Hardware name: Qualcomm Technologies, Inc. Eliza (DT)
...
tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminator 11)) (P)
tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminator 3) drivers/tty/tty_io.c:2073 (discriminator 3) drivers/tty/tty_io.c:2120 (discriminator 3))
chrdev_open (fs/char_dev.c:411)
do_dentry_open (fs/open.c:962)
vfs_open (fs/open.c:1094)
do_open (fs/namei.c:4634)
path_openat (fs/namei.c:4793)
do_filp_open (fs/namei.c:4820)
do_sys_openat2 (fs/open.c:1391 (discriminator 3))
...
Starting Network Name Resolution...
Apparently the flow with this small Yocto-based ramdisk user-space is:
driver (qcom_geni_serial.c): user-space:
============================ ===========
qcom_geni_serial_probe()
uart_add_one_port()
serial_core_register_port()
serial_core_add_one_port()
uart_configure_port()
register_console()
|
| open console
| ...
| tty_init_dev()
| driver->ports[idx] is NULL
|
tty_port_register_device_attr_serdev()
tty_port_link_device() <- set driver->ports[idx] |
| In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: Fix race between rfkill and nci_unregister_device().
syzbot reported the splat below [0] without a repro.
It indicates that struct nci_dev.cmd_wq had been destroyed before
nci_close_device() was called via rfkill.
nci_dev.cmd_wq is only destroyed in nci_unregister_device(), which
(I think) was called from virtual_ncidev_close() when syzbot close()d
an fd of virtual_ncidev.
The problem is that nci_unregister_device() destroys nci_dev.cmd_wq
first and then calls nfc_unregister_device(), which removes the
device from rfkill by rfkill_unregister().
So, the device is still visible via rfkill even after nci_dev.cmd_wq
is destroyed.
Let's unregister the device from rfkill first in nci_unregister_device().
Note that we cannot call nfc_unregister_device() before
nci_close_device() because
1) nfc_unregister_device() calls device_del() which frees
all memory allocated by devm_kzalloc() and linked to
ndev->conn_info_list
2) nci_rx_work() could try to queue nci_conn_info to
ndev->conn_info_list which could be leaked
Thus, nfc_unregister_device() is split into two functions so we
can remove rfkill interfaces only before nci_close_device().
[0]:
DEBUG_LOCKS_WARN_ON(1)
WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349
WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349
WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349
Modules linked in:
CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026
RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]
RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline]
RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187
Code: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f
RSP: 0018:ffffc9000c767680 EFLAGS: 00010046
RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000
RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0
RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4
R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2
R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30
FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0
Call Trace:
<TASK>
lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868
touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940
__flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982
nci_close_device+0x302/0x630 net/nfc/nci/core.c:567
nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639
nfc_dev_down+0x152/0x290 net/nfc/core.c:161
nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179
rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346
rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301
vfs_write+0x29a/0xb90 fs/read_write.c:684
ksys_write+0x150/0x270 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fa59b39acb9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fa5995f6028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007fa59b615fa0 RCX: 00007fa59b39acb9
RDX: 0000000000000008 RSI: 0000200000000080 RDI: 0000000000000007
RBP: 00007fa59b408bf7 R08:
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
flex_proportions: make fprop_new_period() hardirq safe
Bernd has reported a lockdep splat from flexible proportions code that is
essentially complaining about the following race:
<timer fires>
run_timer_softirq - we are in softirq context
call_timer_fn
writeout_period
fprop_new_period
write_seqcount_begin(&p->sequence);
<hardirq is raised>
...
blk_mq_end_request()
blk_update_request()
ext4_end_bio()
folio_end_writeback()
__wb_writeout_add()
__fprop_add_percpu_max()
if (unlikely(max_frac < FPROP_FRAC_BASE)) {
fprop_fraction_percpu()
seq = read_seqcount_begin(&p->sequence);
- sees odd sequence so loops indefinitely
Note that a deadlock like this is only possible if the bdi has configured
maximum fraction of writeout throughput which is very rare in general but
frequent for example for FUSE bdis. To fix this problem we have to make
sure write section of the sequence counter is irqsafe. |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Graphics Kernel 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. |
