| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915: clear CRTC color blob pointers after dropping refs
intel_crtc_put_color_blobs() drops the CRTC color blob references, but
leaves the corresponding pointers unchanged.
This can matter in intel_crtc_prepare_cleared_state(), which frees the
old CRTC hw state before calling intel_dp_tunnel_atomic_clear_stream_bw().
The latter can fail while looking up the DP tunnel group state, for
example with -EDEADLK.
If that happens, the function returns without completing the cleared
state preparation. The failed atomic state will then be cleared by the
atomic core and intel_crtc_free_hw_state() can be called again for the
same state, dropping the same blob references again.
Clear the blob pointers after dropping the references so repeated cleanup
of the same CRTC hw state is safe.
(cherry picked from commit d5005addb5f68e8a0edce249506757bdc9e3d8c8) |
| 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:
drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm
The cleanup tail of kfd_criu_resume_svm() walks
svms->criu_svm_metadata_list and kfree()s each struct criu_svm_metadata
without removing it from the list. The list head is left pointing at
freed kmalloc-96 objects.
A second AMDKFD_IOC_CRIU_OP from the same process re-enters: list_empty()
reads the dangling ->next (use-after-free), the loop walks freed entries,
and each is kfree()'d again (double-free). This is reachable by an
unprivileged render-group user via /dev/kfd with no capabilities required.
Add list_del() before the kfree() so the list is properly emptied. The
list_for_each_entry_safe() iterator already caches the next pointer, so
unlinking during the walk is safe.
(cherry picked from commit 6322d278a298e2c1430b9d2697743d3a04b788b1) |
| 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:
RDMA/irdma: Replace waitqueue and flag with completion
The driver previously used a waitqueue along with an explicit
request_done flag, but without proper barriers around request_done.
An earlier patch by Gui-Dong Han <hanguidong02@gmail.com> attempted
to fix this by adding the missing memory barriers. Rather than
adding the barriers, this patch replaces the waitqueue+flag with
a completion, which is designed for this exact purpose. |
| In the Linux kernel, the following vulnerability has been resolved:
sockmap: Fix use-after-free in udp_bpf_recvmsg()
syzbot reported use-after-free of struct sk_msg in sk_msg_recvmsg(). [0]
sk_msg_recvmsg() peeks sk_msg from psock->ingress_msg under a lock,
but its processing is lockless.
Thus, sk_msg_recvmsg() must be serialised by callers, otherwise
multiple threads could touch the same sk_msg.
For example, TCP uses lock_sock(), and AF_UNIX uses unix_sk(sk)->iolock.
Initially, udp_bpf_recvmsg() had used lock_sock(), but the cited
commit removed it.
Let's serialise sk_msg_recvmsg() with lock_sock() in udp_bpf_recvmsg().
Note that holding spin_lock_bh(&sk->sk_receive_queue.lock) is not
an option due to copy_page_to_iter() in sk_msg_recvmsg().
[0]:
BUG: KASAN: slab-use-after-free in sk_msg_recvmsg+0xb54/0xc30 net/core/skmsg.c:428
Read of size 4 at addr ffff88814cdcf000 by task syz.0.24/6020
CPU: 1 UID: 0 PID: 6020 Comm: syz.0.24 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xba/0x230 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
sk_msg_recvmsg+0xb54/0xc30 net/core/skmsg.c:428
udp_bpf_recvmsg+0x4bd/0xe00 net/ipv4/udp_bpf.c:84
inet_recvmsg+0x260/0x270 net/ipv4/af_inet.c:891
sock_recvmsg_nosec net/socket.c:1078 [inline]
sock_recvmsg+0x1a8/0x270 net/socket.c:1100
____sys_recvmsg+0x1e6/0x4a0 net/socket.c:2812
___sys_recvmsg+0x215/0x590 net/socket.c:2854
do_recvmmsg+0x334/0x800 net/socket.c:2949
__sys_recvmmsg net/socket.c:3023 [inline]
__do_sys_recvmmsg net/socket.c:3046 [inline]
__se_sys_recvmmsg net/socket.c:3039 [inline]
__x64_sys_recvmmsg+0x198/0x250 net/socket.c:3039
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:0x7fb319f9aeb9
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:00007fb31ad97028 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 00007fb31a216090 RCX: 00007fb319f9aeb9
RDX: 0000000000000001 RSI: 0000200000000400 RDI: 0000000000000004
RBP: 00007fb31a008c1f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000040000021 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb31a216128 R14: 00007fb31a216090 R15: 00007ffe21dd0a98
</TASK>
Allocated by task 6019:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__kmalloc_cache_noprof+0x3d1/0x6e0 mm/slub.c:5780
kmalloc_noprof include/linux/slab.h:957 [inline]
kzalloc_noprof include/linux/slab.h:1094 [inline]
alloc_sk_msg net/core/skmsg.c:510 [inline]
sk_psock_skb_ingress_self+0x60/0x350 net/core/skmsg.c:612
sk_psock_verdict_apply net/core/skmsg.c:1038 [inline]
sk_psock_verdict_recv+0x7d9/0x8d0 net/core/skmsg.c:1236
udp_read_skb+0x73e/0x7e0 net/ipv4/udp.c:2045
sk_psock_verdict_data_ready+0x12d/0x550 net/core/skmsg.c:1257
__udp_enqueue_schedule_skb+0xc54/0x10b0 net/ipv4/udp.c:1789
__udp_queue_rcv_skb net/ipv4/udp.c:2346 [inline]
udp_queue_rcv_one_skb+0xac5/0x19c0 net/ipv4/udp.c:2475
__udp4_lib_mcast_deliver+0xc06/0xcf0 net/ipv4/udp.c:2585
__udp4_lib_rcv+0x10f6/0x2620 net/ipv4/udp.c:2724
ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207
ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241
NF_HOOK+0x336/0x3c0 include/linux/netfilter.h:318
dst_input include/net/dst.h:474 [inline]
ip_sublist_rcv_finish+0x221/0x2a0 net/ipv4/ip_input.c:584
ip_list_rcv_finish net/ipv4/ip_inp
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
cxl/region: Block region delete during region creation
Expand the range lock, rename it "regions_lock", to disable region deletion
in the critical period between construct_region() and attach_target(), as
well as the period between device_add() and registering the remove actions.
Otherwise, userspace can confuse the kernel. It can violate the assumption
the region stays registered through the completion of cxl_add_to_region().
It can violate the assumption that devm_add_action_or_reset() is working
with a live 'struct cxl_region'.
It is ok for the region to disappear outside of those windows as that
mirrors device hotplug flows where the proper locks are held. |
| 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:
nvdimm/btt: Handle preemption in BTT lane acquisition
BTT lanes serialize access to per-lane metadata and workspace state
during BTT I/O. The btt-check unit test reports data mismatches during
BTT writes due to a race in lane acquisition that can lead to silent
data corruption.
The existing lane model uses a spinlock together with a per-CPU
recursion count. That recursion model stopped being valid after BTT
lanes became preemptible: another task can run on the same CPU,
observe a non-zero recursion count, bypass locking, and use the same
lane concurrently.
BTT lanes are also held across arena_write_bytes() calls. That path
reaches nsio_rw_bytes(), which flushes writes with nvdimm_flush().
Some provider flush callbacks can sleep, making a spinlock the wrong
primitive for the lane lifetime.
Replace the spinlock-based recursion model with a dynamically
allocated per-lane mutex array and take the lane lock
unconditionally.
Add might_sleep() to catch any future atomic-context caller.
Found with the ndctl unit test btt-check.sh. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/nldev: Fix locking when accessing mr->pd
Sashiko points out that, due to rereg_mr, the PD is actually variable and
all the touches in nldev are racy.
Use mr->device instead of mr->pd->device.
Getting the PD restrack ID is more tricky. To avoid disturbing all the
happy paths, add an rdma_restrack_sync() operation which is sort of like
flush_workqueue() or synchronize_irq(): after it returns, all the old
nldev touches to the mr are gone and everything sees the new PD. This
makes it safe to reach into the PD pointer. |
| 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. |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: imx: mark I2C adapter when hardware is powered down
On some i.MX platforms, certain I2C client drivers keep a periodic
workqueue which continues to trigger I2C transfers.
During system suspend/resume, there exists a time window between:
- suspend_noirq and the system entering suspend
- the system starting to resume and resume_noirq
In this window, the I2C controller resources such as clock and pinctrl
may already be disabled or not yet restored.
If a workqueue triggers an I2C transfer in this period, the driver
attempts to access I2C registers while the hardware resources are
unavailable, which may lead to system hang.
Mark the I2C adapter as suspended during noirq suspend and block new
transfers until resume, ensuring that I2C transfers are only issued
when hardware resources are available. |
| Race condition in V8 in Google Chrome prior to 151.0.7922.173 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High) |
| 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. |
| Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Telephony Service allows an authorized attacker to elevate privileges locally. |
| In the Linux kernel, the following vulnerability has been resolved:
hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read
If the fan data becomes 0 between the FAN_DATA_VALID() check and the
FAN_PERIOD_TO_RPM() conversion, it will result in a divide-by-zero crash
due to a race with a concurrent update of the cached fan value.
Fix a TOCTOU issue by reading fan data once. |
| 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) |
| A memory corruption vulnerability was addressed with improved locking. This issue is fixed in Safari 26.6.1, iOS 18.7.10 and iPadOS 18.7.10, iOS 26.6.1 and iPadOS 26.6.1, macOS Tahoe 26.6.2. Processing maliciously crafted web content may lead to an unexpected Safari crash. |
