This addresses a potential security vulnerability where an untrusted
filesystem can be corrupted in such a way that a program using
libext2fs will allocate a buffer which is far too small. This can
lead to either a crash or potentially a heap-based buffer overflow
crash. No known exploits exist, but main concern is where an
untrusted user who possesses privileged access in a guest Xen
environment could corrupt a filesystem which is then accessed by the
pygrub program, running as root in the dom0 host environment, thus
allowing the untrusted user to gain privileged access in the host OS.
Thanks to the McAfee AVERT Research group for reporting this issue.
Addresses CVE-2007-5497.
Signed-off-by: Rafal Wojtczuk <rafal_wojtczuk@mcafee.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If fs->now is non-zero, use that as the time instead of the system
time when setting various filesystem fields (last modified time, last
write time, etc.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
any debugging statements from within library code (always a bad idea), and
ext2fs_create_resize_inode() will return a proper error code if the
resize inode is corrupt, instead of returning -1.
res_gdt.c (list_backups), closefs.c (ext2fs_bg_has_super),
ext2fs.h: Move ext2fs_list_backups() to res_gdt.c, and
ext2fs_bg_has_super() back to closefs.c. There's no
reason for the new file, since list_backups() isn't being
used by any other functions, and can be made static, and
all users of the ext2fs filesystem will have to call
ext2fs_close() anyway.
Theodore Ts'o