avigne
July 20, 2026, 3:16pm
1
Hello.
I am using GNOME 50 on Wayland, and have gnome-remote-desktop.x86_64 50.2-1.fc44.
>gnome-shell --version
avigne
July 20, 2026, 4:21pm
2
avigne
July 20, 2026, 6:20pm
3
Well, false alarm : it seems copy/paste came back to normal. Dunno
avigne
July 21, 2026, 4:35pm
4
And now, it is breaking again ! This is so strange
I think it’s due to this bug in freerdp:
opened 03:57PM - 23 Jul 26 UTC
closed 01:03PM - 28 Jul 26 UTC
**FreeRDP version:** 3.30.0 (regression vs 3.24.2; the affected code is still pr… esent in current master)
**Environment:** Ubuntu 26.04, gnome-remote-desktop 50.0 (FreeRDP-based RDP server), client: Windows mstsc
**Downstream bug:** https://bugs.launchpad.net/ubuntu/+source/freerdp3/+bug/2161573 (Ubuntu security team asked me to report this upstream)
## Behavior
After upgrading from 3.24.2 to 3.30.0, clipboard sharing between a Windows
mstsc client and a FreeRDP-based server (gnome-remote-desktop) is broken in
both directions. The cliprdr server thread dies right after the first
clipboard payload larger than ~1600 bytes arrives:
```
[ERROR][com.freerdp.utils.ChannelPduTracker] - [ChannelPduTracker_poll]: chunk size 14382 is too big
[ERROR][com.freerdp.channels.cliprdr.server] - [cliprdr_server_thread]: CheckEventHandle failed with error 13!
[RDP.CLIPRDR] Possible protocol violation: Client did not send format data response (Timeout reached)
```
After that, every clipboard operation in the session times out until
reconnect. Downgrading the libraries to 3.24.2 fully restores clipboard
functionality with the same client and settings.
## Root cause
`ChannelPduTracker` (added after 3.24.2 in
`libfreerdp/utils/channel_pdu_tracker.c`) validates every received static
virtual channel chunk against the hard-coded minimum chunk size, and its
reassembly buffer is sized accordingly:
https://github.com/FreeRDP/FreeRDP/blob/3.30.0/libfreerdp/utils/channel_pdu_tracker.c#L31
```c
char buffer[CHANNEL_PDU_LENGTH]; /* 1600 + 8 */
```
https://github.com/FreeRDP/FreeRDP/blob/3.30.0/libfreerdp/utils/channel_pdu_tracker.c#L61
```c
if (header->length > CHANNEL_CHUNK_LENGTH) /* 1600 */
```
But the server's default settings advertise a much larger chunk size in the
Virtual Channel Capability Set:
https://github.com/FreeRDP/FreeRDP/blob/3.30.0/libfreerdp/core/settings.c#L1201
```c
freerdp_settings_set_uint32(settings, FreeRDP_VCChunkSize,
(server && !remote) ? CHANNEL_CHUNK_MAX_LENGTH /* 16256 */
: CHANNEL_CHUNK_LENGTH)
```
Per [MS-RDPBCGR] 2.2.7.1.10 the client may then send chunks up to the
advertised VCChunkSize, and mstsc does exactly that (observed chunk sizes
14382 and 2220 — legal per the negotiated 16256, rejected by the hard-coded
1600 check). `ChannelPduTracker_poll()` fails, the cliprdr server thread
exits with ERROR_INVALID_DATA, and the clipboard is dead for the rest of the
session.
So the server advertises "chunks up to 16256 are fine" while its own receive
path rejects anything above 1600. The pre-tracker code path in 3.24.2
reassembled chunks without this check, which is why 3.24.2 works.
## Suggested fix
Validate `header->length` against the negotiated `VCChunkSize` (or against
`CHANNEL_CHUNK_MAX_LENGTH`) instead of `CHANNEL_CHUNK_LENGTH`, and size the
tracker buffer for `CHANNEL_CHUNK_MAX_LENGTH + sizeof(CHANNEL_PDU_HEADER)`.
## Steps to reproduce
1. FreeRDP 3.30.0 server (e.g. gnome-remote-desktop on Ubuntu 26.04)
2. Connect with Windows mstsc, clipboard redirection enabled
3. Copy >1600 bytes of text on either side and paste on the other
Expected: clipboard content transferred.
Actual: cliprdr server thread dies with the errors above; clipboard stops
working for the whole session.
Full server-side log available in the Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/freerdp3/+bug/2161573
see also ubuntu: Bug #2161573 “Clipboard broken in gnome-remote-desktop after fre...” : Bugs : freerdp3 package : Ubuntu
avigne
August 27, 2026, 2:30pm
6
Thank you Paul, you are absolutely right.
I downgraded the freerdp package to 2:3.24.2-1.fc44, restarted the MS remote desktop client, and the copy paste worked flawlessly as before.
Yesterday freerdp released 3.31, and very promptly, a Fedora build was running this morning.
Thanks a lot. BR ; Alain
freerdp-3.31.0-1.fc44.x86_64 fixes the problem for me