Re: uninitialized buffer in midnight commander (fwd)

[Pavel Roskin <proski gnu org>]

On Fri, 10 Oct 2003, Pavel Machek wrote:

> From bugtraq, I hope it was not here before.

I have fixed it.  There were two bugs in vfs_s_resolve_symlink() - one was
in the code for archives (tarfs, cpiofs) and the other in the code for the
networked systems (fish, ftpfs).

The archive support code tried to convert the symlink target to a relative
path.  The reason why this was needed is because vfs_s_fullpath() wasn't
implemented for archives, so the tree had to be traversed from the current
directory.  I implemented it.

Now vfs_s_resolve_symlink() uses the same code for different VFS types (I
call them subclasses because they all are based on direntry.c).  It used
vfs_s_fullpath() to get the current path, adds the link target to it and
finds the entry starting from the VFS root.

The network support code was simply using a fixed buffer without necessary
checks.  I fixed it too by using allocated memory, but I had to add
protection against too long strings in vfs_s_find_entry_tree(), which is
still using a fixed buffer.

Later I had to add canonicalize_path() in the beginning of
vfs_s_find_entry_tree() when it turned out that this function has problems
following ".." entries.

The changes can be backported to 4.6.0 if anybody cares.  But there is
still a lot of undocumented code and buffers of limited size.  I don't
want anybody to assume that VFS is safe.

There is another one VFS bug that kills mc sometimes.  Midnight Commander
can crash when it enters several VFS types in the same time.  Try running
this command them the mc prompt:

cd /#ftp:ftp.rutgers.edu/pub/redhat/linux/updates/8.0/en/os/i386/cups-libs-1.1.17-0.2.i386.rpm#rpm

mc with hang, crash or work without visible problems, but Valgrind always
detects that something is wrong here:

Invalid write of size 4
    at 0x80C1061: vfs_rmstamp (vfs.c:361)
    by 0x80C2225: _vfs_add_noncurrent_stamps (vfs.c:778)
    by 0x80C24A2: vfs_add_noncurrent_stamps (vfs.c:844)
    by 0x80C26B1: mc_chdir (vfs.c:918)

I still don't understand how stamping works, in particular the role of
getid functions.  It appears that something is happening in the wrong
order, which causes corruption of the stamp chain.

I cannot say if it can be exploited until the bug is fixed.  VFS
specialists are welcome to help.

-- 
Regards,
Pavel Roskin