Fix guest bridge stream reassembly

[brainrom]

Motivation

X11 clients occasionally caused muvm to panic in the XQueryExtension handling code when messages were split across multiple socket reads. The issue was first uncovered when running winecfg inside the VM, as it triggered XQueryExtension request for XFIXES when a window received mouse focus.

Panic happens in extension name processing code:

thread '<unnamed>' (237) panicked at crates/muvm/src/guest/bridge/x11.rs:308:52:
range end index 14 out of range for slice of length 12
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
x11bridge thread crashed, x11 passthrough will no longer function

This happened because

1. process_socket_recv() incorrectly sliced the buffer, dropping previously accumulated request_head bytes.
2. X11ProtocolHandler::process_send_stream() assumed the entire request was present, leading to out-of-bounds panics when only partial data arrived.

What this patch does

1. Fixes process_socket_recv() to correctly include request_head bytes in the buffer passed to process_send_stream().
2. Properly drains tail bytes (request_tail) without consuming the entire buffer, preserving leftovers for the next read.
3. Updates X11ProtocolHandler to safely return WantMore when partial XQueryExtension requests are received, preventing panics.

Result

• X11 clients no longer crash the bridge when messages are fragmented.
• Stream reassembly now works correctly
• The patch preserves existing functionality and maintains WantMore handling for incomplete messages.

[WhatAmISupposedToPutHere]

ack on changes to x11.rs, but i do not understand the purpose of the changes to common.rs and what issue it is supposed to fix. Can you elaborate?

[brainrom]

It's linked changes. Just adding WantMore isn't enough, because process_socket_recv() incorrectly handles it.

let buf = &mut ring_msg.data[..len]; is incorrect, because len is only newly received data size, it doesn't account bytes copied from request_head. buf becomes garbage array. Without this part stream processing just stall.

Moving while() out of branch is part of the same fix. If we have request_tail>0 (process_send_stream() processed more bytes that it have in buffer), then we should discard exactly this number of bytes and process the rest, not just discard entire incoming buffers until request_tail becomes zero.
Like in such case:

buf = [ tail_bytes | next_packet_bytes ]
         ^^^^^^^^^    ^^^^^^^^^^^^^^^^^

[brainrom]

@WhatAmISupposedToPutHere I have elaborated on the changes to common.rs. Do you need any further explanations, or is the review in progress?

[WhatAmISupposedToPutHere]

Okay, took me a while, but i understand that change now.

[brainrom]

@WhatAmISupposedToPutHere format test failed, fixed formatting. Should I squash commits and force push?

[WhatAmISupposedToPutHere]

Yep, squash all the things.

[brainrom]

Squashed.

[slp]

@WhatAmISupposedToPutHere @teohhanhui do you think we should do a patch release including this one?

[brainrom]

Since this issue has been present for a year without being noticed, I think it’s reasonable to include it in the next regular release rather than issuing a separate patch release.
I’ve also found a couple more X11-related issues and plan to debug them next.

[slp]

Since this issue has been present for a year without being noticed, I think it’s reasonable to include it in the next regular release rather than issuing a separate patch release.
I’ve also found a couple more X11-related issues and plan to debug them next.

Makes sense, thanks!