| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
xfs: don't hold buffer locks across sync transaction commit in xfs_sync_sb_buf
xfs_sync_sb_buf() holds sb/rtsb buffer locks across a synchronous
xfs_trans_commit(), which flushes the CIL push workqueue internally.
If shutdown occurs during the CIL push, xfs_buf_item_unpin() needs to
lock these buffers to fail them, causing a deadlock:
setlabel: holds buf lock -> flush_workqueue(xfs-cil)
CIL push worker: xfs_buf_item_unpin -> xfs_buf_lock(same buf)
Remove the xfs_trans_bhold() calls so that commit releases the buffer
locks normally. After the sync commit, re-acquire the buffers via
mp->m_sb_bp / mp->m_rtsb_bp for the on-disk writeback. |
| In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix data race and NULL deref on local->assoc_dev
local->assoc_dev is shared between the association path and the
association-response worker without common synchronization.
mac802154_perform_association() stores the coordinator pointer and waits
for a response. Its timeout and error paths clear the pointer and return
to mac802154_associate(), which may then free the coordinator object.
Meanwhile, mac802154_rx_mac_cmd_worker() may observe the associating bit
and enter mac802154_process_association_resp(), which dereferences
assoc_dev.
The worker's bit test and the handler's pointer dereference are not
atomic with respect to cleanup. Cleanup can clear assoc_dev between them,
causing a NULL dereference, or free the coordinator while the response
handler still uses the pointer.
The recorded result is exposed to the same window. assoc_status and
assoc_addr are written by the handler but read by the association path
while the associating bit is still set, so a second response for the same
request - a malicious one, for instance - can replace them between those
reads and leave the caller with an incoherent status and address pair.
The response handler only needs the coordinator extended address.
Replace assoc_dev with a cached address, removing the pointer lifetime
dependency. Protect the cached address and the associating bit with a
dedicated spinlock. A READ_ONCE()/WRITE_ONCE() pair would not guarantee
an atomic __le64 access on all 32-bit architectures.
wpan_dev->association_lock cannot be reused here: nl802154_associate()
holds it across rdev_associate(), hence for the whole of
mac802154_perform_association() including the wait for the response.
A response handler taking that lock would only get it once the
association has already given up.
Reset the completion, publish the cached address, and set the associating
bit while holding the lock. The response handler takes the lock, rechecks
the bit and the cached address, records the response, clears the bit, and
only then completes the waiter. Thus cleanup cannot pass the handler
between its state check and completion, and the cached 64-bit value
cannot tear.
The handler clears the bit before completing, not the woken waiter:
otherwise complete() is issued under the lock and a second (e.g.
malicious) response can reacquire it before the waiter and replace the
result. So a wait that returns success implies the bit is already clear,
and the success and negative-response paths return directly. The
transmit-error and timeout paths still clear it under assoc_lock, which
serializes any racing response against the cleanup while the call returns
the error it already selected. Both paths snapshot assoc_status and
assoc_addr under the same lock.
Both users run in process context, so a plain spinlock is sufficient.
The lock is not held while waiting for the completion. |
| In the Linux kernel, the following vulnerability has been resolved:
tcp: fix use-after-free in do_tcp_getsockopt(TCP_CC_INFO)
do_tcp_getsockopt() reads icsk->icsk_ca_ops and dereferences the
get_info function pointer without rcu_read_lock(). With BPF struct_ops
congestion control, ca_ops can point to dynamically allocated memory
that is freed concurrently, resulting in a use-after-free when the
kernel dereferences or calls through the stale pointer.
BUG: KASAN: slab-use-after-free in do_tcp_getsockopt+0x2037/0x23e0
Read of size 8 at addr ffff888013701258 by task exploit/149
do_tcp_getsockopt+0x2037/0x23e0 (net/ipv4/tcp.c:4564)
tcp_getsockopt+0x91/0xf0
__sys_getsockopt+0xf7/0x170
Fix this by wrapping the ca_ops load and get_info call within
rcu_read_lock()/rcu_read_unlock(), and using READ_ONCE() to load
the icsk_ca_ops pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
tcp: fix use-after-free in do_tcp_getsockopt(TCP_CONGESTION)
do_tcp_getsockopt() reads icsk->icsk_ca_ops->name without holding
rcu_read_lock(). Since commit 0baf26b0fcd7 ("bpf: tcp: Support
tcp_congestion_ops in bpf"), icsk_ca_ops can point to dynamically
allocated BPF struct_ops memory that may be freed concurrently via
setsockopt(TCP_CONGESTION), leading to a use-after-free.
BUG: KASAN: slab-use-after-free in _copy_to_user+0x37/0x60
Read of size 16 at addr ffff888013505260 by task exploit/149
_copy_to_user+0x37/0x60
do_tcp_getsockopt+0x158a/0x2460 (net/ipv4/tcp.c:4585)
tcp_getsockopt+0x91/0xf0
__sys_getsockopt+0xf7/0x170
Fix this by holding rcu_read_lock() around the ca_ops->name access,
using READ_ONCE() to load icsk_ca_ops, and copying the name to a
stack buffer before releasing the lock. Also annotate the relevant
icsk_ca_ops stores with WRITE_ONCE() to fix the accompanying KCSAN
data-race issue. |
| Out-of-bounds read in Microsoft Windows Search Component allows an authorized attacker to disclose information locally. |
| Numeric truncation error in Microsoft Windows Search Component allows an authorized attacker to elevate privileges locally. |
| A use-after-free in present_clear_window_notifies() in the X.org X Server before 21.1.25 and X Wayland before 24.1.14 could be used by malicious X clients to crash or potentially execute code in the X server context. |
| Improper resolution of path equivalence in Windows Backup Engine allows an authorized attacker to elevate privileges locally. |
| Protection mechanism failure in Windows PowerShell allows an authorized attacker to bypass a security feature locally. |
| HCL BigFix AEX product is affected by a vulnerability in the aws-sdk package.. It may cause AWS API requests to be sent to unintended or non‐AWS endpoints. |
| Use after free in Windows Ancillary Function Driver for WinSock allows an authorized attacker to disclose information locally. |
| Out-of-bounds read in Windows DHCP Server allows an authorized attacker to deny service locally. |
| In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027, uncontrolled recursion, infinite loop, unchecked loop condition and inefficient regular expression vulnerabilities in RadSpreadProcessing and RadSpreadStreamProcessing allow an unauthenticated attacker to terminate or hang the host process via a crafted XLSX or XLS workbook or formula. |
| In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027, uncontrolled recursion, infinite loop, inefficient algorithmic complexity and resource allocation vulnerabilities in RadPdfProcessing and AI document summarization and question answering allow an unauthenticated attacker to terminate or hang the host process via a crafted PDF document or document text submitted for summarization or question answering. |
| Access of resource using incompatible type ('type confusion') in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally. |
| In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027, uncontrolled recursion, inefficient algorithmic complexity and infinite loop vulnerabilities in RadWordsProcessing allow an unauthenticated attacker to terminate or hang the host process via a crafted DOCX, DOC, RTF or HTML document. |
| In Progress® Telerik® Document Processing Libraries prior to version 2026.3.1027, improper verification of cryptographic signatures and improper certificate validation in RadPdfProcessing digital signature validation allow an unauthenticated attacker to cause signature validation to report forged content as unmodified and its signing certificate as valid via a crafted signed PDF document. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: nVMX: Reset MMU back to the root MMU if loading L2 state fails for !VM-Entry
Reset the vCPU's MMU pointer back to the root MMU if loading L2 state fails
in the "not from VM-Entry" case, i.e. when emulating RSM or handling
KVM_SET_NESTED_STATE. Failure to unwind the MMU pointer results in KVM
trying to run L1 with a nested MMU, and is especially problematic if the
vCPU manages to free its nested state before the VM crashes. Constructing
the root for a nested EPT MMU goes through vmcs12, which is dynamically
allocated/freed when nVMX is enabled/disabled. And so if the nested state
is freed with the MMU still pointing at the nested MMU, KVM will hit a NULL
pointer deref when attempting to get L1=>L2 EPTP.
BUG: kernel NULL pointer dereference, address: 0000000000000078
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 114a2d067 P4D 111743067 PUD 11141f067 PMD 0
Oops: Oops: 0000 [#1] SMP
CPU: 20 UID: 1000 PID: 1272 Comm: nested_tdp_faul Not tainted 7.3.0-rc4-8c89f11d1a99b-sink-vm #1914 PREEMPTLAZY
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel]
Call Trace:
<TASK>
kvm_mmu_load+0xcd/0x870 [kvm]
kvm_arch_vcpu_ioctl_run+0x18f5/0x1f80 [kvm]
kvm_vcpu_ioctl+0x2c7/0x970 [kvm]
__x64_sys_ioctl+0x90/0xd0
do_syscall_64+0x9c/0x4d0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x47491b
</TASK>
Modules linked in: kvm_intel kvm irqbypass
CR2: 0000000000000078
---[ end trace 0000000000000000 ]---
RIP: 0010:nested_ept_get_eptp+0xb/0x10 [kvm_intel]
[sean: write changelog] |
| In the Linux kernel, the following vulnerability has been resolved:
accel/rocket: search every core slot when looking up a scheduler
sched_to_core() walks rdev->cores[] up to rdev->num_cores, and
rocket_remove() decrements num_cores for every core it removes. Unbind a
core that is not the last one and the cores behind it fall outside the
search, so sched_to_core() returns NULL for a core that is still bound and
still running jobs. Neither caller checks the result:
rocket_job_run(): rocket_fence_create(core), core->dev
rocket_job_timedout(): dev_err(core->dev, "NPU job timed out")
Unbinding the middle core of the three on an RK3588 while three clients are
submitting to all of them faults twice, once from the surviving core's
job queue and once from its reset work:
KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]
Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched]
pc : rocket_job_run+0x234/0x838 [rocket]
Call trace:
rocket_job_run+0x234/0x838 [rocket]
drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched]
process_one_work+0x640/0x14f0
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched]
pc : rocket_job_timedout+0xf0/0x1e0 [rocket]
Call trace:
rocket_job_timedout+0xf0/0x1e0 [rocket]
drm_sched_job_timedout+0x188/0x6a0 [gpu_sched]
Both are the third core: the workqueue names are its device and its
core->index, and it was left at slot 2 while num_cores had dropped to 2.
Search all the slots that were allocated, the way find_core_for_dev() now
does. A core that is still bound is then found, and the two callers get
the pointer they already assume they have.
This does not make unbinding one core out of several safe. An open client
keeps an entity pointing at the scheduler of the core that went away:
drm_sched reports it as not ready for every job that lands on it, and the
client waits in dma_fence_default_wait for a fence that will never signal.
Stopping the NULL dereference is what belongs in a fix; the rest wants
more thought. |
| In the Linux kernel, the following vulnerability has been resolved:
firewire: core: fix race condition in split transaction handling
For a split transaction, either fw_core_handle_response() or
split_transaction_timeout_callback() may manipulate the same transaction
entry in the pending transaction list. The return value of timer_delete()
is used to determine which function handles the entry. If the transaction
is a split transaction and timer_delete() returns zero, the timeout
callback may already be running. In this case, the response handler must
leave the entry in the list for the timeout callback to remove.
A previous code refactoring broke this behavior, introducing a race
condition in which both functions could process the same transaction.
This could lead to a use-after-free on the transaction initiator side.
Fix the regression by ensuring that the response handler does not process
the transaction when timer_delete() returns zero. The timeout callback is
responsible for removing the entry from the pending transaction list. |
