| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix dead lock while flushing management frames
Commit [1] converted the management transmission work item into a
wiphy work. Since a wiphy work can only run under wiphy lock
protection, a race condition happens in below scenario:
1. a management frame is queued for transmission.
2. ath12k_mac_op_flush() gets called to flush pending frames associated
with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush()
the process waits for the transmission done.
3. Since wiphy lock has been taken by the flush process, the transmission
work item has no chance to run, hence the dead lock.
>From user view, this dead lock results in below issue:
wlp8s0: authenticate with xxxxxx (local address=xxxxxx)
wlp8s0: send auth to xxxxxx (try 1/3)
wlp8s0: authenticate with xxxxxx (local address=xxxxxx)
wlp8s0: send auth to xxxxxx (try 1/3)
wlp8s0: authenticated
wlp8s0: associate with xxxxxx (try 1/3)
wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING)
ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1
The dead lock can be avoided by invoking wiphy_work_flush() to proactively
run the queued work item. Note actually it is already present in
ath12k_mac_op_flush(), however it does not protect the case where vif
being NULL. Hence move it ahead to cover this case as well.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 |
| In the Linux kernel, the following vulnerability has been resolved:
sfc: fix deadlock in RSS config read
Since cited commit, core locks the net_device's rss_lock when handling
ethtool -x command, so driver's implementation should not lock it
again. Remove the latter. |
| In the Linux kernel, the following vulnerability has been resolved:
virtio_net: fix device mismatch in devm_kzalloc/devm_kfree
Initial rss_hdr allocation uses virtio_device->device,
but virtnet_set_queues() frees using net_device->device.
This device mismatch causing below devres warning
[ 3788.514041] ------------[ cut here ]------------
[ 3788.514044] WARNING: drivers/base/devres.c:1095 at devm_kfree+0x84/0x98, CPU#16: vdpa/1463
[ 3788.514054] Modules linked in: octep_vdpa virtio_net virtio_vdpa [last unloaded: virtio_vdpa]
[ 3788.514064] CPU: 16 UID: 0 PID: 1463 Comm: vdpa Tainted: G W 6.18.0 #10 PREEMPT
[ 3788.514067] Tainted: [W]=WARN
[ 3788.514069] Hardware name: Marvell CN106XX board (DT)
[ 3788.514071] pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
[ 3788.514074] pc : devm_kfree+0x84/0x98
[ 3788.514076] lr : devm_kfree+0x54/0x98
[ 3788.514079] sp : ffff800084e2f220
[ 3788.514080] x29: ffff800084e2f220 x28: ffff0003b2366000 x27: 000000000000003f
[ 3788.514085] x26: 000000000000003f x25: ffff000106f17c10 x24: 0000000000000080
[ 3788.514089] x23: ffff00045bb8ab08 x22: ffff00045bb8a000 x21: 0000000000000018
[ 3788.514093] x20: ffff0004355c3080 x19: ffff00045bb8aa00 x18: 0000000000080000
[ 3788.514098] x17: 0000000000000040 x16: 000000000000001f x15: 000000000007ffff
[ 3788.514102] x14: 0000000000000488 x13: 0000000000000005 x12: 00000000000fffff
[ 3788.514106] x11: ffffffffffffffff x10: 0000000000000005 x9 : ffff800080c8c05c
[ 3788.514110] x8 : ffff800084e2eeb8 x7 : 0000000000000000 x6 : 000000000000003f
[ 3788.514115] x5 : ffff8000831bafe0 x4 : ffff800080c8b010 x3 : ffff0004355c3080
[ 3788.514119] x2 : ffff0004355c3080 x1 : 0000000000000000 x0 : 0000000000000000
[ 3788.514123] Call trace:
[ 3788.514125] devm_kfree+0x84/0x98 (P)
[ 3788.514129] virtnet_set_queues+0x134/0x2e8 [virtio_net]
[ 3788.514135] virtnet_probe+0x9c0/0xe00 [virtio_net]
[ 3788.514139] virtio_dev_probe+0x1e0/0x338
[ 3788.514144] really_probe+0xc8/0x3a0
[ 3788.514149] __driver_probe_device+0x84/0x170
[ 3788.514152] driver_probe_device+0x44/0x120
[ 3788.514155] __device_attach_driver+0xc4/0x168
[ 3788.514158] bus_for_each_drv+0x8c/0xf0
[ 3788.514161] __device_attach+0xa4/0x1c0
[ 3788.514164] device_initial_probe+0x1c/0x30
[ 3788.514168] bus_probe_device+0xb4/0xc0
[ 3788.514170] device_add+0x614/0x828
[ 3788.514173] register_virtio_device+0x214/0x258
[ 3788.514175] virtio_vdpa_probe+0xa0/0x110 [virtio_vdpa]
[ 3788.514179] vdpa_dev_probe+0xa8/0xd8
[ 3788.514183] really_probe+0xc8/0x3a0
[ 3788.514186] __driver_probe_device+0x84/0x170
[ 3788.514189] driver_probe_device+0x44/0x120
[ 3788.514192] __device_attach_driver+0xc4/0x168
[ 3788.514195] bus_for_each_drv+0x8c/0xf0
[ 3788.514197] __device_attach+0xa4/0x1c0
[ 3788.514200] device_initial_probe+0x1c/0x30
[ 3788.514203] bus_probe_device+0xb4/0xc0
[ 3788.514206] device_add+0x614/0x828
[ 3788.514209] _vdpa_register_device+0x58/0x88
[ 3788.514211] octep_vdpa_dev_add+0x104/0x228 [octep_vdpa]
[ 3788.514215] vdpa_nl_cmd_dev_add_set_doit+0x2d0/0x3c0
[ 3788.514218] genl_family_rcv_msg_doit+0xe4/0x158
[ 3788.514222] genl_rcv_msg+0x218/0x298
[ 3788.514225] netlink_rcv_skb+0x64/0x138
[ 3788.514229] genl_rcv+0x40/0x60
[ 3788.514233] netlink_unicast+0x32c/0x3b0
[ 3788.514237] netlink_sendmsg+0x170/0x3b8
[ 3788.514241] __sys_sendto+0x12c/0x1c0
[ 3788.514246] __arm64_sys_sendto+0x30/0x48
[ 3788.514249] invoke_syscall.constprop.0+0x58/0xf8
[ 3788.514255] do_el0_svc+0x48/0xd0
[ 3788.514259] el0_svc+0x48/0x210
[ 3788.514264] el0t_64_sync_handler+0xa0/0xe8
[ 3788.514268] el0t_64_sync+0x198/0x1a0
[ 3788.514271] ---[ end trace 0000000000000000 ]---
Fix by using virtio_device->device consistently for
allocation and deallocation |
| In the Linux kernel, the following vulnerability has been resolved:
drm/panel-simple: fix connector type for DataImage SCF0700C48GGU18 panel
The connector type for the DataImage SCF0700C48GGU18 panel is missing and
devm_drm_panel_bridge_add() requires connector type to be set. This leads
to a warning and a backtrace in the kernel log and panel does not work:
"
WARNING: CPU: 3 PID: 38 at drivers/gpu/drm/bridge/panel.c:379 devm_drm_of_get_bridge+0xac/0xb8
"
The warning is triggered by a check for valid connector type in
devm_drm_panel_bridge_add(). If there is no valid connector type
set for a panel, the warning is printed and panel is not added.
Fill in the missing connector type to fix the warning and make
the panel operational once again. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: release path before iget_failed() in btrfs_read_locked_inode()
In btrfs_read_locked_inode() if we fail to lookup the inode, we jump to
the 'out' label with a path that has a read locked leaf and then we call
iget_failed(). This can result in a ABBA deadlock, since iget_failed()
triggers inode eviction and that causes the release of the delayed inode,
which must lock the delayed inode's mutex, and a task updating a delayed
inode starts by taking the node's mutex and then modifying the inode's
subvolume btree.
Syzbot reported the following lockdep splat for this:
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
btrfs-cleaner/8725 is trying to acquire lock:
ffff0000d6826a48 (&delayed_node->mutex){+.+.}-{4:4}, at: __btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290
but task is already holding lock:
ffff0000dbeba878 (btrfs-tree-00){++++}-{4:4}, at: btrfs_tree_read_lock_nested+0x44/0x2ec fs/btrfs/locking.c:145
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (btrfs-tree-00){++++}-{4:4}:
__lock_release kernel/locking/lockdep.c:5574 [inline]
lock_release+0x198/0x39c kernel/locking/lockdep.c:5889
up_read+0x24/0x3c kernel/locking/rwsem.c:1632
btrfs_tree_read_unlock+0xdc/0x298 fs/btrfs/locking.c:169
btrfs_tree_unlock_rw fs/btrfs/locking.h:218 [inline]
btrfs_search_slot+0xa6c/0x223c fs/btrfs/ctree.c:2133
btrfs_lookup_inode+0xd8/0x38c fs/btrfs/inode-item.c:395
__btrfs_update_delayed_inode+0x124/0xed0 fs/btrfs/delayed-inode.c:1032
btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1118 [inline]
__btrfs_commit_inode_delayed_items+0x15f8/0x1748 fs/btrfs/delayed-inode.c:1141
__btrfs_run_delayed_items+0x1ac/0x514 fs/btrfs/delayed-inode.c:1176
btrfs_run_delayed_items_nr+0x28/0x38 fs/btrfs/delayed-inode.c:1219
flush_space+0x26c/0xb68 fs/btrfs/space-info.c:828
do_async_reclaim_metadata_space+0x110/0x364 fs/btrfs/space-info.c:1158
btrfs_async_reclaim_metadata_space+0x90/0xd8 fs/btrfs/space-info.c:1226
process_one_work+0x7e8/0x155c kernel/workqueue.c:3263
process_scheduled_works kernel/workqueue.c:3346 [inline]
worker_thread+0x958/0xed8 kernel/workqueue.c:3427
kthread+0x5fc/0x75c kernel/kthread.c:463
ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:844
-> #0 (&delayed_node->mutex){+.+.}-{4:4}:
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x1774/0x30a4 kernel/locking/lockdep.c:5237
lock_acquire+0x14c/0x2e0 kernel/locking/lockdep.c:5868
__mutex_lock_common+0x1d0/0x2678 kernel/locking/mutex.c:598
__mutex_lock kernel/locking/mutex.c:760 [inline]
mutex_lock_nested+0x2c/0x38 kernel/locking/mutex.c:812
__btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290
btrfs_release_delayed_node fs/btrfs/delayed-inode.c:315 [inline]
btrfs_remove_delayed_node+0x68/0x84 fs/btrfs/delayed-inode.c:1326
btrfs_evict_inode+0x578/0xe28 fs/btrfs/inode.c:5587
evict+0x414/0x928 fs/inode.c:810
iput_final fs/inode.c:1914 [inline]
iput+0x95c/0xad4 fs/inode.c:1966
iget_failed+0xec/0x134 fs/bad_inode.c:248
btrfs_read_locked_inode+0xe1c/0x1234 fs/btrfs/inode.c:4101
btrfs_iget+0x1b0/0x264 fs/btrfs/inode.c:5837
btrfs_run_defrag_inode fs/btrfs/defrag.c:237 [inline]
btrfs_run_defrag_inodes+0x520/0xdc4 fs/btrf
---truncated--- |
| VB-Audio Matrix and Matrix Coconut (versions ending in 1.0.2.2 and 2.0.2.2 and earlier, respectively), contain a local privilege escalation vulnerability in the VBMatrix VAIO virtual audio driver (vbmatrixvaio64*_win10.sys). The driver allocates a 128-byte non-paged pool buffer and, upon receiving IOCTL 0x222060, maps it into user space using an MDL and MmMapLockedPagesSpecifyCache. Because the allocation size is not page-aligned, the mapping exposes the entire 0x1000-byte kernel page containing the buffer plus adjacent non-paged pool allocations with read/write permissions. An unprivileged local attacker can open a device handle (using the required 0x800 attribute flag), invoke the IOCTL to obtain the mapping, and then read or modify live kernel objects and pointers present on that page. This enables bypass of KASLR, arbitrary kernel memory read/write within the exposed page, corruption of kernel objects, and escalation to SYSTEM. |
| In the Linux kernel, the following vulnerability has been resolved:
pNFS: Fix a deadlock when returning a delegation during open()
Ben Coddington reports seeing a hang in the following stack trace:
0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415
1 [ffffd0b50e177548] schedule at ffffffff9ca05717
2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1
3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb
4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5
5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4]
6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4]
7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4]
8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4]
9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4]
10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4]
11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4]
12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4]
13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4]
14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4]
15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4]
16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4]
17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea
18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e
19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935
The issue is that the delegreturn is being asked to wait for a layout
return that cannot complete because a state recovery was initiated. The
state recovery cannot complete until the open() finishes processing the
delegations it was given.
The solution is to propagate the existing flags that indicate a
non-blocking call to the function pnfs_roc(), so that it knows not to
wait in this situation. |
| curl before version 7.52.1 is vulnerable to an uninitialized random in libcurl's internal function that returns a good 32bit random value. Having a weak or virtually non-existent random value makes the operations that use it vulnerable. |
| Quarkus is a Cloud Native, (Linux) Container First framework for writing Java applications. In versions prior to 3.24.1, 3.20.2, and 3.15.6, there is a potential data leak when duplicating a duplicated context. Quarkus extensively uses the Vert.x duplicated context to implement context propagation. With the new semantic data from one transaction can leak to the data from another transaction. From a Vert.x point of view, this new semantic clarifies the behavior. A significant amount of data is stored in the duplicated context, including request scope, security details, and metadata. Duplicating a duplicated context is rather rare and is only done in a few places. This issue has been patched in version 3.24.1, 3.20.2, and 3.15.6. |
| A flaw was found in PCP. The default pmproxy configuration exposes the Redis server backend to the local network, allowing remote command execution with the privileges of the Redis user. This issue can only be exploited when pmproxy is running. By default, pmproxy is not running and needs to be started manually. The pmproxy service is usually started from the 'Metrics settings' page of the Cockpit web interface. This flaw affects PCP versions 4.3.4 and newer. |
| An issue was discovered in Roundcube Webmail 1.6.0 before 1.6.14. Insufficient Cascading Style Sheets (CSS) sanitization in HTML e-mail messages may lead to SSRF or Information Disclosure, e.g., if stylesheet links point to local network hosts. |
| An issue was discovered in Roundcube Webmail before 1.5.15 and 1.6.15. The remote image blocking feature can be bypassed via SVG content in an e-mail message. This may lead to information disclosure or access-control bypass. This involves the animate element with attributeName=fill/filter/stroke. |
| Binding to an unrestricted ip address in Azure IoT SDK allows an unauthorized attacker to disclose information over a network. |
| When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the `CURLOPT_POSTFIELDS` option has been set, if the same handle previously was used to issue a `PUT` request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the subsequent `POST` request. The problem exists in the logic for a reused handle when it is changed from a PUT to a POST. |
| Sensitive data storage in improperly locked memory in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally. |
| Missing Checks in certain functions related to RMP initialization can allow a local admin privileged attacker to cause misidentification of I/O memory, potentially resulting in a loss of guest memory integrity |
| Improper initialization for some ESXi kernel mode driver for the Intel(R) Ethernet 800-Series before version 2.2.2.0 (esxi 8.0) & 2.2.3.0 (esxi 9.0) within Ring 1: Device Drivers may allow an information disclosure. Unprivileged software adversary with an authenticated user combined with a low complexity attack may enable data exposure. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (low), integrity (none) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Frigate is a network video recorder (NVR) with realtime local object detection for IP cameras. Prior to 0.16.4, a critical Remote Command Execution (RCE) vulnerability has been identified in the Frigate integration with go2rtc. The application does not sanitize user input in the video stream configuration (config.yaml), allowing direct injection of system commands via the exec: directive. The go2rtc service executes these commands without restrictions. This vulnerability is only exploitable by an administrator or users who have exposed their Frigate install to the open internet with no authentication which allows anyone full administrative control. This vulnerability is fixed in 0.16.4. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: Rework long task execution when adding/deleting entries
When adding/deleting large number of elements in one step in ipset, it can
take a reasonable amount of time and can result in soft lockup errors. The
patch 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range of
consecutive elements to add/delete") tried to fix it by limiting the max
elements to process at all. However it was not enough, it is still possible
that we get hung tasks. Lowering the limit is not reasonable, so the
approach in this patch is as follows: rely on the method used at resizing
sets and save the state when we reach a smaller internal batch limit,
unlock/lock and proceed from the saved state. Thus we can avoid long
continuous tasks and at the same time removed the limit to add/delete large
number of elements in one step.
The nfnl mutex is held during the whole operation which prevents one to
issue other ipset commands in parallel. |
| In the Linux kernel, the following vulnerability has been resolved:
USB: Gadget: core: Help prevent panic during UVC unconfigure
Avichal Rakesh reported a kernel panic that occurred when the UVC
gadget driver was removed from a gadget's configuration. The panic
involves a somewhat complicated interaction between the kernel driver
and a userspace component (as described in the Link tag below), but
the analysis did make one thing clear: The Gadget core should
accomodate gadget drivers calling usb_gadget_deactivate() as part of
their unbind procedure.
Currently this doesn't work. gadget_unbind_driver() calls
driver->unbind() while holding the udc->connect_lock mutex, and
usb_gadget_deactivate() attempts to acquire that mutex, which will
result in a deadlock.
The simple fix is for gadget_unbind_driver() to release the mutex when
invoking the ->unbind() callback. There is no particular reason for
it to be holding the mutex at that time, and the mutex isn't held
while the ->bind() callback is invoked. So we'll drop the mutex
before performing the unbind callback and reacquire it afterward.
We'll also add a couple of comments to usb_gadget_activate() and
usb_gadget_deactivate(). Because they run in process context they
must not be called from a gadget driver's ->disconnect() callback,
which (according to the kerneldoc for struct usb_gadget_driver in
include/linux/usb/gadget.h) may run in interrupt context. This may
help prevent similar bugs from arising in the future. |
