Bug: TSI sliently drops large HTTP POST requests with BufDescTooSmall

[chaserhkj]

To reproduce:

$ socat tcp-listen:8000,fork - # On host, start a plain text server to monitor traffic
$ podman run --runtime krun --rm -it archlinux
$ curl http://host.ip:8000/ # This works as the host side socat will show the request
$ data=$(dd if=/dev/urandom bs=1024 count=32|base64 -w0) # Some large data chunk
$ curl http://host.ip:8000/ -X POST -d $data
[2026-03-10T20:54:39Z ERROR devices::virtio::vsock::device] error reading TX packet: BufDescTooSmall
# after the above log, curl will hang forever in the guest, and host side socat won't see any request

This only happens with plain text HTTP, not with HTTPS. It seems that the HTTP client tries to send a large packet and it exceeds some buffer length limit somewhere. For HTTPS this is not a concern probably because the TLS layer segmented the packet due to cryptography design.

This is a pretty serious issue since this breaks SOCK_STREAM semantics and effectively introduced silent packet losses to socket behavior. Furthermore due to #510 this is not limited to host-guest communication and can break guest's own loopback as well. This makes this bug far more impactful since loopback traffic is probably where plaintext HTTP is most likely used.

Under a normal and correct network stack, large packets should be broken down into small segments according to the network interfaces' MTU settings. libkrun should implement similar segment breaking logics if packet sizes could exceed any of its internal buffer limits.

[slp]

This is already being tracked in #535. Workarounds have been implemented in libkrunfw (containers/libkrunfw#113) to address this until #530 is merged.