CVE-2024-50175: media: qcom: camss: Remove use_count guard in stop_streaming
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")
Security readout for executives and security teams
Plain-English summary
A Linux camera-driver bug can leave camera buffers active when streaming stops on systems using Qualcomm CAMSS. Normal camera applications may trigger kernel warnings and leave the camera unavailable with EBUSY until recovery. The supplied CVSS score is 7.8, but practical exposure depends on affected kernel code and Qualcomm camera hardware being present.
Executive priority
Prioritize affected Qualcomm camera devices, especially production endpoints where camera availability or kernel stability matters. Patch through normal kernel maintenance promptly. Broader emergency action is not supported because exposure is hardware-specific and the supplied evidence does not show active exploitation.
Technical view
CAMSS stop_streaming() incorrectly used a video entity use_count as an active-stream count. When open and streaming counts diverged, buffer release was skipped, violating videobuf2 requirements and leaving buffers active. The resolution removes that guard, partially reverting the earlier multiple-virtual-channel change. Reported triggers include libcamera SoftISP, qcam, and Google Hangouts use.
Likely exposure
Exposure is concentrated in Linux devices running the affected CAMSS code with supported Qualcomm camera hardware. The bundle lists affected versions including 6.4, 6.6.55, 6.10.14, 6.11.3, and 6.12, but its version data is ambiguous; verify each vendor kernel by commit ancestry.
Exploitation context
The CVSS vector describes local, low-complexity access requiring low privileges and no user interaction. The supplied sources document failures during ordinary camera streaming, not malicious exploitation. This CVE is not listed as KEV in the bundle, and no cited source establishes active exploitation.
Researcher notes
The strongest evidence is a stream teardown state-management flaw: use_count tracks user-space opens, not active streams. The source reports WARN splats, unreleased videobuf2 buffers, and persistent EBUSY behavior. No CWE is assigned. Confidentiality and integrity impacts implied by CVSS are not independently demonstrated in the supplied narrative.
Mitigation direction
Install a vendor kernel containing the applicable stable fix commit.
Verify backported vendor kernels by commit presence, not version number alone.
If no update is available, request platform-specific guidance from the device or kernel vendor.
Avoid deploying affected kernels on CAMSS-dependent devices until remediation is confirmed.
Validation and detection
Inventory Linux versions and devices using Qualcomm CAMSS camera hardware.
Check kernel source or package metadata for the applicable stable fix commit.
Review kernel logs for videobuf2 queue-cancel warnings and active-buffer messages.
Test repeated camera start-stop cycles and confirm subsequent starts do not return EBUSY.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-50175 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.