Fast-path RLE bitmap decode fails against xrdp (16bpp): "not enough bytes: expected 2, but got 1" + "unsupported fast-path update code" — causes visible screen corruption

[d3lsec]

Title

Fast-path RLE bitmap decode fails against xrdp (16bpp): "not enough bytes: expected 2, but got 1" + "unsupported fast-path update code" — causes visible screen corruption

Environment

• @devolutions/iron-remote-desktop 0.11.0 (npm, latest)
• @devolutions/iron-remote-desktop-rdp 0.7.0 (npm, latest)
• Client: browser (WASM), connecting through devolutions-gateway 2026.2.4 (RDCleanPath)
• Server: xrdp 0.10.6.1-2+kali1 + xorgxrdp 1:0.10.5-2 on Kali GNU/Linux Rolling 2026.3, desktop session = Xfce 4.20
• Server capabilities as sent in ServerDemandActive: Bitmap { pref_bits_per_pix: 16, desktop_resize_flag: true }, GFX/EGFX pipeline NOT used for this connection — negotiated via the classic fast-path bitmap-orders channel instead.

What happens

After a normal, successful connection (TLS handshake OK, login OK, capability exchange OK), the client logs repeated warnings while receiving bitmap updates, and the on-screen result is visibly corrupted (diagonal shearing / torn tiles), while mouse/keyboard input keep working.

Representative log lines from one session (122 total BitmapData fast-path updates received, all bits_per_pixel: 16, 2 of them fail to decode):

DEBUG ironrdp_session::fast_path: Non-32 bpp compressed RLE_BITMAP_STREAM bpp=16
WARN  ironrdp_session::fast_path: Invalid RLE-compressed bitmap: not enough bytes: expected 2 bytes, but got 1
WARN  ironrdp_session::fast_path: Received invalid Fast-Path update field="updateCode" reason="unsupported fast-path update code"

One of the BitmapData PDUs immediately preceding a failure, for reference:

BitmapData { rectangle: InclusiveRectangle { left: 385, top: 427, right: 594, bottom: 448 }, width: 212, height: 22, bits_per_pixel: 16, compression_flags: Compression(BITMAP_COMPRESSION | NO_BITMAP_COMPRESSION_HDR), compressed_data_header: None, bitmap_data.len(): 54 }

What I ruled out (server-side, not a config issue)

Before filing, I checked whether this was an xrdp misconfiguration on our end:

• desktop_width/desktop_height requested by the client are always rounded to a multiple of 4 (e.g. 796x1020, 900x636) — not a stride/alignment issue on the client side.
• Toggling bitmap_compression=false in xrdp.ini (forces raw/uncompressed bitmap updates instead of RLE): connection got noticeably slower but showed the exact same corruption — so it isn't specific to the RLE codec's compression math alone, something in the fast-path bitmap-orders handling itself is affected, or xrdp still exercises the same code path regardless of that flag.
• max_bpp=32 is already set in xrdp.ini (the server's own ceiling), yet preferredBitsPerPixel stays 16 in ServerDemandActive regardless — this doesn't look configurable from our side.
• Forcing the X11 screen depth to 32 in xorg.conf (DefaultDepth/Depth) breaks the xrdp Xorg session entirely (X server could not be started) — not viable.
• iron-remote-desktop's ConfigBuilder has no method to request a specific color depth (only withUsername/withPassword/withServerDomain/withDestination/withProxyAddress/withAuthToken/withExtension/withDesktopSize), so we can't influence this from the client config either.
• Confirmed with xfreerdp (FreeRDP 2.11.5) against the same xrdp instance: connects and renders perfectly clean at the same resolution/session — so this isn't an xrdp/xorgxrdp bug, it's specific to how ironrdp_session::fast_path parses this server's 16bpp interleaved-RLE stream.

Impact

Legacy/non-GFX xrdp sessions (very common — Linux desktop targets, not just Windows) render with visible tearing/corruption. Reproducible every connection against this server, ~2 failed tile decodes out of ~122 per session in our testing, but visually noticeable because failures desync the bitmap cache for subsequent frames referencing the same tile.

Contact

adelson-amorim@outlook.com — happy to provide a packet capture / full session log (currently ~190MB with embedded frame data) if useful for a repro.

[glamberson]

Thanks again for how thorough this report already is, ruling out xrdp/xorgxrdp config and confirming clean with xfreerdp made this easy to trust as a real ironrdp-side bug.

I read through the Interleaved RLE decoder against FreeRDP's interleaved.c and didn't find the bug by inspection alone. Could you send over the packet capture / session log you offered? That would let us reproduce the actual failing frame directly.

[d3lsec]

Thanks for looking into this — here's the packet capture / session log you asked for, plus an independent re-reproduction to rule out anything specific to the first VM.

Re-reproduction on a fresh instance

The original VM used for the first report developed an unrelated ext4 disk corruption after filing (bad block bitmap checksum, confirmed by two clean reboots that failed to recover it — not related to IronRDP). To make sure the corruption we're reporting is the real decode bug and not an artifact of that, I rebuilt a fresh Kali VM from the same known-good master image/config and reproduced from scratch:

• @devolutions/iron-remote-desktop / @devolutions/iron-remote-desktop-rdp (same versions as before), Chromium, via devolutions-gateway (RDCleanPath).
• xrdp 0.10.6.1, fresh boot (0 min uptime at connection time).
• Server log confirms the same negotiation as before: SSL|HYBRID|HYBRID_EX requested, TLS selected (TLSv1.3, TLS_AES_256_GCM_SHA384), RemoteFX codec offered, GFX config present (/etc/xrdp/gfx.toml) but not used for this connection — same classic fast-path bitmap-orders channel as the original report.

Within seconds of connecting, same exact warnings as originally reported:

WARN ironrdp_session::fast_path: Received invalid Fast-Path update field="updateCode" reason="unsupported fast-path update code"
WARN ironrdp_session::fast_path: Invalid RLE-compressed bitmap: not enough bytes: expected 2 bytes, but got 1

Same visual result: diagonal shearing / torn tiles on screen.

Not Kali-specific

We've now seen this same failure signature (identical warnings, identical visual corruption pattern) against two separate Linux/xrdp instances, not just the one Kali box from the original report — so this doesn't look like it's specific to that one VM's image or config.

Files

I have three files ready — corruption_screenshot.png, xrdp_server_log.txt (server-side log for this exact connection, handshake through teardown), and ironrdp_repro.pcap (full capture, tcpdump -i eth0 port 3389 -s 0, taken directly on the xrdp server's interface during the reproduction) — but I'm posting this through the API and it doesn't let me attach files to a comment. I'll follow up right after with a reply that has them attached through the web UI.

Caveat on the pcap: this RDP session negotiated TLS security (see server log — Selected TLS security), so the RDP payload inside the capture is TLS-encrypted. Wireshark will show the TCP/TLS record structure but not the decoded RDP PDUs without the session's TLS keys, which we did not capture this round. Sharing it anyway in case the timing/sizes are useful on their own.

If a decrypted capture (e.g. via a TLS key log) or anything else would actually move this forward, happy to go collect it — just let me know what you need. Also happy to be reached directly: adelson-amorim@outlook.com.

Really appreciate the time you're putting into this, thank you.

[d3lsec]

[xrdp_server_log.txt](https://github.com/user-attachments/files/32037682/xrdp_server_log.txt)

ironrdp_repro.zip

[d3lsec]

ironrdp_repro.zip

[d3lsec]

Found the root cause — two separate bugs in the fast-path decode path, both triggered by this exact xrdp traffic pattern:

1. not enough bytes: expected 2, but got 1 (the RLE decoder)

ironrdp-graphics' RLE decompressor kept reading orders even after the destination bitmap buffer was already full. xrdp pads the tail of its RLE_BITMAP_STREAM after the real orders end (to fill the negotiated tile size); the old loop treated that trailing padding as the start of a new order and choked on it mid-parse — hence "expected 2 bytes, but got 1". Fix is a one-line guard: stop the loop as soon as the destination is full, before trying to read another order.

while !src.eof() {
    // xrdp may pad RLE_BITMAP_STREAM after the destination is already full.
    if dst.remaining_len() == 0 {
        break;
    }
    ...

Added a regression test (trailing_incomplete_order_is_ignored_when_destination_is_full) that reproduces exactly this: a well-formed RLE stream immediately followed by a single trailing byte, once the buffer is already at capacity.

2. unsupported fast-path update code (Synchronize treated as invalid)

Separately, UpdateCode::Synchronize (0x3) was falling into the "unrecognized update code" branch instead of being handled as the no-op it's meant to be. xrdp sends a Synchronize update in the same burst as the bitmap updates above, so both warnings always showed up together in the logs even though they're unrelated bugs.

Validation

• Full workspace test suite (ironrdp-graphics, ironrdp-pdu, ironrdp-session) green, regression test included.
• Re-reproduced against a fresh xrdp instance (same setup as the repro I sent you: xrdp 0.10.6.1, TLS security, classic fast-path bitmap-orders channel) — connects clean now, zero occurrences of either warning, no visual corruption.
• Also validated end-to-end against a second, completely independent Linux/xrdp target (different machine, outside the original test lab) to make sure this wasn't specific to the VMs used in the original report — same clean result.

I don't have a PR open against this repo yet — the patch right now lives in a local fork I've been testing against. Happy to open one against crates/ironrdp-graphics and crates/ironrdp-session if that's useful, or if your team would rather land the fix yourselves now that the root cause is pinned down, that works too — whatever's less friction on your end.

Thanks again for staying with this one, especially for asking for the packet capture instead of taking the report at face value — that's what pushed the re-reproduction that ruled out a one-off VM issue, and having a clean second data point made it a lot easier to trust the fix once I found it. Really appreciate the time.

[glamberson]

Sorry for the slow reply, and thank you for the capture and for reproducing it on a second machine.

Yes, please open the pull requests yourself. I'd send two, since they're separate causes: The RLE decoder guard in ironrdp-graphics, and the Fast-Path Synchronize handling in the fast-path update decoder.

Two notes for the descriptions. For Synchronize, MS-RDPBCGR 2.2.9.1.1.3.1.3 describes TS_UPDATE_SYNC as a T.128 artifact that SHOULD be ignored, section 2.2.9.1.2.1.3 defines the fast-path variant, and the slow-path case is already ignored as a no-op in ironrdp-session, so the fast-path decoder returning "unsupported fast-path update code" is a gap. For the RLE guard, I found nothing in MS-RDPBCGR 2.2.9.1.1.3.1.2.4 about bytes after the last compression order, so I'd present it as tolerance for xrdp's padding, backed by your reproduction on two servers, not as a spec requirement.

One thing to expect: I've got an open PR, #1962, that adds limits on the decoder's bitmap dimensions in the same file, crates/ironrdp-graphics/src/rle.rs. It doesn't touch the order loop you changed, but both changes may add a test at the end of the same test module, so whichever lands second may need a small rebase.