NetBSD Problem Report #1677

From gnats  Mon Oct 23 19:28:14 1995
Received: from bloom-beacon.MIT.EDU by (8.6.9/8.6.9) with ESMTP id TAA29725 for <>; Mon, 23 Oct 1995 19:27:47 -0400
Message-Id: <>
Date: Mon, 23 Oct 1995 19:10:21 -0400
From: John Kohl <>
Cc: Trevin Beattie <>,
Subject: union FS can return bogus value for lookup of `.', causing later panic
X-Send-Pr-Version: 3.95

>Number:         1677
>Category:       kern
>Synopsis:       union FS can return bogus value for lookup of `.', causing later panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct 23 19:35:03 +0000 1995
>Last-Modified:  Sun Mar 26 19:45:00 +0000 2017
>Originator:     John Kohl
>Release:        1.1_ALPHA
NetBSD Kernel Hackers `R` Us

System: NetBSD pattern 1.1_ALPHA NetBSD 1.1_ALPHA (PATTERN) #195: Sun Oct 22 13:31:09 EDT 1995 jtk@pattern:/u1/NetBSD-current/src/sys/arch/i386/compile/PATTERN i386

If the union FS is looking up `.' in a directory  which is searchable in
the top level but unsearchable in the bottom level, it returns a union vnode
that is not the same as the starting vnode.  This returned vnode is only
half-locked, in that another union vnode points to the same lower layer

Because the lower layer could not be looked up, union_lookup() called
union_allocvp() with lowervp == NULLVP.  This resulted in
union_allocvp() failing to find the "real" cached vnode for `.' and it
creates a new one.  The new one has UN_LOCKED set, and the uppervp is
indeed locked, but the lock was taken on behalf of the "real" vnode for `.'

This causes trouble in things like sys_lstat() and it kin which have
code like:
	    SCARG(uap, path), p);
	if (error = namei(&nd))
		return (error);
	vp = nd.ni_vp;
	dvp = nd.ni_dvp;
		if (dvp == vp)
		error = vn_stat(vp, &sb, p);
		if (error)
			return (error);

The second vput() results in a panic from UFS (if DIAGNOSTIC) when it
attempts to unlock an unlocked UFS vnode.

1) in the lower layer:
	mkdir Foo
	chmod 700 Foo
	chown otheruser Foo
2) in the upper layer:
	mkdir Foo
3) mount the union FS
4) ls -la /union_mountpoint/Foo
5) watch the machine croak

Not sure what the "right thing" is.  Maybe short-circuit `.'?

What about other cases where some user might not have the appropriate
lookup permissions in the lower layer?  It seems like we must never let
union_allocvp() be called in such a way as to generate two union vnodes
for the same underlying object.
Subject: Re: kern/1677: union FS can return bogus value for lookup of `.',
 causing later panic
Date: Sun, 26 Mar 2017 19:40:53 +0000

 I believe this bug was fixed, I can't reproduce it.


NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.