Date: Tue, 13 Jun 2000 06:08:42 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Marius Bendiksen <mbendiks@eunet.no> Cc: security@FreeBSD.ORG Subject: Re: msdosfs_vnops.c : msdosfs_rename() Message-ID: <Pine.BSF.4.21.0006130546390.868-100000@besplex.bde.org> In-Reply-To: <Pine.BSF.4.05.10006122110530.703-100000@login-1.eunet.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Jun 2000, Marius Bendiksen wrote:
> It would appear to me that, in the following section, there is the
> potential for a malicious user to cause a system panic. Could anyone
> confirm/disaffirm this?
>
> if (fvp == NULL) {
> /*
> * From name has disappeared
> */
> if (doingdirectory)
> panic("rename: lost dir entry");
No, this can only happen if there is a filesystem bug.
> This is after rescanning the directory during a rename operation. Neither
> the directory, nor the entry, is locked at this point, according to the
> comments in the source.
It is supposed to be locked by setting IN_RENAME in ip->i_flag. Note that
IN_RENAME is only set in the doingdirectory case.
I don't completely trust relookup(), however. In theory, the filesystem
tree may be almost arbitrarily rearranged while relookup() sleeps, since
relookup() doesn't hold many locks (in particular, it doesn't hold locks
on the directories being changed or their parents or grandparents until
it searches back down to them). I once made this happen in practice by
forcing some long sleeps and doing the rearrangement in another process.
There seemed to be problems, but I wasn't sure and have forgotten the
details.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006130546390.868-100000>