| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Fix PM related deadlocks in MS IOCTLs
Prevent runtime resume/suspend while MS IOCTLs are in progress.
Failed suspend will call ivpu_ms_cleanup() that would try to acquire
file_priv->ms_lock, which is already held by the IOCTLs. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: omapfb: Add 'plane' value check
Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.
The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.
For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.
For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.
Add check for this value.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: pciehp: Avoid unnecessary device replacement check
Hot-removal of nested PCI hotplug ports suffers from a long-standing race
condition which can lead to a deadlock: A parent hotplug port acquires
pci_lock_rescan_remove(), then waits for pciehp to unbind from a child
hotplug port. Meanwhile that child hotplug port tries to acquire
pci_lock_rescan_remove() as well in order to remove its own children.
The deadlock only occurs if the parent acquires pci_lock_rescan_remove()
first, not if the child happens to acquire it first.
Several workarounds to avoid the issue have been proposed and discarded
over the years, e.g.:
https://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/
A proper fix is being worked on, but needs more time as it is nontrivial
and necessarily intrusive.
Recent commit 9d573d19547b ("PCI: pciehp: Detect device replacement during
system sleep") provokes more frequent occurrence of the deadlock when
removing more than one Thunderbolt device during system sleep. The commit
sought to detect device replacement, but also triggered on device removal.
Differentiating reliably between replacement and removal is impossible
because pci_get_dsn() returns 0 both if the device was removed, as well as
if it was replaced with one lacking a Device Serial Number.
Avoid the more frequent occurrence of the deadlock by checking whether the
hotplug port itself was hot-removed. If so, there's no sense in checking
whether its child device was replaced.
This works because the ->resume_noirq() callback is invoked in top-down
order for the entire hierarchy: A parent hotplug port detecting device
replacement (or removal) marks all children as removed using
pci_dev_set_disconnected() and a child hotplug port can then reliably
detect being removed. |
| Inappropriate implementation in Lens in Google Chrome on iOS prior to 136.0.7103.59 allowed a remote attacker to perform UI spoofing via a crafted QR code. (Chromium security severity: Low) |
| An unauthenticated attacker can obtain a user's plant list by knowing the username. |
| An unauthenticated attacker can check the existence of usernames in the system by querying an API. |
| An unauthenticated attacker can obtain a list of smart devices by knowing a valid username. |
| An authenticated attacker can obtain any plant name by knowing the plant ID. |
| Unauthenticated attackers can add devices of other users to their scenes (or arbitrary scenes of other arbitrary users). |
| An attacker can export other users' plant information. |
| An unauthenticated attacker can hijack other users' devices and potentially control them. |
| Unauthenticated attackers can rename arbitrary devices of arbitrary users (i.e., EV chargers). |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq
storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it
doesn't need to make forward progress under memory pressure. Marking this
workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a
non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following
warning:
[ 14.506347] ------------[ cut here ]------------
[ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn
[ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130
[ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu
[ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun
[ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130
<-snip->
[ 14.506408] Call Trace:
[ 14.506412] __flush_work+0xf1/0x1c0
[ 14.506414] __cancel_work_timer+0x12f/0x1b0
[ 14.506417] ? kernfs_put+0xf0/0x190
[ 14.506418] cancel_delayed_work_sync+0x13/0x20
[ 14.506420] disk_block_events+0x78/0x80
[ 14.506421] del_gendisk+0x3d/0x2f0
[ 14.506423] sr_remove+0x28/0x70
[ 14.506427] device_release_driver_internal+0xef/0x1c0
[ 14.506428] device_release_driver+0x12/0x20
[ 14.506429] bus_remove_device+0xe1/0x150
[ 14.506431] device_del+0x167/0x380
[ 14.506432] __scsi_remove_device+0x11d/0x150
[ 14.506433] scsi_remove_device+0x26/0x40
[ 14.506434] storvsc_remove_lun+0x40/0x60
[ 14.506436] process_one_work+0x209/0x400
[ 14.506437] worker_thread+0x34/0x400
[ 14.506439] kthread+0x121/0x140
[ 14.506440] ? process_one_work+0x400/0x400
[ 14.506441] ? kthread_park+0x90/0x90
[ 14.506443] ret_from_fork+0x35/0x40
[ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]--- |
| Unauthenticated attackers can rename "rooms" of arbitrary users. |
| An unauthenticated attacker can delete any user's "rooms" by knowing the user's and room IDs. |
| An unauthenticated attacker can obtain EV charger version and firmware upgrading history by knowing the charger ID. |
| Unauthenticated attackers can query an API endpoint and get device details. |
| An unauthenticated attackers can obtain a list of smart devices by knowing a valid username through an unprotected API. |
| Unauthenticated attackers can retrieve full list of users associated with arbitrary accounts. |
| Unauthenticated attackers can retrieve serial number of smart meters associated to a specific user account. |
