| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware()
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
media: venus: core: Fix some resource leaks in the error path of 'venus_probe()'
If an error occurs after a successful 'of_icc_get()' call, it must be
undone.
Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak.
Update the remove function accordingly and axe the now unneeded
'icc_put()' calls. |
| In the Linux kernel, the following vulnerability has been resolved:
hfsplus: prevent corruption in shrinking truncate
I believe there are some issues introduced by commit 31651c607151
("hfsplus: avoid deadlock on file truncation")
HFS+ has extent records which always contains 8 extents. In case the
first extent record in catalog file gets full, new ones are allocated from
extents overflow file.
In case shrinking truncate happens to middle of an extent record which
locates in extents overflow file, the logic in hfsplus_file_truncate() was
changed so that call to hfs_brec_remove() is not guarded any more.
Right action would be just freeing the extents that exceed the new size
inside extent record by calling hfsplus_free_extents(), and then check if
the whole extent record should be removed. However since the guard
(blk_cnt > start) is now after the call to hfs_brec_remove(), this has
unfortunate effect that the last matching extent record is removed
unconditionally.
To reproduce this issue, create a file which has at least 10 extents, and
then perform shrinking truncate into middle of the last extent record, so
that the number of remaining extents is not under or divisible by 8. This
causes the last extent record (8 extents) to be removed totally instead of
truncating into middle of it. Thus this causes corruption, and lost data.
Fix for this is simply checking if the new truncated end is below the
start of this extent record, making it safe to remove the full extent
record. However call to hfs_brec_remove() can't be moved to it's previous
place since we're dropping ->tree_lock and it can cause a race condition
and the cached info being invalidated possibly corrupting the node data.
Another issue is related to this one. When entering into the block
(blk_cnt > start) we are not holding the ->tree_lock. We break out from
the loop not holding the lock, but hfs_find_exit() does unlock it. Not
sure if it's possible for someone else to take the lock under our feet,
but it can cause hard to debug errors and premature unlocking. Even if
there's no real risk of it, the locking should still always be kept in
balance. Thus taking the lock now just before the check. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: uniphier-sd: Fix a resource leak in the remove function
A 'tmio_mmc_host_free()' call is missing in the remove function, in order
to balance a 'tmio_mmc_host_alloc()' call in the probe.
This is done in the error handling path of the probe, but not in the remove
function.
Add the missing call. |
| In the Linux kernel, the following vulnerability has been resolved:
ixgbe: fix unbalanced device enable/disable in suspend/resume
pci_disable_device() called in __ixgbe_shutdown() decreases
dev->enable_cnt by 1. pci_enable_device_mem() which increases
dev->enable_cnt by 1, was removed from ixgbe_resume() in commit
6f82b2558735 ("ixgbe: use generic power management"). This caused
unbalanced increase/decrease. So add pci_enable_device_mem() back.
Fix the following call trace.
ixgbe 0000:17:00.1: disabling already-disabled device
Call Trace:
__ixgbe_shutdown+0x10a/0x1e0 [ixgbe]
ixgbe_suspend+0x32/0x70 [ixgbe]
pci_pm_suspend+0x87/0x160
? pci_pm_freeze+0xd0/0xd0
dpm_run_callback+0x42/0x170
__device_suspend+0x114/0x460
async_suspend+0x1f/0xa0
async_run_entry_fn+0x3c/0xf0
process_one_work+0x1dd/0x410
worker_thread+0x34/0x3f0
? cancel_delayed_work+0x90/0x90
kthread+0x14c/0x170
? kthread_park+0x90/0x90
ret_from_fork+0x1f/0x30 |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: cadence: fix reference leak when pm_runtime_get_sync fails
The PM reference count is not expected to be incremented on
return in functions cdns_i2c_master_xfer and cdns_reg_slave.
However, pm_runtime_get_sync will increment pm usage counter
even failed. Forgetting to putting operation will result in a
reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: img-scb: fix reference leak when pm_runtime_get_sync fails
The PM reference count is not expected to be incremented on
return in functions img_i2c_xfer and img_i2c_init.
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails
The PM reference count is not expected to be incremented on
return in lpi2c_imx_master_enable.
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: imx: fix reference leak when pm_runtime_get_sync fails
In i2c_imx_xfer() and i2c_imx_remove(), the pm reference count
is not expected to be incremented on return.
However, pm_runtime_get_sync will increment pm reference count
even failed. Forgetting to putting operation will result in a
reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: sprd: fix reference leak when pm_runtime_get_sync fails
The PM reference count is not expected to be incremented on
return in sprd_i2c_master_xfer() and sprd_i2c_remove().
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: stm32f7: fix reference leak when pm_runtime_get_sync fails
The PM reference count is not expected to be incremented on
return in these stm32f7_i2c_xx serious functions.
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
i2c: xiic: fix reference leak when pm_runtime_get_sync fails
The PM reference count is not expected to be incremented on
return in xiic_xfer and xiic_i2c_remove.
However, pm_runtime_get_sync will increment the PM reference
count even failed. Forgetting to putting operation will result
in a reference leak here.
Replace it with pm_runtime_resume_and_get to keep usage
counter balanced. |
| Microsoft Defender for IoT Elevation of Privilege Vulnerability |
| Microsoft Defender for IoT Elevation of Privilege Vulnerability |
|
Broken access controls on PDFtron WebviewerUI in M-Files Hubshare before 3.3.11.3 allows unauthenticated attackers to upload malicious files to the application server.
|
| Mahara 21.04 before 21.04.7, 21.10 before 21.10.5, 22.04 before 22.04.3, and 22.10 before 22.10.0 potentially allow a PDF export to trigger a remote shell if the site is running on Ubuntu and the flag -dSAFER is not set with Ghostscript. |
| In Mahara 21.04 before 21.04.7, 21.10 before 21.10.5, 22.04 before 22.04.3, and 22.10 before 22.10.0, embedded images are accessible without a sufficient permission check under certain conditions. |
| Incorrect access control in the anti-virus driver wsdkd.sys of Watchdog Antivirus v1.4.158 allows attackers to write arbitrary files. |
| TCP, when using a large Window Size, makes it easier for remote attackers to guess sequence numbers and cause a denial of service (connection loss) to persistent TCP connections by repeatedly injecting a TCP RST packet, especially in protocols that use long-lived connections, such as BGP. |
| A vulnerability has been identified in Mendix Runtime V7 (All versions < V7.23.29), Mendix Runtime V8 (All versions < V8.18.16), Mendix Runtime V9 (All versions < V9.13 only with Runtime Custom Setting *DataStorage.UseNewQueryHandler* set to False). If an entity has an association readable by the user, then in some cases, Mendix Runtime may not apply checks for XPath constraints that parse said associations, within apps running on affected versions. A malicious user could use this to dump and manipulate sensitive data. |
