CVE-2024-50175 is a vulnerability identified in the Linux kernel's media subsystem, specifically within the Qualcomm Camera Subsystem (CAMSS) driver. The issue arises from an improper use of the use_count variable in the stop_streaming() function. The use_count was originally intended to track the number of times a video entity has been opened by user-space applications, but it was incorrectly used to manage the number of active video streams. This misuse leads to a mismatch between use_count and the actual stream-on count, causing stop_streaming() to malfunction. The consequence is that when stopping the camera streaming, the driver leaves video buffers in an active state and fails to release resources properly. This results in the inability to restart the camera stream, with subsequent attempts failing with an -EBUSY (device busy) error. The problem is particularly evident when using CAMSS with libcamera's SoftISP 0.3 and has been observed to break real-world applications like Google Hangouts. The root cause is the erroneous refusal to release video buffers based on use_count, which should be reverted. The vulnerability stems from a partial revert of a previous commit that attempted to support multiple virtual channels (VCs) on the same Raw Data Interface (RDI). The fix involves implementing proper reference counting for pipeline components (CSIPHY, CSID, VFE, and RDIx) and ensuring video buffers are released correctly when stop_streaming is called. This vulnerability does not appear to be exploitable for remote code execution or privilege escalation but causes denial of service (DoS) by rendering camera streaming unusable until a system reboot or driver reload. No known exploits are reported in the wild, and no CVSS score has been assigned yet.

For European organizations, this vulnerability primarily impacts systems relying on the affected Linux kernel versions with Qualcomm CAMSS drivers, particularly those using video capture or streaming functionalities such as in embedded devices, IoT, mobile devices, or video conferencing systems. The inability to stop and restart camera streams can cause service disruptions in critical applications like remote collaboration tools, telemedicine, security surveillance, and multimedia processing. Organizations using video conferencing platforms that depend on libcamera or similar frameworks on Linux devices may experience degraded user experience or complete failure of video input. This can lead to operational downtime, reduced productivity, and potential loss of business continuity. While the vulnerability does not directly compromise confidentiality or integrity, the denial of service effect can indirectly affect availability of services. Additionally, embedded systems in industrial or automotive sectors using Qualcomm camera pipelines could face operational issues, impacting safety or monitoring capabilities. The impact is more pronounced in environments where Linux-based video capture is integral to business processes or security monitoring.

To mitigate this vulnerability, European organizations should: 1) Apply the latest Linux kernel patches that revert the improper use_count handling in the CAMSS driver as soon as they become available from trusted sources or Linux distributions. 2) Where immediate patching is not feasible, consider disabling or avoiding the use of multiple virtual channels on the same RDI in CAMSS to prevent triggering the faulty stop_streaming behavior. 3) Monitor system logs for warnings related to videobuf2_common and stop_streaming failures to detect potential impact. 4) For critical systems, implement fallback mechanisms such as restarting the affected video service or the entire system to recover from the busy state. 5) Engage with hardware and software vendors to confirm updated driver support and compatibility with patched kernels. 6) Test video streaming workflows thoroughly after patching to ensure stability, especially in applications relying on libcamera and SoftISP. 7) Maintain inventory of devices using Qualcomm CAMSS drivers and prioritize patching based on criticality. These steps go beyond generic advice by focusing on the specific driver and pipeline components affected and emphasizing operational monitoring and vendor coordination.