NetBSD Problem Report #53850
From www@NetBSD.org Thu Jan 10 03:44:27 2019
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id B554F7A233
for <gnats-bugs@gnats.NetBSD.org>; Thu, 10 Jan 2019 03:44:27 +0000 (UTC)
Message-Id: <20190110034426.A2D707A26A@mollari.NetBSD.org>
Date: Thu, 10 Jan 2019 03:44:26 +0000 (UTC)
From: n54@gmx.com
Reply-To: n54@gmx.com
To: gnats-bugs@NetBSD.org
Subject: mount(2) with MNT_UNION | MNT_UPDATE will lead to panic
X-Send-Pr-Version: www-1.0
>Number: 53850
>Category: kern
>Synopsis: mount(2) with MNT_UNION | MNT_UPDATE will lead to panic
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Jan 10 03:45:00 +0000 2019
>Closed-Date: Tue Feb 19 07:13:52 +0000 2019
>Last-Modified: Tue Feb 19 07:13:52 +0000 2019
>Originator: Kamil Rytarowski
>Release: NetBSD 8.99.30 amd64
>Organization:
TNF
>Environment:
NetBSD chieftec 8.99.30 NetBSD 8.99.30 (GENERIC) #0: Tue Jan 8 00:25:54 CET 2019 root@chieftec:/public/netbsd-root/sys/arch/amd64/compile/GENERIC amd64
>Description:
Updating a mounted partition to MNT_UNION will lead to a panic.
# ls /et[ 116.5603135] uvm_fault(0xfffffab9a2ca4cf8, 0x0, 1) -> e
[ 116.5603135] fatal page fault in supervisor mode
[ 116.5603135] trap type 6 code 0 rip 0xffffffff80df7d10 cs 0x8 rflags 0x286 cr2
0x24 ilevel 0 rsp 0xffffd88029ec8e00
[ 116.5603135] curlwp 0xfffffab9a2be7600 pid 444.1 lowest kstack 0xffffd88029ec5
2c0
kernel: page fault trap, code=0
Stopped in pid 444.1 (ksh) at netbsd:vref+0x10: movl 24(%rax),%eax
db{0}> bt
vref() at netbsd:vref+0x10
vn_readdir() at netbsd:vn_readdir+0x251
sys___getdents30() at netbsd:sys___getdents30+0x96
sy_call() at netbsd:sy_call+-0x29911d
sy_invoke() at netbsd:sy_invoke+0xd5
syscall() at netbsd:syscall+0xff
--- syscall (number 390) ---
731778d0310a:
db{0}>
https://nxr.netbsd.org/xref/src/sys/kern/vfs_vnops.c#523
522
523 if (count == auio.uio_resid && (vp->v_vflag & VV_ROOT) &&
524 (vp->v_mount->mnt_flag & MNT_UNION)) {
525 struct vnode *tvp = vp;
526 vp = vp->v_mount->mnt_vnodecovered;
527 vref(vp); /// <-- vp is NULLVP
528 mutex_enter(&fp->f_lock);
529 fp->f_vnode = vp;
530 fp->f_offset = 0;
531 mutex_exit(&fp->f_lock);
532 vrele(tvp);
533 goto unionread;
534 }
535 *done = count - auio.uio_resid;
536 return error;
537 }
>How-To-Repeat:
#include <sys/param.h>
#include <sys/types.h>
#include <sys/mount.h>
int
main(int argc, char **argv)
{
char A[1024];
mount(NULL, "/", MNT_UNION | MNT_UPDATE, A, 0);
return 0;
}
// trigger vn_readdir(), e.g. in ksh(1) <tab> completion of directories
>Fix:
N/A
>Release-Note:
>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/53850: mount(2) with MNT_UNION | MNT_UPDATE will lead to
panic
Date: Thu, 10 Jan 2019 06:59:24 +0000
On Thu, Jan 10, 2019 at 03:45:00AM +0000, n54@gmx.com wrote:
> Updating a mounted partition to MNT_UNION will lead to a panic.
Urrgh...
> int
> main(int argc, char **argv)
> {
> char A[1024];
> mount(NULL, "/", MNT_UNION | MNT_UPDATE, A, 0);
> return 0;
> }
Does it also die if you do this on a mount point other than /, where
there is actually another fs underneath?
(and if you mount over /, does it then not die?)
I kinda think MNT_UPDATE ought not to be allowed to turn MNT_UNION on
and off, but if it otherwise works...
--
David A. Holland
dholland@netbsd.org
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/53850: mount(2) with MNT_UNION | MNT_UPDATE will lead to
panic
Date: Fri, 11 Jan 2019 02:50:36 +0100
On 10.01.2019 08:00, David Holland wrote:
> The following reply was made to PR kern/53850; it has been noted by GNATS.
>
> From: David Holland <dholland-bugs@netbsd.org>
> To: gnats-bugs@NetBSD.org
> Cc:
> Subject: Re: kern/53850: mount(2) with MNT_UNION | MNT_UPDATE will lead to
> panic
> Date: Thu, 10 Jan 2019 06:59:24 +0000
>
> On Thu, Jan 10, 2019 at 03:45:00AM +0000, n54@gmx.com wrote:
> > Updating a mounted partition to MNT_UNION will lead to a panic.
>
> Urrgh...
>
> > int
> > main(int argc, char **argv)
> > {
> > char A[1024];
> > mount(NULL, "/", MNT_UNION | MNT_UPDATE, A, 0);
> > return 0;
> > }
>
> Does it also die if you do this on a mount point other than /, where
> there is actually another fs underneath?
>
> (and if you mount over /, does it then not die?)
>
> I kinda think MNT_UPDATE ought not to be allowed to turn MNT_UNION on
> and off, but if it otherwise works...
>
It looks like some types of partitions return error (EOPNOTSUPP).
I've not reproduced the crash with tmpfs on /var/shm.
I miss some details but probably forbidding MNT_UNION bit switching on
MNT_UPDATE is the way to go.
> --
> David A. Holland
> dholland@netbsd.org
>
>
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/53850: mount(2) with MNT_UNION | MNT_UPDATE will lead to panic
Date: Fri, 11 Jan 2019 06:07:01 -0000 (UTC)
n54@gmx.com (Kamil Rytarowski) writes:
> > On Thu, Jan 10, 2019 at 03:45:00AM +0000, n54@gmx.com wrote:
> > > Updating a mounted partition to MNT_UNION will lead to a panic.
> > I kinda think MNT_UPDATE ought not to be allowed to turn MNT_UNION on
> > and off, but if it otherwise works...
MNT_UNION is just a flag that makes the mount interpreted differently.
I don't think there is something intrinsic that it must not be set.
The problem here is that MNT_UNION is enabled for the root which is
not mounted on some existing vnode, thus mnt_coveredvnode is VPNULL.
In this case MNT_UNION doesn't make sense anyway, there is no lower
filesystem that could be visible through the root mount.
So either:
- make checks for MNT_UNION aware of VPNULL and ignore the flag,
there are 3 cases that do this.
Or:
- don't allow an update to set MNT_UNION if there is no covered
filesystem.
So maybe:
--- vfs_syscalls.c 9 Jan 2018 03:31:13 -0000 1.518
+++ vfs_syscalls.c 11 Jan 2019 06:05:13 -0000
@@ -278,6 +278,15 @@ mount_update(struct lwp *l, struct vnode
goto out;
}
+ /*
+ * Enabling MNT_UNION requires a covered mountpoint and
+ * must not happen on the root mount.
+ */
+ if ((flags & MNT_UNION) != 0 && mp->mnt_vnodecovered == VPNULL) {
+ error = EOPNOTSUPP;
+ goto out;
+ }
+
error = kauth_authorize_system(l->l_cred, KAUTH_SYSTEM_MOUNT,
KAUTH_REQ_SYSTEM_MOUNT_UPDATE, mp, KAUTH_ARG(flags), data);
if (error)
--
--
Michael van Elst
Internet: mlelstv@serpens.de
"A potential Snark may lurk in every tree."
From: "Michael van Elst" <mlelstv@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/53850 CVS commit: src/sys/kern
Date: Tue, 19 Feb 2019 06:55:28 +0000
Module Name: src
Committed By: mlelstv
Date: Tue Feb 19 06:55:28 UTC 2019
Modified Files:
src/sys/kern: vfs_syscalls.c
Log Message:
Don't allow MNT_UNION on the root, there is no covered filesystem.
Fixes PR 53850
To generate a diff of this commit:
cvs rdiff -u -r1.524 -r1.525 src/sys/kern/vfs_syscalls.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->closed
State-Changed-By: kamil@NetBSD.org
State-Changed-When: Tue, 19 Feb 2019 08:13:52 +0100
State-Changed-Why:
Fix committed.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.