https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262180
--- Comment #11 from [email protected] --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3feafab4a34c95209cd4fc3e6224c324efc056f3 commit 3feafab4a34c95209cd4fc3e6224c324efc056f3 Author: Mark Johnston <[email protected]> AuthorDate: 2025-05-23 12:52:24 +0000 Commit: Mark Johnston <[email protected]> CommitDate: 2025-06-30 14:19:30 +0000 namei: Make stackable filesystems check harder for jail roots Suppose a process has its cwd pointing to a nullfs directory, where the lower directory is also visible in the jail's filesystem namespace. Suppose that the lower directory vnode is moved out from under the nullfs mount. The nullfs vnode still shadows the lower vnode, and dotdot lookups relative to that directory will instantiate new nullfs vnodes outside of the nullfs mountpoint, effectively shadowing the lower filesystem. This phenomenon can be abused to escape a chroot, since the nullfs vnodes instantiated by these dotdot lookups defeat the root vnode check in vfs_lookup(), which uses vnode pointer equality to test for the process root. Fix this by extending nullfs and unionfs to perform the same check, exploiting the fact that the passed componentname is embedded in a nameidata structure to avoid changing the VOP_LOOKUP interface. That is, add a flag to indicate that containerof can be used to get the full nameidata structure, and perform the root vnode check on the lower vnode when performing a dotdot lookup. PR: 262180 Reviewed by: olce, kib MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D50418 (cherry picked from commit 7587f6d4840f8d363e457cddc14c184cf1fe7cc1) sys/fs/nullfs/null_vnops.c | 28 ++++++++++++++++++---------- sys/fs/unionfs/union_vnops.c | 21 +++++++++++++++++++++ sys/kern/vfs_cache.c | 11 +---------- sys/kern/vfs_lookup.c | 41 ++++++++++++++++++++++++++++++----------- sys/sys/namei.h | 5 ++++- 5 files changed, 74 insertions(+), 32 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
