Skip to content

GUACAMOLE-2263: Harden CLIPRDR channel against FreeRDP 3.x clipboard state machine.#661

Open
escra wants to merge 1 commit intoapache:staging/1.6.1from
ESCRA-GmbH:fix/cliprdr-freerdp3-hardening
Open

GUACAMOLE-2263: Harden CLIPRDR channel against FreeRDP 3.x clipboard state machine.#661
escra wants to merge 1 commit intoapache:staging/1.6.1from
ESCRA-GmbH:fix/cliprdr-freerdp3-hardening

Conversation

@escra
Copy link
Copy Markdown

@escra escra commented Apr 14, 2026

Summary

Six fixes for the clipboard redirection (CLIPRDR) plugin that prevent RDP
session disconnects when clipboard operations are performed with FreeRDP 3.x
clients.

FreeRDP 3.x has a significantly stricter CLIPRDR state machine than 2.x.
Several patterns that were harmless with FreeRDP 2.x now cause session
teardowns:

  1. Overlapping Format Data Requests - FreeRDP 3.x tracks pending requests
    internally and disconnects with error 1359 if a second request arrives
    before the first is answered. Fix: add request_pending flag with
    request_lock mutex.

  2. CB_RESPONSE_FAIL not checked - If the server responds with a failure
    flag, the old code would attempt to process the (NULL/garbage) data,
    causing a crash. Fix: check msgFlags & CB_RESPONSE_FAIL early.

  3. No response for unsupported formats - When the server requests an
    unsupported clipboard format, the old code silently drops the request.
    FreeRDP 3.x times out after 10 seconds and tears down the session. Fix:
    send CB_RESPONSE_FAIL for unsupported formats.

  4. NULL/empty data guard - requestedFormatData can be NULL or
    dataLen can be zero in edge cases. Fix: guard before processing.

  5. Stale pending requests - When a new Format List arrives (server
    clipboard content changed), any pending request for old data becomes
    stale. Fix: clear request_pending when a new Format List is received.

  6. Non-OK return codes treated as fatal - FreeRDP 3.x treats non-OK
    returns from CLIPRDR callbacks as fatal channel errors. Fix: all callbacks
    now return CHANNEL_RC_OK and log errors instead.

Related

Affected versions

  • staging/1.6.1 - with FreeRDP 3.x (default in Docker image)
  • main - same patterns exist

Test plan

  • Connect from FreeRDP 3.x client, perform rapid copy/paste operations
  • Copy unsupported clipboard format (e.g., image) on server, verify no disconnect
  • Verify clipboard works normally with FreeRDP 2.x (no regression)
  • Stress test: rapid clipboard changes while switching windows
  • Verify no error 1359 disconnects under load

Five fixes for the clipboard redirection (CLIPRDR) plugin that prevent
RDP session disconnects when clipboard operations are performed with
FreeRDP 3.x:

1. Add request_pending flag with request_lock mutex to prevent
   overlapping Format Data Requests that desync FreeRDP's internal
   state tracking (error 1359).
2. Check CB_RESPONSE_FAIL in format_data_response before processing
   data to prevent NULL pointer dereference on failed server responses.
3. Send FAIL response for unsupported formats in format_data_request
   instead of silently dropping — FreeRDP 3.x times out and tears down
   the session if no response arrives.
4. Guard against NULL or empty requestedFormatData in
   format_data_response to prevent crash on malformed PDUs.
5. Clear stale pending requests when a new Format List arrives.
6. All CLIPRDR callbacks now always return CHANNEL_RC_OK — FreeRDP 3.x
   treats non-OK returns as fatal channel errors that disconnect the
   entire session.

Related: FreeRDP/FreeRDP#11847
@escra escra changed the title Harden CLIPRDR channel against FreeRDP 3.x clipboard state machine. GUACAMOLE-2263: Harden CLIPRDR channel against FreeRDP 3.x clipboard state machine. Apr 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant