From owner-freebsd-current  Wed Sep 13 04:00:10 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id EAA21634
          for current-outgoing; Wed, 13 Sep 1995 04:00:10 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA21627
          for <current@freebsd.org>; Wed, 13 Sep 1995 04:00:05 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id UAA05201; Wed, 13 Sep 1995 20:58:16 +1000
Date: Wed, 13 Sep 1995 20:58:16 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199509131058.UAA05201@godzilla.zeta.org.au>
To: davidg@root.com, terry@lambert.org
Subject: Re: BAD BUG IN UFS RENAME
Cc: current@freebsd.org, mckusick@mckusick.com
Sender: current-owner@freebsd.org
Precedence: bulk

>> >Well, I've discovered some very interesting brain damage.
>> >
>> >In the case of an attemped cross-device rename, both NAMEI buffers are
>> >freed twice.
>> 
>>    Yes, I think I see this - the VOP_ABORTOP's on both cn buffers, followed by
>> the explicit free's in rename()?

>Yes.  It's not obvious because they check the HASBUF in the VOP_ABORTOP;
>the actual rename stuff will work for UFS, assuming that there aren't
>any cascade errors, but not for other file systems.  This because they
>check that the SAVESTART bit isn't set to determine the free behaviour.

>So it's not as blatant as it would seem the first time you glance at it;

I think it's not even actual.  rename() sets SAVESTART for the source and
the destination (nothing else in /sys/kern sets SAVESTART); many functions
in nfs_serv.c set SAVESTART.  All ABORTOPs are check SAVESTART like they
are supposed to and don't free the buffer if SAVESTART is set; thus there
is no problem in ufs_rename().

The braindamage, if any, is in the layering that sometimes requires the
callee to free the buffer, and perhaps in the non-clearing and non-checking
of HASBUF after the buffer has been freed, and perhaps in the overloading
of SAVESTART and/or the non-use of SAVENAME in the ABORTOPs to decide
whether the callee should free the buffer.

>This could very well be the MSDOSFS rename bug.

Nope, there are several known msdosfs rename bugs, all known to be
different.  (E.g., one is also a ufs rename bug: things have to be unlocked
before calling checkpath() to avoid deadlock, but this allows races
in checkpath().  Bad effects are easy to demonstrate by putting a tsleep()
in checkpath() before the call to VFS_VGET() and removing a critical
file or directory during the simulated blockage of VFS_VGET().)

Bruce