CVE-2024-50175

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: qcom: camss: Remove use_count guard in stop_streaming<br /> <br /> The use_count check was introduced so that multiple concurrent Raw Data<br /> Interfaces RDIs could be driven by different virtual channels VCs on the<br /> CSIPHY input driving the video pipeline.<br /> <br /> This is an invalid use of use_count though as use_count pertains to the<br /> number of times a video entity has been opened by user-space not the number<br /> of active streams.<br /> <br /> If use_count and stream-on count don&amp;#39;t agree then stop_streaming() will<br /> break as is currently the case and has become apparent when using CAMSS<br /> with libcamera&amp;#39;s released softisp 0.3.<br /> <br /> The use of use_count like this is a bit hacky and right now breaks regular<br /> usage of CAMSS for a single stream case. Stopping qcam results in the splat<br /> below, and then it cannot be started again and any attempts to do so fails<br /> with -EBUSY.<br /> <br /> [ 1265.509831] WARNING: CPU: 5 PID: 919 at drivers/media/common/videobuf2/videobuf2-core.c:2183 __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common]<br /> ...<br /> [ 1265.510630] Call trace:<br /> [ 1265.510636] __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common]<br /> [ 1265.510648] vb2_core_streamoff+0x24/0xcc [videobuf2_common]<br /> [ 1265.510660] vb2_ioctl_streamoff+0x5c/0xa8 [videobuf2_v4l2]<br /> [ 1265.510673] v4l_streamoff+0x24/0x30 [videodev]<br /> [ 1265.510707] __video_do_ioctl+0x190/0x3f4 [videodev]<br /> [ 1265.510732] video_usercopy+0x304/0x8c4 [videodev]<br /> [ 1265.510757] video_ioctl2+0x18/0x34 [videodev]<br /> [ 1265.510782] v4l2_ioctl+0x40/0x60 [videodev]<br /> ...<br /> [ 1265.510944] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 0 in active state<br /> [ 1265.511175] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 1 in active state<br /> [ 1265.511398] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 2 in active st<br /> <br /> One CAMSS specific way to handle multiple VCs on the same RDI might be:<br /> <br /> - Reference count each pipeline enable for CSIPHY, CSID, VFE and RDIx.<br /> - The video buffers are already associated with msm_vfeN_rdiX so<br /> release video buffers when told to do so by stop_streaming.<br /> - Only release the power-domains for the CSIPHY, CSID and VFE when<br /> their internal refcounts drop.<br /> <br /> Either way refusing to release video buffers based on use_count is<br /> erroneous and should be reverted. The silicon enabling code for selecting<br /> VCs is perfectly fine. Its a "known missing feature" that concurrent VCs<br /> won&amp;#39;t work with CAMSS right now.<br /> <br /> Initial testing with this code didn&amp;#39;t show an error but, SoftISP and "real"<br /> usage with Google Hangouts breaks the upstream code pretty quickly, we need<br /> to do a partial revert and take another pass at VCs.<br /> <br /> This commit partially reverts commit 89013969e232 ("media: camss: sm8250:<br /> Pipeline starting and stopping for multiple virtual channels")