CVE-2024-50266

What it actually does

Incorrect GDSC configuration prevents runtime HW control mode changes for vcodec clocks, leaving video_cc_mvs0_clk stuck off and triggering clk_branch_wait warnings during venus driver video operations.

Why it matters to the business

Video playback and streaming applications fail or hang on affected Qualcomm platforms, reducing device usability for media workloads and requiring kernel updates to restore functionality.

How an attack unfolds

A local user or process initiates video decoding via the venus driver on SM8350/SC8280XP hardware; the vdec_start_streaming path enables clocks that never leave the stuck-off state because GDSC definitions lack HW_CTRL_TRIGGER support.

How to fix it

Update the Linux kernel to the version containing the videocc-sm8350 GDSC change that enables HW_CTRL_TRIGGER for vcodec clocks; apply all vendor-provided kernel packages that include this fix.

How to confirm the fix worked

Boot the updated kernel, start a video stream with the venus driver, and confirm absence of clk_branch_wait warnings and that video_cc_mvs0_clk reports correct status.

Typical attack path

1. Invoke V4L2 streamon ioctl on a video device
2. Trigger vdec_start_streaming in venus_dec
3. Call vcodec_clks_enable which reaches clk_branch2_enable
4. Encounter clk_branch_wait failure leaving clock stuck off

How to detect it

Search kernel logs for clk_branch_wait warnings mentioning video_cc_mvs0_clk status stuck at off during venus or V4L2 video streaming activity.

What your security team should do

• Prioritize kernel updates on all Qualcomm SM8350/SC8280XP systems running video workloads
• Add kernel log monitoring for clk_branch_wait and video clock warnings
• Test video decoding functionality after applying updates