uninitialized buffer in midnight commander (fwd)
Pavel Roskin
proski at gnu.org
Mon Oct 13 13:58:27 UTC 2003
On Fri, 10 Oct 2003, Pavel Machek wrote:
> >From bugtraq, I hope it was not here before.
Yes, it was here. There are several problems in vfs_s_resolve_symlink().
One is that buffer. Either the buffer for the symlink should be allocated
dynamically, or the function should return an error it the symlink won't
fit.
Another problem is that the code for converting absolute symlinks to the
relative once is incorrect. Buffer buf is never initialized, but the
first operation done on it is strcat(), which appends text to the end. If
the names (symlink and its target) have a common part that doesn't end
with slash (like dir1/file and dir2/file), only the path pointer (p) is
rewound back to the slash. I'm considering if diff_two_paths() in
src/util.c can be used for that.
There is one more thing I don't understand. Symlinks are converted to
relative path only for filesystems that don't use vfs_s_find_entry_linear,
i.e. cpiofs and tarfs. fish and ftpfs are not affected. I would expect
exactly the opposite behavior, because ftpfs and fish represent full
filesystems starting with the root, while cpiofs and tarfs represent
archived parts of the filesystem.
When I found all that, I realized that either I'm missing something or VFS
is in a very bad shape. I've spend this weekend trying to understand VFS
and clean it up a little bit. Among other things, I could separate
extfs.c from xdirentry.h to ensure that changes in vfs_s_resolve_symlink()
will only affect vfs_s descendants, namely cpiofs, tarfs, ftpfs and fish.
I hope I'll be able to fix all problems with vfs_s_resolve_symlink() in
the next few days. You help will be appreciated.
--
Regards,
Pavel Roskin
More information about the mc-devel
mailing list