Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: dce100: skip non-DP stream encoders for DP MST<br /> <br /> On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital<br /> DIG stream encoders plus one analog DAC encoder. When assigning a stream<br /> encoder for a second DisplayPort MST stream, if the preferred digital<br /> encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link()<br /> falls back to the first free pool entry. That entry may be the analog<br /> encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute.<br /> The subsequent atomic commit then dereferences NULL function pointers in<br /> link_set_dpms_on() and crashes.<br /> <br /> Skip encoders without dp_set_stream_attribute when the stream uses a DP<br /> signal (including MST). Use dc_is_dp_signal(stream-&gt;signal) for the MST<br /> fallback path instead of checking only the link connector signal.<br /> <br /> Tested on:<br /> - GPU: AMD Radeon R7 260X (Bonaire / DCE8)<br /> - Board: Supermicro C9X299-PG300<br /> - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot<br /> - Kernel: 7.1.3 (issue observed since 6.19)<br /> - Result: kernel oops without patch; dual monitors stable with patch<br /> <br /> (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cedrus: skip invalid H.264 reference list entries<br /> <br /> Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the<br /> stateless slice control and later uses their indices to look up<br /> decode-&gt;dpb[] in _cedrus_write_ref_list().<br /> <br /> Rejecting such controls in cedrus_try_ctrl() would break existing<br /> userspace, since stateless H.264 reference lists may legitimately carry<br /> out-of-range indices for missing references. Instead, guard the actual<br /> DPB lookup in Cedrus and skip entries whose indices do not fit the fixed<br /> V4L2_H264_NUM_DPB_ENTRIES array.<br /> <br /> This keeps the fix local to the driver use site and avoids out-of-bounds<br /> reads from malformed or unsupported reference list entries.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: airspy: Return queued buffers on start_streaming() failure<br /> <br /> The vb2 framework hands buffers to the driver via buf_queue() before<br /> calling start_streaming(). If start_streaming() returns an error<br /> without first returning those buffers via vb2_buffer_done(),<br /> vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued<br /> buffers leak.<br /> <br /> airspy_start_streaming() returned -ENODEV early when the USB device had<br /> been disconnected (s-&gt;udev == NULL) without returning any buffers that<br /> buf_queue() had already accepted. Take v4l2_lock first and jump to the<br /> existing err_clear_bit label, which already drains s-&gt;queued_bufs via<br /> vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking.<br /> <br /> This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:<br /> Return queued buffers on start_streaming() failure").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix bo-&gt;pin leaking in amdgpu_bo_create_reserved<br /> <br /> amdgpu_bo_create_reserved() only allocates a new BO when<br /> *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is<br /> NULL, it simply skips creation when *bo_ptr is non-NULL.<br /> But it unconditionally reserves, pins, gart allocates<br /> and maps the BO afterwards.<br /> <br /> When the same non-NULL BO pointer is passed in again,<br /> for example firmware buffers that live in adev and are<br /> re-loaded on every resume / cp_resume / start<br /> under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases<br /> pin_count unconditionally, however the matching teardown only unpins<br /> once, so pin_count never drops to zero, so TTM is not able<br /> to move, swap or evict a BO, causing BO leaks.<br /> <br /> This commit fixes this issue by only pinning the bo<br /> once at creation, and repeated calls no longer<br /> take additional pin references.<br /> <br /> (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe<br /> <br /> Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call<br /> v4l2_subdev_init_finalize() which allocates the subdev active state,<br /> but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup()<br /> calls v4l2_subdev_cleanup() to free it.<br /> <br /> This causes a memory leak on every rmmod, reported by kmemleak:<br /> <br /> unreferenced object 0xffff0000d06fc800 (size 192):<br /> comm "(udev-worker)", pid 254, jiffies 4294913455<br /> backtrace (crc 36eeae58):<br /> kmemleak_alloc+0x34/0x40<br /> __kvmalloc_node_noprof+0x5f8/0x7d8<br /> __v4l2_subdev_state_alloc+0x1fc/0x30c<br /> __v4l2_subdev_init_finalize+0x178/0x368<br /> <br /> Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup()<br /> in both crossbar and pipe cleanup paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nuvoton: npcm-video: fix memory leaks in probe and remove<br /> <br /> npcm_video_probe() allocates the npcm_video structure with kzalloc_obj()<br /> but never frees it on any probe error path or in npcm_video_remove(),<br /> leaking the allocation on every failed probe and every normal unbind.<br /> <br /> Additionally, when npcm_video_setup_video() fails, the reserved memory<br /> association established by of_reserved_mem_device_init() in<br /> npcm_video_init() is not released, leaking the rmem_assigned_device<br /> entry on the global list.<br /> <br /> Fix both by adding kfree(video) to all probe error paths and to<br /> npcm_video_remove(), and adding the missing<br /> of_reserved_mem_device_release() call when npcm_video_setup_video()<br /> fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mali-c55: Fix possible ERR_PTR in enable_streams<br /> <br /> The media_pad_remote_pad_unique() function returns either a valid<br /> pointer or an ERR_PTR() on failure (-ENOTUNIQ if multiple links are<br /> enabled, -ENOLINK if no connected pad is found). The return value<br /> was assigned directly to isp-&gt;remote_src and dereferenced in the<br /> next line without checking for errors, which could lead to an<br /> ERR_PTR dereference.<br /> <br /> Add proper error checking with IS_ERR() before dereferencing the<br /> pointer. Also set isp-&gt;remote_src to NULL on error to maintain<br /> consistency with other error paths in the function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: alvium: fix critical pointer access in alvium_ctrl_init<br /> <br /> The current implementation of alvium_ctrl_init creates several controls in<br /> function alvium_ctrl_init and uses the returned pointer without check. That<br /> can cause write access over NULL-pointer for several controls. The reworked<br /> code checks the pointers before adding flags.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: msi2500: Return queued buffers on start_streaming() failure<br /> <br /> The vb2 framework hands buffers to the driver via buf_queue() before<br /> calling start_streaming(). If start_streaming() returns an error<br /> without first returning those buffers via vb2_buffer_done(),<br /> vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued<br /> buffers leak.<br /> <br /> msi2500_start_streaming() had five error paths that all hit this trap<br /> and were further tangled by ret-overwriting between calls:<br /> <br /> - -ENODEV when the USB device was already disconnected<br /> - -ERESTARTSYS when mutex_lock_interruptible() was interrupted<br /> - msi2500_set_usb_adc() failure: ret was silently overwritten by<br /> the next call (msi2500_isoc_init), so the error was lost entirely<br /> - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but<br /> the function then fell through to msi2500_ctrl_msg() and again<br /> masked the original error by overwriting ret<br /> - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all,<br /> leaving isoc URBs submitted with no way for the driver to consume<br /> them<br /> <br /> Consolidate the error paths into a small goto chain. Every failure<br /> now stops the function, drains the queued-buffer list, and returns<br /> the real error code. The ctrl_msg failure path also rolls back the<br /> preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before<br /> unlocking and draining.<br /> <br /> The cleanup helper takes a vb2_buffer_state argument so that the<br /> start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as<br /> expected by userspace on start_streaming failure) while stop_streaming<br /> keeps its existing VB2_BUF_STATE_ERROR semantics.<br /> <br /> This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo:<br /> Return queued buffers on start_streaming() failure").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: meson: vdec: Fix memory leak in error path of vdec_open<br /> <br /> The vdec_open() function previously jumped directly to<br /> err_m2m_release when vdec_init_ctrls() failed, skipping<br /> release of the m2m context. This caused a resource leak.<br /> <br /> Fix it by introducing a proper err_m2m_ctx_release label<br /> that calls v4l2_m2m_ctx_release(sess-&gt;m2m_ctx) before<br /> releasing the m2m device.<br /> <br /> This was identified via kmemleak:<br /> unreferenced object 0xffff0000205d6878 (size 8):<br /> comm "v4l_id", pid 5289, jiffies 4294938580<br /> hex dump (first 8 bytes):<br /> 40 d2 49 18 00 00 ff ff @.I.....<br /> backtrace (crc d3204599):<br /> kmemleak_alloc+0xc8/0xf0<br /> __kvmalloc_node_noprof+0x60c/0x850<br /> v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev]<br /> vdec_open+0x1f4/0x788 [meson_vdec]<br /> v4l2_open+0x144/0x460 [videodev]<br /> chrdev_open+0x1ac/0x500<br /> do_dentry_open+0x3f0/0xfe8<br /> vfs_open+0x68/0x320<br /> do_open+0x2d8/0x9a8<br /> path_openat+0x1d0/0x4f0<br /> do_filp_open+0x190/0x380<br /> do_sys_openat2+0xf8/0x1b0<br /> __arm64_sys_openat+0x13c/0x1e8<br /> invoke_syscall+0xdc/0x268<br /> el0_svc_common.constprop.0+0x178/0x258<br /> do_el0_svc+0x4c/0x70

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx23885: add ioremap return check and cleanup<br /> <br /> Add a check for the return value of pci_ioremap_bar()<br /> in cx23885_dev_setup().<br /> If ioremap for BAR0 fails, release the already allocated<br /> PCI memory region,<br /> decrement the device count, and return -ENODEV.<br /> <br /> This prevents a potential null pointer dereference and<br /> ensures proper cleanup<br /> on memory mapping failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx231xx: fix devres lifetime<br /> <br /> USB drivers bind to USB interfaces and any device managed resources<br /> should have their lifetime tied to the interface rather than parent USB<br /> device. This avoids issues like memory leaks when drivers are unbound<br /> without their devices being physically disconnected (e.g. on probe<br /> deferral or configuration changes).<br /> <br /> Fix the driver state lifetime so that it is released on driver unbind.