mirror of
https://github.com/cloud-hypervisor/cloud-hypervisor.git
synced 2026-08-05 02:19:16 +00:00
8bd96078a9
The vsock muxer tracked host-allocated local ports in a set, and `remove_connection()` released `key.local_port` from it for every connection it removed. Only host-initiated connections take their local port from `allocate_local_port()`, though: guest-initiated ones use the guest-chosen `dst_port` verbatim, and never hold an allocation. Removal was therefore able to release a port its connection did not own. A guest-initiated connection whose destination port collides with a host-allocated ephemeral port dropped that port from the allocator's free list on teardown, while the host-initiated connection that owned it was still live and using it. The allocator could then hand the same port out twice. Track the owning peer (guest) port alongside each allocation, and release an allocation only when the connection being removed matches the recorded owner. Guest-initiated connections never match, so they can no longer disturb host-side port accounting. Reaching this from the guest additionally requires a host process listening on the AF_UNIX path for a port in the host ephemeral range, which is not how host services are normally deployed. Hitting the duplicate allocation would further require the allocator to wrap its ~2^30 port range. This is a correctness fix rather than a fix for a practically exploitable issue. Add a regression test that drives the muxer through the colliding-port sequence and checks the host connection keeps its allocation. Signed-off-by: Lily Goscha <lilygoscha@gmail.com>