mirror of
https://github.com/hanzoai/visor.git
synced 2026-09-24 17:04:14 +00:00
Ryan El Kochta
efb3bcd85f
Seems that GNU tar extraction has been broken in gVisor since 75b03fd (11/15/2025), which started using openat2(2) to address CVE-2025-45582. tar uses openat2(2) for the RESOLVE_BENEATH flag which allows scoping the path resolution underneath the specified dirfd. This commit implements openat2(2) in gVisor, with support for all flags supported by Linux: RESOLVE_BENEATH, RESOLVE_IN_ROOT, RESOLVE_CACHED, RESOLVE_NO_MAGICLINKS, RESOLVE_NO_SYMLINKS, and RESOLVE_NO_XDEV. This commit also introduces VirtualFilesystem.renameSeq, a global sequence counter that along with mountSeq detects mount or rename operations that race with scoped traversals. A final "resolved-path-is-under-dirfd" check is performed after the traversal. This is for two reasons: (1) in case of a bug in any of the above logic, or (2) in case of an (extremely unlikely) attack where mountSeq overflows by exactly 2^32 during a path resolution. Unfortunately, due to the way path traversal in gVisor is tightly coupled to the operation being performed by a VFS method, using scoped traversals in an operation that *mutates* anything will be difficult, since without major refactoring, the check must happen after the side effect has taken place. Currently, Linux only exposes scoped traversals through openat2(2), so destroying the created fd is all we need to do if the final check fails. (As a result of this limitation, most VFS functions have been modified to reject scoped traversals "just-in-case".) The RESOLVE_NO_XDEV implementation has a slight divergence from Linux. It is a bit looser, permitting absolute symlinks in any case where the root dentry's mount matches the mount the traversal is locked to. Linux's behavior here is likely a bug, and since we can safely be *more* permissive, there's not much reason to match it. This commit also adds syscall tests and an strace formatter for openat2(2).