You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should provide some support for ensuring that when host mapping objects are no longer needed, they have a chance to run a destructor. This is particularly important as, currently, map_file_cow has no way to ensure that its mappings are cleaned up, so it leaks a bit of virtual memory whenever it is run.
Since map_file_cow currently only calls map_region, could we remove map_file_cow, and have the caller just use map_region and keep track of the handle themselves?
Root Cause
The raw *mut c_void pointer returned by libc::mmap is cast to usize and stored in MemoryRegion.host_region — a plain integer with no ownership or Drop semantics. Nothing in the cleanup chain calls munmap:
HyperlightVm::unmap_region — removes the KVM/MSHV slot only, does not munmap
HyperlightVm::Drop — only calls interrupt_handle.set_dropped()
MultiUseSandbox — has no Drop impl
Snapshot restore() — calls unmap_region for stale regions (same problem)
The error path in map_file_cow correctly calls munmap, confirming the success path omission is an oversight.
Proposed Fix
Introduce a Linux OwnedFileMapping struct that stores the mmap pointer and size with a Drop impl calling libc::munmap. Track these in a Vec on MultiUseSandbox and clean up in restore() (when regions are unmapped during snapshot restore) and on MultiUseSandbox::Drop (catch-all for remaining mappings).
The correct solution here is probably that map_region instead of taking a MemoryRegion directly takes some where for<'a> &'a T: Into<MemoryRegion> + Clone object that it holds onto and drops at the appropriate times. When map_file_cow calls map_region, it uses some (arch-specific) FileMapping structure that implements that properly. That would also let you write code that shared one mapping between multiple sandboxes and use it on both Linux and Windows without disaster striking from the strange lifecycle management of the region on Windows.
Activity
ludfjig commentedon Aug 27, 2025
Since
map_file_cowcurrently only callsmap_region, could we removemap_file_cow, and have the caller just usemap_regionand keep track of the handle themselves?map_file_cowleaks VMA entries (missingmunmapon success path) #1290 as a duplicate of this issuejsturtevant commentedon Mar 11, 2026
from #1290:
syntactically commentedon Aug 5, 2026
The correct solution here is probably that
map_regioninstead of taking aMemoryRegiondirectly takes somewhere for<'a> &'a T: Into<MemoryRegion> + Cloneobject that it holds onto and drops at the appropriate times. Whenmap_file_cowcallsmap_region, it uses some (arch-specific)FileMappingstructure that implements that properly. That would also let you write code that shared one mapping between multiple sandboxes and use it on both Linux and Windows without disaster striking from the strange lifecycle management of the region on Windows.