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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50172 – RDMA/bnxt_re: Fix a possible memory leak
https://notcve.org/view.php?id=CVE-2024-50172
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a possible memory leak In bnxt_re_setup_chip_ctx() when bnxt_qplib_map_db_bar() fails driver is not freeing the memory allocated for "rdev->chip_ctx". En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/bnxt_re: Se corrige una posible pérdida de memoria En bnxt_re_setup_chip_ctx() cuando bnxt_qplib_map_db_bar() falla, el controlador no libera la memoria asignada para "rdev->chip_ctx". • https://git.kernel.org/stable/c/0ac20faf5d837b59fb4c041ea320932ed47fd67f https://git.kernel.org/stable/c/73e04a6114e08b5eb10e589e12b680955accb376 https://git.kernel.org/stable/c/595fa9b17201028d35f92d450fc0ecda873fe469 https://git.kernel.org/stable/c/3fc5410f225d1651580a4aeb7c72f55e28673b53 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50171 – net: systemport: fix potential memory leak in bcm_sysport_xmit()
https://notcve.org/view.php?id=CVE-2024-50171
In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcm_sysport_xmit() The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: systemport: corrige una posible pérdida de memoria en bcm_sysport_xmit(). Bcm_sysport_xmit() devuelve NETDEV_TX_OK sin liberar skb en caso de que dma_map_single() falle. Agregue dev_kfree_skb() para solucionarlo. • https://git.kernel.org/stable/c/80105befdb4b8cea924711b40b2462b87df65b62 https://git.kernel.org/stable/c/8e81ce7d0166a2249deb6d5e42f28a8b8c9ea72f https://git.kernel.org/stable/c/31701ef0c4547973991ff63596c927f841dfd133 https://git.kernel.org/stable/c/b6321146773dcbbc372a54dbada67e0b50e0a25c https://git.kernel.org/stable/c/5febfc545389805ce83d37f9f4317055b26dd7d7 https://git.kernel.org/stable/c/533d2f30aef272dade17870a509521c3afc38a03 https://git.kernel.org/stable/c/4b70478b984af3c9d0279c121df5ff94e2533dbd https://git.kernel.org/stable/c/7d5030a819c3589cf9948b1eee397b626 •