Code Execution in Host Sentry Process via Double Free in gVisor VFS MemoryFile

Use-after-free vulnerability in VFS in Google gVisor prior to release 20260831.0 on all platforms allows a local attacker with standard container privileges to achieve code execution in the host sentry process by double-freeing the backing MemoryFile from an in-sandbox overlay filesystem. The sentry process remains confined by host-level Linux seccomp and namespace boundaries.

Host Root Sandbox Escape in gVisor via Character Device Passthrough and CUSE

Improper Exposure of Resource to Wrong Sphere in the host file helper (gofer) in Google gVisor prior to commit 573a9e73cf844f on Linux platforms with CUSE enabled allows a local attacker with container image deployment privileges to achieve root code execution on the host system. By including a /dev/cuse character device node in a container image, opening the device passes through to the host, allowing the sandboxed attacker to register a host device and exploit CUSE unrestricted ioctl handling to overwrite root udev helper memory.

Improper File Permission Handling in Google gVisor runsc

Google gVisor's runsc component exhibited a local privilege escalation vulnerability due to incorrect handling of file access permissions, which allowed unprivileged users to access restricted files. This occurred because the process initially ran with root-like permissions until the first fork.

Improved Seeding and Hashing In gVisor

A weak hashing algorithm and small sizes of seeds/secrets in Google's gVisor allowed for a remote attacker to calculate a local IP address and a per-boot identifier that could aid in tracking of a device in certain circumstances.

Weaknesses in the generation of TCP/UDP source ports and some other header values in Google's gVisor allowed them to be predicted by an external attacker in some circumstances.

Denial-of-Service in Gvisor

A denial of service exists in Gvisor Sandbox where a bug in reference counting code in mount point tracking could lead to a panic, making it possible for an attacker running as root and with permission to mount volumes to kill the sandbox. We recommend upgrading past commit 6a112c60a257dadac59962e0bc9e9b5aee70b5b6

Google gVisor before 2018-08-22 reuses a pagetable in a different level with the paging-structure cache intact, which allows attackers to cause a denial of service ("physical address not valid" panic) via a crafted application.

pkg/sentry/kernel/shm/shm.go in Google gVisor before 2018-11-01 allows attackers to overwrite memory locations in processes running as root (but not escape the sandbox) via vectors involving IPC_RMID shmctl calls, because reference counting is mishandled.

Google gVisor before 2018-08-23, within the seccomp sandbox, permits access to the renameat system call, which allows attackers to rename files on the host OS.