Date: Fri, 02 Apr 2021 12:41:31 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 253593] Process hangs if nullfs mounted cwd moved out of chroot Message-ID: <bug-253593-227-1zdpjikfDZ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-253593-227@https.bugs.freebsd.org/bugzilla/> References: <bug-253593-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253593 --- Comment #9 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D76b1b5ce6d81f66b09be8a20aecd064b6= 5fd6b50 commit 76b1b5ce6d81f66b09be8a20aecd064b65fd6b50 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2021-04-01 17:42:14 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2021-04-02 12:40:25 +0000 nullfs: protect against user creating inconsistent state The VFS conventions is that VOP_LOOKUP() methods do not need to handle ISDOTDOT lookups for VV_ROOT vnodes (since they cannot, after all). Nu= llfs bypasses VOP_LOOKUP() to lower filesystem, and there, due to user actio= ns, it is possible to get into situation where - upper vnode does not have VV_ROOT set - lower vnode is root - ISDOTDOT is requested User just needs to nullfs-mount non-root of some filesystem, and then m= ove some directory under mount, out of mount, using lower filesystem. In this case, nullfs cannot do much, but we still should and can ensure internal kernel structures are consistent. Avoid ISDOTDOT lookup forwarding when VV_ROOT is set on lower dvp, return somewhat arbitrary ENOENT. PR: 253593 Reported by: Gregor Koscak <elogin41@gmail.com> Test by: Patrick Sullivan <sulli00777@gmail.com> Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week sys/fs/nullfs/null_vnops.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-253593-227-1zdpjikfDZ>