| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
xsk: clear metadata pointer when no timestamp is requested
User space can change metadata flags after request processing. Rereading
them during completion can therefore make the kernel write a timestamp
that was not requested when the packet was submitted.
Clear the metadata pointer during request processing unless timestamp
completion is requested. Completion handling can then use the pointer
itself instead of rereading the flags.
On the mlx5 multi-packet WQE path metadata is evaluated per batch:
xsk_tx_metadata_request() runs only for the descriptor that starts a
session, just like the checksum offload that is applied once through the
shared WQE. Only that descriptor's pointer is reset, so completion
handling can record a timestamp for the other descriptors of the session
regardless of their own XDP_TXMD_FLAGS_TIMESTAMP bit. The write stays
inside the metadata area; the single-WQE, other zero-copy, and generic
paths reset the pointer per descriptor and are unaffected. |
| In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Use current_context for safe per-CPU buffer swap
The ring_buffer_swap_cpu() function currently checks the per-CPU
committing counter to determine if a buffer is actively being written to
before performing the swap. However, there exists a race window where
this check can be bypassed:
ring_buffer_lock_reserve
cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_a
rb_reserve_next_event
rb_start_commit // inc committing
if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) {...}
__rb_reserve_next
rb_move_tail
rb_end_commit(cpu_buffer); // dec committing => 0
/* interrupt hits here, successfully swaps! */
local_inc(&cpu_buffer->committing);
ring_buffer_unlock_commit
cpu_buffer = buffer->buffers[cpu]; // cpu_buffer_b
rb_commit
rb_end_commit
RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing))
// triggers warning
The committing counter can temporarily drop to 0 during a single write
operation (within rb_move_tail), creating a window where swap can
succeed even though the write is still in progress. This leads to
inconsistent buffer state and triggers the RB_WARN_ON in rb_commit().
Replace the committing counter check with current_context checks, which
are set at the entry of ring_buffer_lock_reserve() and remain valid
throughout the entire write operation, providing a reliable indicator of
buffer busy state during swap. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/filemap: __filemap_add_folio() restore index before retrying
In __filemap_add_folio()'s split-a-conflict loop, xas_set_order() is
applied repeatedly: each application modifies xas.xa_index, rounding it
down according to the split_order attempted at that stage: and if all goes
as intended, it eventually (or immediately) converges on an
xas_try_split() to the required folio_order, with xas.xa_index now the
same as index: then xas_store() puts the new folio into the xarray there.
But if a new node was needed, and GFP_NOWAIT allocation did not get one,
the lock is dropped, xas_nomem() used to allocate, and sequence retried.
If (that part of) the xarray is unchanged when the lock is reacquired, no
problem. But what if the conflict was meanwhile resolved by another
thread (perhaps even doing the same thing, inserting a folio at that same
index)? Isn't there a danger of now putting our folio into the xarray at
an intermediate rounded-down index? With !folio_contains() bug to follow,
when CONFIG_DEBUG_VM=y is checking for that.
Fix this with an xas_set_order() to restore the original xas.xa_index at
the bottom of the loop, so the retry does a full re-evaluation after
reacquiring the lock, and cannot reach xas_store() with the wrong index.
Production was suffering from rare SIGILLs and SIGSEGVs, executable text
found a page away from where it belonged, !folio_contains() bug hit when
debug enabled: symptoms not seen since this patch went in. |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to execute arbitrary code due to a time-of-check to time-of-use (TOCTOU) race condition. |
| IBM AIX 7.2, and 7.3 and IBM PowerVM VIOS 4.1 could allow a local attacker to gain root privileges due to a time-of-check to time-of-use (TOCTOU) race condition. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Serialize the scheduler timeout handlers
V3D exposes several independent hardware queues (BIN, RENDER, TFU and
CSD) but has only a single, global reset. A timeout on any one queue
therefore has to stop, reset and restart the schedulers of every other
queue as well. That makes concurrent timeout handlers unsafe.
`reset_lock` was never able to make them safe, as a driver-side lock can
only cover the driver's &drm_sched_backend_ops.timedout_job callback.
The scheduler handles the timed out job and its pending list around that
callback, outside of the driver's control, so a global reset triggered
by one queue can still interfere with another queue that is in the
middle of handling a timeout of its own.
Consequently, if a reset happens in the CSD queue while a CL-intensive
application is running, the global reset stops and restarts the CL
queue's scheduler while that queue is handling a timeout of its own. As
drm_sched_stop() and drm_sched_start() subtract and add the credits of
every job sitting on the pending list of the scheduler they are called
on, and as the CL queue's handler concurrently takes its job off that
same list and puts it back, the stop and the start no longer see the
same set of jobs. The CL queue is left with more credits in flight than
its limit:
[ 327.302739] ------------[ cut here ]------------
[ 327.302744] WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched]
[ 327.302884] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.18.39-v8-16k+ #3 PREEMPT
[ 327.302889] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)
[ 327.302893] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched]
[ 327.302984] Call trace:
[ 327.302987] drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] (P)
[ 327.302997] process_scheduled_works+0x180/0x3d0
[ 327.303010] worker_thread+0x268/0x3e8
[ 327.303016] kthread+0x140/0x250
[ 327.303022] ret_from_fork+0x10/0x20
[ 327.303031] ---[ end trace 0000000000000000 ]---
From that point on, the credit count of the CL queue is broken, causing
a complete GPU hang and UI freeze.
The DRM scheduler already provides a mechanism to serialize the timeout
handlers of different schedulers: an ordered workqueue passed as
drm_sched_init()'s @timeout_wq parameter. By default, each scheduler
queues its timeout work on the system workqueue, which runs the handlers
concurrently. Give all of the queues a shared ordered workqueue instead,
as recommended by the DRM scheduler documentation for hardware that has
distinct queues but resets globally. |
| In the Linux kernel, the following vulnerability has been resolved:
9p: skip nlink update in cacheless mode to fix WARN_ON
v9fs_dec_count() unconditionally calls drop_nlink() on regular files,
even when the inode's nlink is already zero. In cacheless mode the
client refetches inode metadata from the server (the source of truth)
on every operation, so by the time v9fs_remove() returns, the locally
cached nlink may already reflect the post-unlink value:
1. Client initiates unlink, server processes it and sets nlink to 0
2. Client refetches inode metadata (nlink=0) before unlink returns
3. Client's v9fs_remove() completes successfully
4. Client calls v9fs_dec_count() which calls drop_nlink() on nlink=0
This race is easily triggered under heavy unlink workloads, such as
stress-ng's unlink stressor, producing the following warning:
WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8
Call trace:
drop_nlink+0x4c/0xc8
v9fs_remove+0x1e0/0x250 [9p]
v9fs_vfs_unlink+0x20/0x38 [9p]
vfs_unlink+0x13c/0x258
...
In cacheless mode the server is authoritative and the inode is on its
way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count()
entirely when neither CACHE_META nor CACHE_LOOSE is set, which both
avoids the warning and removes a class of nlink races (two concurrent
unlinkers observing nlink > 0 and both calling drop_nlink()) that an
nlink == 0 guard alone would only narrow rather than close. |
| In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: userspace: fix use-after-free in get_local_id
In mptcp_pm_userspace_get_local_id(), the address entry is looked up under
spinlock, but its id is read after dropping the lock. A concurrent deletion
can free the entry between the unlock and the read, leading to UAF.
The race window is narrow. It was reproduced only with a locally
constructed stress test that repeatedly overlaps an MP_JOIN SYN with a
MPTCP_PM_CMD_SUBFLOW_DESTROY request.
However, the KASAN report below confirms that the race is reachable:
[ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0
[ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0
...
[ 666.319401] Call Trace:
[ 666.319405] <IRQ>
[ 666.319408] dump_stack_lvl+0x53/0x70
[ 666.319412] print_address_description.constprop.0+0x2c/0x3b0
[ 666.319418] print_report+0xbe/0x2b0
[ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0
[ 666.319423] kasan_report+0xce/0x100
[ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0
[ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0
[ 666.319433] mptcp_pm_get_local_id+0x371/0x440
...
[ 666.319821] Allocated by task 45539:
[ 666.319844] kasan_save_stack+0x33/0x60
[ 666.319855] kasan_save_track+0x14/0x30
[ 666.319858] __kasan_kmalloc+0x8f/0xa0
[ 666.319863] __kmalloc_noprof+0x1e7/0x520
[ 666.319867] sock_kmalloc+0xdf/0x130
[ 666.319885] sock_kmemdup+0x1b/0x40
[ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500
[ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610
...
[ 666.319967] Freed by task 45560:
[ 666.319988] kasan_save_stack+0x33/0x60
[ 666.319991] kasan_save_track+0x14/0x30
[ 666.319994] kasan_save_free_info+0x3b/0x60
[ 666.319998] __kasan_slab_free+0x43/0x70
[ 666.320000] kfree+0x166/0x440
[ 666.320003] sock_kfree_s+0x1d/0x50
[ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200
[ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0
Fix by copying the id into a local variable while still holding the lock,
and use -1 as a "not found" sentinel. |
| In the Linux kernel, the following vulnerability has been resolved:
futex: Prevent robust futex exit race some more
A robust futex unlock stores 0 over the whole futex value - wiping
FUTEX_WAITERS - and wakes a single waiter. That wakeup is a one-shot
notification: the protocol relies on its recipient to either acquire the
futex (and eventually unlock while aware of the remaining contention) or
re-arm FUTEX_WAITERS before sleeping again. If the woken waiter is killed
before it can do either, the kernel must jump in and wake the next task
down the line.
This is a known complication of the futex protocol with a previous
partial fix in commit ca16d5bee598 ("futex: Prevent robust futex exit
race"). Unfortunately, that fix is insufficient.
If a third task re-acquired the futex through the uncontended fast
path in the meantime, the notification is lost: robust exit processing
sees that it is owned by another task and does nothing, while the new
owner sees no FUTEX_WAITERS when it unlocks and wakes nobody.
The remaining waiters sleep forever behind a free futex:
A owns the futex, B and C sleep in FUTEX_WAIT
uval == A | FUTEX_WAITERS
A robust unlock: store 0, FUTEX_WAKE(1) wakes B
uval == 0
D fast path acquire: cmpxchg(0 -> D)
uval == D, no FUTEX_WAITERS
B killed before acting on the wakeup
B exit walk, pending op: owner D != B -> no action
D unlock: no FUTEX_WAITERS -> no wake
C sleeps forever
This is clearly a shortcoming in the implementation, which fails to keep
the FUTEX_WAITERS bit consistent.
Work around this by augmenting the robust list exit processing to also
perform the extra wakeup if the futex word is owned by another thread but
FUTEX_WAITERS is not set.
This does not fix the problem of a non-contended take over/release and free
sequence, which has been discussed for years and has been addressed by
commit 3ca9595d9fb6 ("futex: Add support for unlocking robust futexes") and
subsequent changes, but failed to take the problem described above into
account.
A more complete solution which is based on the in kernel unlock of
contended robust futexes has been discussed in the context of this change
and should show up in mainline sooner than later.
[ tglx: Amend change log slightly and fixup coding style ] |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: avoid moving extents to occupied clusters
For non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical
me_goal. ocfs2_move_extent() initializes new_phys_cpos from that goal and
expects ocfs2_probe_alloc_group() to replace it with a free run in the
target block group.
The probe currently leaves *phys_cpos unchanged if the scan reaches the
end of the group without finding a free run. An occupied goal at the last
bit can therefore survive the probe and be passed to
__ocfs2_move_extent(), which copies file data into a cluster still owned
by another inode before the bitmap is updated.
When the probe does find a free run, it also subtracts move_len from the
ending bit. The start of an N-bit run ending at i is i - N + 1, so the
current calculation can report the bit immediately before the free run.
Clear *phys_cpos before scanning and use the correct free-run start.
Callers already treat a zero result as -ENOSPC, so failed probes no longer
continue with an occupied caller-controlled goal. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers
kvm_io_bus_get_dev() returns a device that is only matched by the
address, and nothing else. This can cause a lifetime issue if
the matched device is not the expected type, as by the time
the caller can introspect the object, it might be gone (the srcu
lock having been dropped).
Given that there is only a single user of this helper, the simplest
option is to move the locking responsibility to the caller, which
can keep the srcu lock held for as long as it wants.
Note that this aligns with other kvm_io_bus*() helpers, which
already require the srcu lock to be held by the callers. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix unlikely race in try_get_locked_pte()
Fix an unlikely race in try_get_locked_pte(), which could have happened
if puds or pmds get unmapped between the p?dp_get() and p?d_offset()
functions. |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Validate NIX maximum LFs correctly
NIX maximum number of LFs can be set via devlink command
but that can be done before assigning any LFs to a PF/VF.
The condition used to check whether any LFs are assigned is
incorrect. This patch fixes that condition. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: Fix xfrm state cache insertion race
The xfrm input state cache insertion code checks the validity of
the state before acquiring the global xfrm_state_lock. Thus it's
possible for someone else to kill the state after it passed the
validity check, and then the insertion will add the dead state
to the cache.
Fix this by moving the validity check inside the lock.
This entire function is called on the input path, where BH must
be off (e.g., the caller of this function xfrm_input acquires
its spinlocks without disabling BH).
So there is no need to disable BH here or take the RCU read lock.
Remove both and replace them with an assertion that trips if BH
is accidentally enabled on some future calling path. |
| In the Linux kernel, the following vulnerability has been resolved:
cxl/region: Resolve region deletion races
Sungwoo noticed that the sysfs trigger to delete a region may try to delete
a region multiple times. It also has no exclusion relative to the kernel
releasing the region via CXL root device teardown.
Instead of installing new cxl root devres actions per region, use the
existing root decoder unregistration event to remove all remaining regions.
An xarray of regions replaces a devres list of regions.
This handles 3 separate issues with the old approach:
1/ sysfs users racing to delete the same region: no longer possible now
that the regions_lock is held over the lookup and deletion.
2/ multiple actions triggering deletion of the same region: solved by
erasing regions while holding @regions_lock, and only proceeding on
successful erasure.
3/ userspace racing devres_release_all() to trigger the devres not found
warning: solved by sysfs unregistration not requiring a release action |
| In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix list corruption in allocate_file_region_entries()
allocate_file_region_entries() tops up resv->region_cache with freshly
allocated file_region descriptors. The allocation uses GFP_KERNEL, so
resv->lock is dropped around it: the new entries are gathered on a
stack-local list head, allocated_regions, and spliced into
resv->region_cache once the lock is re-acquired.
The splice used list_splice(), which moves the entries but does not
re-initialize the source head, so allocated_regions is left pointing at an
entry that now lives on resv->region_cache. The top-up runs in a while
loop that re-checks the cache deficit after re-acquiring the lock. For a
shared mapping the resv_map is shared by every mapper of the hugetlbfs
inode, so a concurrent region_chg()/region_add()/region_del() on the same
resv_map can consume cache entries during the unlocked window and force a
second iteration. That iteration calls list_add() on the stale head and
corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check
trips:
list_add corruption. next->prev should be prev (ffffc900011ff7f8),
but was ffff88814c281460. (next=ffff88814c545640).
kernel BUG at lib/list_debug.c:31!
allocate_file_region_entries+0x191/0x420
region_chg+0x267/0x300
hugetlb_reserve_pages+0x387/0xc80
hugetlbfs_file_mmap+0x2ce/0x3f0
mmap_region+0x1348/0x1a80
do_mmap+0x85e/0xb90
vm_mmap_pgoff+0x18c/0x330
ksys_mmap_pgoff+0x2a1/0x3e0
do_syscall_64+0xd7/0x420
Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack
address into resv->region_cache, leading to later use-after-free.
This was observed as a real host panic on a dense KVM host where a QEMU
guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate
SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one
shared resv_map.
Use list_splice_init() so the source head is re-initialized empty after
each splice, making the retry loop safe. |
| In the Linux kernel, the following vulnerability has been resolved:
vduse: hold vduse_lock across IDR lookup in open path
vduse_dev_open() looks up struct vduse_dev through the IDR and then
acquires dev->lock only after vduse_lock has been dropped.
This leaves a window where a concurrent VDUSE_DESTROY_DEV can remove the
same object from the IDR and free it before the open path locks the
device, leading to a use-after-free.
Close this race by keeping vduse_lock held until dev->lock has been
acquired in the open path, matching the lock ordering already used by
the destroy path. |
| In the Linux kernel, the following vulnerability has been resolved:
liveupdate: fix TOCTOU race in luo_session_retrieve()
Extend the scope of the rwsem_read lock in luo_session_retrieve() to
overlap with the acquisition of the session mutex. This prevents a
concurrent thread from releasing and freeing the session between the
lookup and the mutex lock. |
| n8n is an open source workflow automation platform. Prior to 1.123.64, 2.29.8, and 2.30.1, the Git node clone operation allows an authenticated workflow user to swap a validated directory for a symlink before cloning, planting a crafted repository in the community node directory that loads as a custom JavaScript node after restart and executes arbitrary code on the server. This issue is fixed in versions 1.123.64, 2.29.8, and 2.30.1. |
| Race condition in USB in Google Chrome prior to 151.0.7922.169 allowed a remote attacker who had compromised the renderer process to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High) |
