Bug: TSI sliently drops large HTTP POST requests with BufDescTooSmall
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- rust
- Domain
- networking
Research direction
The reproduction identifies the virtio vsock TX path through the devices::virtio::vsock::device error log, but names no source file or test. Start by tracing where BufDescTooSmall is raised and how large TX packets are handled; compare the behavior with the expected SOCK_STREAM semantics. Done means large plaintext HTTP POST requests are delivered without hanging, with a regression test covering the reproduction.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Rust
- Stars
- 2.8k
- Forks
- 279
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 28
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from libkrun/libkrun
-
virtio-fs (Linux passthrough): debug log in do_lookup panics the fs worker on non-UTF-8 file namesPossibly taken @zcl-g5 claimed this 1 day ago. Open
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
libkrun/libkrun#895 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 5/5 Over a week Newbie friendliness 12/100
Maintainers usually reply within 2 days
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 2 days
-
All virtiofs shares return ECONNREFUSED in the guest (macOS host, libkrun 1.19.6 + krunkit 1.3.2)Open
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 2 days
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
EasyTier/EasyTier#2672 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
repowise-dev/repowise#3374 ·
Maintainers usually reply within 1 day
-
awaiting-response bug needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
wildcard/caro#1562 · 1 comment ·
Maintainers usually reply within 3 days