CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50177 – drm/amd/display: fix a UBSAN warning in DML2.1
https://notcve.org/view.php?id=CVE-2024-50177
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] <TASK> [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? • https://git.kernel.org/stable/c/27bc3da5eae57e3af8f5648b4498ffde48781434 https://git.kernel.org/stable/c/eaf3adb8faab611ba57594fa915893fc93a7788c •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50176 – remoteproc: k3-r5: Fix error handling when power-up failed
https://notcve.org/view.php?id=CVE-2024-50176
In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance. • https://git.kernel.org/stable/c/2a1ec20b174c0f613224c59e694639ac07308b53 https://git.kernel.org/stable/c/2494bc856e7ce50b1c4fd8afb4d17f2693f36565 https://git.kernel.org/stable/c/61f6f68447aba08aeaa97593af3a7d85a114891f https://git.kernel.org/stable/c/8ae2a10f5c7010ac82ab015cf864199093d61a7d https://git.kernel.org/stable/c/87ab3af7447791d0c619610fd560bd804549e187 https://git.kernel.org/stable/c/fc71c23958931713b5e76f317b76be37189f2516 https://git.kernel.org/stable/c/afd102bde99d90ef41e043c846ea34b04433eb7b https://git.kernel.org/stable/c/7afb5e3aa989c479979faeb18768a6788 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50175 – media: qcom: camss: Remove use_count guard in stop_streaming
https://notcve.org/view.php?id=CVE-2024-50175
In the Linux kernel, the following vulnerability has been resolved: media: qcom: camss: Remove use_count guard in stop_streaming The use_count check was introduced so that multiple concurrent Raw Data Interfaces RDIs could be driven by different virtual channels VCs on the CSIPHY input driving the video pipeline. This is an invalid use of use_count though as use_count pertains to the number of times a video entity has been opened by user-space not the number of active streams. If use_count and stream-on count don't agree then stop_streaming() will break as is currently the case and has become apparent when using CAMSS with libcamera's released softisp 0.3. The use of use_count like this is a bit hacky and right now breaks regular usage of CAMSS for a single stream case. Stopping qcam results in the splat below, and then it cannot be started again and any attempts to do so fails with -EBUSY. [ 1265.509831] WARNING: CPU: 5 PID: 919 at drivers/media/common/videobuf2/videobuf2-core.c:2183 __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common] ... [ 1265.510630] Call trace: [ 1265.510636] __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common] [ 1265.510648] vb2_core_streamoff+0x24/0xcc [videobuf2_common] [ 1265.510660] vb2_ioctl_streamoff+0x5c/0xa8 [videobuf2_v4l2] [ 1265.510673] v4l_streamoff+0x24/0x30 [videodev] [ 1265.510707] __video_do_ioctl+0x190/0x3f4 [videodev] [ 1265.510732] video_usercopy+0x304/0x8c4 [videodev] [ 1265.510757] video_ioctl2+0x18/0x34 [videodev] [ 1265.510782] v4l2_ioctl+0x40/0x60 [videodev] ... [ 1265.510944] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 0 in active state [ 1265.511175] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 1 in active state [ 1265.511398] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 2 in active st One CAMSS specific way to handle multiple VCs on the same RDI might be: - Reference count each pipeline enable for CSIPHY, CSID, VFE and RDIx. - The video buffers are already associated with msm_vfeN_rdiX so release video buffers when told to do so by stop_streaming. - Only release the power-domains for the CSIPHY, CSID and VFE when their internal refcounts drop. Either way refusing to release video buffers based on use_count is erroneous and should be reverted. The silicon enabling code for selecting VCs is perfectly fine. Its a "known missing feature" that concurrent VCs won't work with CAMSS right now. Initial testing with this code didn't show an error but, SoftISP and "real" usage with Google Hangouts breaks the upstream code pretty quickly, we need to do a partial revert and take another pass at VCs. This commit partially reverts commit 89013969e232 ("media: camss: sm8250: Pipeline starting and stopping for multiple virtual channels") • https://git.kernel.org/stable/c/89013969e23247661f0514c77f26d60fa083216c https://git.kernel.org/stable/c/c2218a82f795dc3d0b6210bcaa3d9c5ca736fcd9 https://git.kernel.org/stable/c/a975db8aea152f9907aa53a7f517e557ccb40da3 https://git.kernel.org/stable/c/d7d4dde3decef1b5aa1f5c390147f79aae412dee https://git.kernel.org/stable/c/25f18cb1b673220b76a86ebef8e7fb79bd303b27 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50174 – drm/panthor: Fix race when converting group handle to group object
https://notcve.org/view.php?id=CVE-2024-50174
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase(). • https://git.kernel.org/stable/c/de85488138247d034eb3241840424a54d660926b https://git.kernel.org/stable/c/8a585d553c11965332d7a2d74e79ef92a42bfc87 https://git.kernel.org/stable/c/44742138d151c3a945460ae7beff8ae45ac0bf58 https://git.kernel.org/stable/c/cac075706f298948898b1f63e81709df42afa75d •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50173 – drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup()
https://notcve.org/view.php?id=CVE-2024-50173
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead. • https://git.kernel.org/stable/c/d72f049087d4f973f6332b599c92177e718107de https://git.kernel.org/stable/c/ac2ca5e5148a0d4d78ac01c2d8348d0757c7367f https://git.kernel.org/stable/c/3bde05794497d5f426d4ea2ecb9868bf7721fb24 https://git.kernel.org/stable/c/282864cc5d3f144af0cdea1868ee2dc2c5110f0d •