Hello Maintainer of FreeRDP,
today, I was diagnosing an issue regarding RDP Connections to a Windows machine lacking Webcam support (used with "/dvc:rdpecam" option).
I did a bunch of debugging, and even tunnel-connecting to my private VM, which I used to verify the feature on, recognized the camera, but gave me some errors and couldn't show any image.
I appears that since then, an update broke this feature. Basically around March webcam worked through freerdp, at least 2 months ago it didn't anymore.
In the interest to solve this issue in a timely manner, I used Claude Code (Fable 5.1) for diagnosing the logs and troubleshooting.
It produced newly built deb files which fixed the issue first-time, making it's diagnosis seem on-point.
Basically this PRs changes need to be included: https://github.com/FreeRDP/FreeRDP/pull/13596
Below is the report by Fable 5.1 about the details.
Regards and apologies in advance if I didn't do this proper (first time submitting a report to debian),
Linus Kaschulla
AI-Generated Report:
camera redirection with xfreerdp3 (/dvc:rdpecam, MS-RDPECAM) no longer works in
trixie since the 3.15.0+dfsg-2.1+deb13u1 update (shipped with the 13.5 point
release). It worked with 3.15.0+dfsg-2.1. deb13u2 and deb13u3 are affected as
well.
Symptoms
--------
The redirected camera appears in the Windows session (e.g. "Logitech BRIO
(Redirected)" in the Windows 11 Camera app or in Device Manager), the server
sends StartStreamsRequest, the V4L2 capture starts, but no picture ever
arrives. With /log-level:DEBUG (and stderr captured, 2>&1) the log shows:
[INFO][com.freerdp.channels.rdpecam-v4l.client] - [cam_v4l_stream_start]: Camera format: MJPG, width: 1920, height: 1080, fps: 60/1
[DEBUG][com.freerdp.channels.rdpecam-device.client] - [ecam_dev_on_data_received]: ChannelId=19, MessageId=0x11, Version=2
[DEBUG][com.freerdp.channels.rdpecam-device.client] - [ecam_dev_send_pending]: Frame drop or error in ecam_encoder_compress
[DEBUG][com.freerdp.channels.rdpecam-device.client] - [ecam_dev_send_pending]: Frame drop or error in ecam_encoder_compress
No [ERROR] line is logged, no SampleResponse (MessageId=0x12) is ever sent,
and after one or two frames the capture thread stays silent until the server
deactivates the device. Reproducible with a Logitech BRIO (MJPG) against
Windows 11 24H2 and Windows Server 2022.
Cause
-----
channels-rdpecam-ensure-sws-context-size-matches-CVE-2026-24677.patch
(upstream d2d4f449312d) adds at the top of ecam_encoder_compress_h264() in
channels/rdpecam/client/encoding.c:
if (!ecam_sws_valid(stream))
return FALSE;
ecam_sws_valid() returns FALSE while stream->sws is NULL, and the sws context
is only created further down in the same function by ecam_init_sws_context()
(after the MJPEG decoder has produced the pixel format). So the first frame,
and every following frame, returns FALSE before anything is decoded or
encoded, and nothing is logged because that return path has no WLog call.
Upstream had the same regression in 3.22.0 and removed the check again on
2026-02-08 in commit 55a9161ecbf2336f1003faba6792f02688c4b29e
"[channels,rdpecam] fix sws context checks" (released in 3.23.0). That
follow-up commit is missing from the trixie package.
Fix
---
The attached channels-rdpecam-fix-sws-context-checks.patch is that upstream
commit (three lines removed) with a DEP-3 header; it applies on top of the
current trixie patch series. The out-of-bounds check that CVE-2026-24677 is
about is kept, because ecam_init_sws_context() still validates and
(re)creates the context before sws_scale() is called.
I rebuilt 3.15.0+dfsg-2.1+deb13u3 with this patch added to
debian/patches/series; it applies without offset and builds cleanly. The same fix (upstream code of
3.32.1 from trixie-backports, which contains 55a9161ecbf2) restores a working
camera on our hardware.
System
------
Debian 13 (trixie) amd64, freerdp3-x11 / libfreerdp3-3 /
libfreerdp-client3-3 / libwinpr3-3 3.15.0+dfsg-2.1+deb13u3, ffmpeg 7.1.5,
PipeWire desktop, Logitech BRIO (USB 3, MJPG), Intel iGPU with VAAPI.