A flaw was found in KubeVirt's safepath package (pkg/safepath/safepathlinux.go). The OpenAtNoFollow function walks path components using OPATH|ONOFOLLOW flags, which per open(2) semantics succeeds on a symlink leaf and returns a file descriptor referring to the symlink itself rather than failing with ELOOP. Downstream helper functions (ChmodAtNoFollow, ChownAtNoFollow, MknodAtNoFollow) then operate on the path via /proc/self/fd/N using link-following syscalls (chown(2) instead of fchownat(ATSYMLINKNOFOLLOW)), which the kernel resolves by dereferencing the symlink at use time. This defeats the intended no-follow protection for the final path component.

An attacker with namespace-level pod access can place a symlink in the virt-launcher pod filesystem targeting an arbitrary host path. When virt-handler (running as root on the node) performs a safepath chown/chmod operation on that path during VM disk setup, hotplug, or network-cache flows, it follows the symlink and modifies the ownership or permissions of the attacker-chosen host file with hardcoded values (uid 107, mode ~0660).