Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Sep 1995 20:58:16 +1000
From:      Bruce Evans <bde@zeta.org.au>
To:        davidg@root.com, terry@lambert.org
Cc:        current@freebsd.org, mckusick@mckusick.com
Subject:   Re: BAD BUG IN UFS RENAME
Message-ID:  <199509131058.UAA05201@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> >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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509131058.UAA05201>