fix(cliprdr): validate locked file requests against the list their lock covers

[Piero (pierophp)]

Stacked on #1980. GitHub cannot base a cross-fork PR on another fork branch, so the diff here also carries #1980's commit. The change under review is the second commit, fix(cliprdr): validate locked file requests against the list their lock covers. Rebasing onto master once #1980 lands makes it standalone.

Problem

[MS-RDPECLIP] 3.1.5.4.5:

If the clipDataId field is present, then the locked File Stream data associated with the ID MUST be used to service the request.

The sender side already honours this. A Lock PDU received from the remote snapshots local_file_list into locked_file_lists, and an incoming FileContentsRequest carrying a clipDataId is served from that snapshot — with the spec text quoted inline at the use site.

The receiver side has no equivalent. A Lock PDU we send asks the remote to keep its File Stream data alive across a clipboard change. request_file_contents even documents the contract:

Caller can override by setting request.data_id explicitly before calling this method. This allows the receiver to correlate the request with locked File Stream data even if the clipboard has changed since the lock was sent.

…and twelve lines later validates the index against remote_file_list, which handle_format_list clears on every clipboard change and the next FormatDataResponse overwrites:

if let Some(ref file_list) = self.remote_file_list {
    if file_list.files.len() <= validated_file_index {
        return Err(/* "file index out of bounds for remote file list" */);

So: lock a two-file selection, let the remote replace it with a one-file one, and an already-issued request for index 1 fails — even though the lock is precisely the promise that the remote still holds that data. handle_format_list's own comment says this is not the intent:

// Transition active locks to Expired — but do NOT send Unlock PDUs yet.
// Active downloads from the previous clipboard may still be using these locks.

With a server embedder that surfaces the error, that failure reaches the session.

Change

Mirrors locked_file_lists for the receiving direction:

• locked_remote_file_lists: HashMap<u32, PackedFileList> — the remote list snapshotted under whatever lock was active when it arrived, at the existing on_remote_file_list call site.
• Bounds and range validation consult that snapshot when the request carries a data_id, falling back to remote_file_list otherwise.
• The snapshot is released with its lock, in both the drive_timeouts sweep and release_outgoing_locks.
• Bounded by the same MAX_LOCKED_FILE_LISTS as the sender side.

handle_format_list is untouched: it still clears remote_file_list, and the snapshots deliberately outlive it.

Tests

In crates/ironrdp-testsuite-core/tests/clipboard/lock_lifecycle.rs:

• a_locked_request_validates_against_the_list_its_lock_covers — drives two selections through the real protocol flow (FormatList → initiate_paste → FormatDataResponse), then requests A's second file under A's clipDataId. Fails on master with "file index out of bounds for remote file list"; passes here. The same index without a lock is still rejected against the current selection.
• a_snapshot_is_released_with_the_lock_it_belongs_to — after the sweep sends Unlock, the snapshot must stop validating requests, since the remote has released the data.

All 213 clipboard tests pass.

🤖 Generated with Claude Code