| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
media: meson: vdec: Fix memory leak in error path of vdec_open
The vdec_open() function previously jumped directly to
err_m2m_release when vdec_init_ctrls() failed, skipping
release of the m2m context. This caused a resource leak.
Fix it by introducing a proper err_m2m_ctx_release label
that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before
releasing the m2m device.
This was identified via kmemleak:
unreferenced object 0xffff0000205d6878 (size 8):
comm "v4l_id", pid 5289, jiffies 4294938580
hex dump (first 8 bytes):
40 d2 49 18 00 00 ff ff @.I.....
backtrace (crc d3204599):
kmemleak_alloc+0xc8/0xf0
__kvmalloc_node_noprof+0x60c/0x850
v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev]
vdec_open+0x1f4/0x788 [meson_vdec]
v4l2_open+0x144/0x460 [videodev]
chrdev_open+0x1ac/0x500
do_dentry_open+0x3f0/0xfe8
vfs_open+0x68/0x320
do_open+0x2d8/0x9a8
path_openat+0x1d0/0x4f0
do_filp_open+0x190/0x380
do_sys_openat2+0xf8/0x1b0
__arm64_sys_openat+0x13c/0x1e8
invoke_syscall+0xdc/0x268
el0_svc_common.constprop.0+0x178/0x258
do_el0_svc+0x4c/0x70 |
| In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Shut down BO cache timer before teardown
The BO cache timer callback schedules time_work, and time_work can rearm
the timer through vc4_bo_cache_free_old().
vc4_bo_cache_destroy() deletes the timer and then cancels the work, which
does not break that cycle: the work being cancelled can rearm the timer,
and the timer then queues work again after teardown.
Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the
cycle ends with cancel_work_sync(). |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/userq: fix indefinite fence wait during GPU reset
pre_reset only force-completes fences of MAPPED queues. A queue in any
other state (e.g. mid-eviction) keeps its last_fence pending; after a
GPU reset that fence never signals, so the eviction/suspend worker and
process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and
wedge the machine:
INFO: task kworker/6:28 blocked for more than 120 seconds.
Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu]
Call Trace:
dma_fence_wait_timeout+0x7e/0x130
amdgpu_userq_evict+0x67/0x140 [amdgpu]
amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu]
process_scheduled_works+0xa6/0x420
Force-complete every queue's fence regardless of state. The unmap and
mark-hung step stays gated on MAPPED, since unmapping a queue that is
not mapped is invalid.
(cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Release VFCT ACPI table reference
amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table()
but never releases it. acpi_get_table() takes a reference on the
table (incrementing its validation_count and mapping it on the 0->1
transition); without a paired acpi_put_table() the mapping is leaked
on every call, whether or not a matching VBIOS image is found.
Route all exit paths after the table is acquired through a common
acpi_put_table(). The VBIOS image is copied out with kmemdup() before
the table is released, so it remains valid for the caller.
(cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d) |
| In the Linux kernel, the following vulnerability has been resolved:
media: stm32-dcmipp: Return queued buffers on start_streaming() failure
The vb2 framework hands buffers to the driver via buf_queue() before
calling start_streaming(). If start_streaming() returns an error
without first returning those buffers via vb2_buffer_done(),
vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued
buffers leak.
dcmipp_bytecap_start_streaming() returned -EINVAL when the source
subdevice could not be resolved from the media graph, before
pm_runtime_resume_and_get() and media_pipeline_start() had been called.
The remaining error paths already converge on the err_buffer_done
label, which calls dcmipp_bytecap_all_buffers_done(...,
VB2_BUF_STATE_QUEUED). Jump to that label directly: the intermediate
err_pm_put / err_media_pipeline_stop labels are skipped, which is
correct because nothing they would undo has happened yet.
This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:
Return queued buffers on start_streaming() failure"). |
| In the Linux kernel, the following vulnerability has been resolved:
media: saa7134: Fix a possible memory leak in saa7134_video_init1
In saa7134_video_init1(), the return value of the first
saa7134_pgtable_alloc() is not checked. If it fails, the function
continues as if successful, leaving the driver with an invalid page
table. Additionally, if vb2_queue_init() for the VBI queue fails after
the video queue page table has been allocated, the allocated memory is
not freed before returning. The second saa7134_pgtable_alloc() also
lacks a return value check. Errors occur during device probing before
the device is fully registered, the normal cleanup path in
saa7134_finidev() is not executed, leading to memory leaks and
potential use of uninitialized DMA resources.
Check the return value of both saa7134_pgtable_alloc() calls and
propagate errors. On failure of any later step, free allocated page
tables to avoid memory leaks. Ensure control handlers are also
released on error to prevent further resource leakage.
Found by code review. |
| In the Linux kernel, the following vulnerability has been resolved:
media: radio-si476x: Unregister v4l2_device on probe failure
si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2
controls and before registering the video device. If any of those later
steps fails, probe returns through the exit label after freeing only the
control handler.
A failed probe does not call si476x_radio_remove(), so the
v4l2_device_unregister() there is not reached. This leaves the parent
device reference taken by v4l2_device_register() behind on the error path.
Unregister the V4L2 device in the probe error path after freeing the
controls. |
| In the Linux kernel, the following vulnerability has been resolved:
media: pwc: Drain fill_buf on start_streaming() failure
pwc_isoc_init() submits its isochronous URBs with
usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is
submitted, its completion handler pwc_isoc_handler() can run on another
CPU before the loop finishes:
start_streaming()
pwc_isoc_init()
usb_submit_urb(urbs[0], GFP_KERNEL)
pwc_isoc_handler(urbs[0])
pdev->fill_buf =
pwc_get_next_fill_buf(pdev)
usb_submit_urb(urbs[i>0], ..) -> fails
pwc_isoc_cleanup(pdev) /* kills URBs */
return ret;
pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED)
pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and
stores it in pdev->fill_buf. The error path in start_streaming() only
drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is
leaked. vb2_start_streaming() then triggers
WARN_ON(owned_by_drv_count).
stop_streaming() already handles this since commit 80b0963e1698
("[media] pwc: fix WARN_ON"), which added the fill_buf drain in the
teardown path but not in the start_streaming() error path. Mirror that
handling on failure so start_streaming() returns with no buffer owned
by the driver.
Issue identified by automated review of the INV-003 series at
https://sashiko.dev/ |
| In the Linux kernel, the following vulnerability has been resolved:
media: cx231xx: fix devres lifetime
USB drivers bind to USB interfaces and any device managed resources
should have their lifetime tied to the interface rather than parent USB
device. This avoids issues like memory leaks when drivers are unbound
without their devices being physically disconnected (e.g. on probe
deferral or configuration changes).
Fix the driver state lifetime so that it is released on driver unbind. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved
amdgpu_bo_create_reserved() only allocates a new BO when
*bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is
NULL, it simply skips creation when *bo_ptr is non-NULL.
But it unconditionally reserves, pins, gart allocates
and maps the BO afterwards.
When the same non-NULL BO pointer is passed in again,
for example firmware buffers that live in adev and are
re-loaded on every resume / cp_resume / start
under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases
pin_count unconditionally, however the matching teardown only unpins
once, so pin_count never drops to zero, so TTM is not able
to move, swap or evict a BO, causing BO leaks.
This commit fixes this issue by only pinning the bo
once at creation, and repeated calls no longer
take additional pin references.
(cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON()
There's no need to crash the kernel for these cases.
(cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44) |
| In the Linux kernel, the following vulnerability has been resolved:
drm/i915/vrr: require valid min/max vfreq for VRR
Ensure the EDID provided min/max vfreq are valid. Most scenarios are
already covered (by coincidence) through the checks in
intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit
about it. At worst, a zero min_vfreq could lead to a division by zero in
intel_vrr_compute_vmax().
Discovered using AI-assisted static analysis confirmed by Intel Product
Security.
(cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6) |
| is affected by a Cross-site Scripting (XSS) vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. The vulnerable component is restricted to an administrative network zone by default. Exploitation of this issue requires user interaction in that a victim must open a malicious file. Scope is changed. |
| Heap-based buffer overflow in Microsoft Office allows an unauthorized attacker to execute code locally. |
| In the Linux kernel, the following vulnerability has been resolved:
ice: prevent tstamp ring allocation for non-PF VSI types
The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest
TxTime First) offload enabled. This bitmap is indexed by queue number
and is set by ice_offload_txtime(), which only operates on PF VSI
queues.
However, ice_is_txtime_ena() does not check the VSI type before
consulting the bitmap. When ETF offload is enabled on PF Tx queue 0,
bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset
rebuild, the CTRL VSI's Tx queue 0 is reconfigured and
ice_is_txtime_ena() is called for that ring. Since it only checks
pf->txtime_txqs by queue index without distinguishing VSI type, it
finds bit 0 set and returns true, matching the PF VSI's ETF queue,
not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously
allocate a tstamp_ring for the CTRL VSI ring.
Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring()
takes an early return at the !netdev check before reaching
ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset
leaks one 64-byte tstamp_ring.
Fix this by restricting ice_is_txtime_ena() to return true only for
PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues. |
| Use after Free in the annotator function of Zoom Clients may allow a meeting participant to achieve remote code execution of another participant via network access. |
| An issue in usememos v0.27.1 allows a remote attacker to achieve account takeover via the ssoCredentials branch of the SignIn handler in server/router/api/v1/auth_service.go, because SSO identity is matched only on an attacker-controllable identifier without binding to the IdP's stable subject claim. |
