The problem is alloc_blocks() will call get_next_block() which might
reallocate outdir->buf, and memory address could be changed after
this. To fix this, pointers that point into outdir->buf, such as
int_limit and root need to be recaulated based on the new starting
address of outdir->buf.
[ Changed to correctly recalculate int_limit, and to optimize how we
reallocate outdir->buf. -TYT ]
Addresses-Debian-Bug: 948517
Signed-off-by: Wang Shilong <wshilong@ddn.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 101e73e99c)
If directory has been deleted in pass1[bcd] processing, then we
shouldn't try to rehash the directory in pass 3a when we try to
rehash/reoptimize directories.
Addresses-Debian-Bug: 948508
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 71ba137553)
In e2fsck pass 3a, when we are rehashing directories, at least in
theory, all of the directories should have had corruptions with
respect to directory entry structure fixed. However, it's possible
(for example, if the user declined a fix) that we can reach this stage
of processing with a corrupted directory entries.
So check for that case and don't try to process a corrupted directory
block so we don't run into trouble in mutate_name() if there is a
zero-length file name.
Addresses-Debian-Bug: 948508
Addresses: TALOS-2019-0973
Addresses: CVE-2019-5188
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 8dd73c149f)
A maliciously corrupted file systems can trigger buffer overruns in
the quota code used by e2fsck. To fix this, add sanity checks to the
quota header fields as well as to block number references in the quota
tree.
Addresses: CVE-2019-5094
Addresses: TALOS-2019-0887
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
(cherry picked from commit 8dbe7b475e)
This reverts commit 3293ea9ecb.
This wasn't really the right fix, since there can't be more than 2**32
files in a file system. The real issue is when the number of files in
a directory change during the e4defrag run.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Port of commit 3271c69c97f486914fea833a36eaf5d86938c76d as applied to
e2fsck, but to tune2fs.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Bug: 112062612
Bug: 111302946
Test: $ m SANITIZE_HOST=address out/host/linux-x86/bin/tune2fs
$ out/host/linux-x86/bin/tune2fs --help
Change-Id: If49d367d96b7bfd0b8b79c6bde23c0ded52ca683
From AOSP commit: 1cb5de330e5d1e0c6f587945ec065b995cc1c84b
* New upstream version
* Avoid overflows when tracking the number of files defragged
by e4defrag (Closes: #888899)
* Fix groff formatting nits in various man pages (Closes: #916188)
* Fix location of libext2fs documentation (Closes: #915942)
* Fix regression so we are correctly translating Posix ACL's
in libext2fs
* Use the online free block counts so e2freefrag's percentages
are correct
* Fix a false warning that tune2fs will take long time to change
a UUID if the metadata_csum feature is not enabled
* Fix mk_cmds so it works on a usrmerge system when e2fsprogs is built
on a non-usrmerge system (Closes: #914087)
* E2fsck will avoid offering to set the inline_data feature flag
unnecessarily
* E4defrag will handle the case where it is running as root and it can't
find the file system to open more gracefully (Closes: #907634)
* Fix a bug where resize2fs was failing to update the extent tree
checksums in an corner case
* Fix fuse2fs's command line parsing when options are specified after
the target device/image
* Fix a bug which could cause e2fsprogs tools to segfault on a corrupted
file system where the journal's s_nr_users is impossibly large.
* E2image now includes the mmp block (if needed) when creating a
metadata-only image.
* When e2fsck notices it could optimize an extent tree, it will now ask
"Optimize?" instead of "Fix?", which was confusing some users since it
implied that something was broken.
[dgit import unpatched e2fsprogs 1.44.5-1]
If e2fsck can optimize an inode's extent tree, it should ask for
permission to optimize it, not to "fix" it. This was causing some
confusion, since some users interpreted this prompt as an indication
that the file system was inconsistent.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Change a two-fonts macro to a one-font one, when there is only one
genuine argument.
Separate a punctuation mark or a section number from the only argument
to make two for a two-fonts macro.
Remove an unneeded escape in front of a horizontal tab character.
Correct the unit for distance from 'in' to 'i'.
Signed-off-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The commit 50d0998cfe ("libext2fs: add ea_inode support to set
xattr") broke the fix that was addressed in commit 0ee1eaf70c
("libext2fs: translate internal ext4 acl to Posix ACL in
ext2fs_xattr_[sg]et()"). This was because although we calculated what
the correct on-disk ACL representation would be, we didn't actually
*store* it, but instead stored the passed-in Posix ACL memory
representation instead.
Addresses-Launchpad-Bug: #1807288
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In e2freefrag live scan mode, we take the free block count from the
ondisk superblock. This leads to screwy histogram percentages:
Extent Size Range : Free extents Free Blocks Percent
4M... 8M- : 5 8234 1.05%
64M... 128M- : 2 52279 6.64%
512M... 1024M- : 1 202752 25.74%
...because there could be superblock updates in the journal that haven't
yet been checkpointed. The online scan is perfectly capable of tallying
the free blocks on its own, so teach it do that and make a more accurate
report.
Reported-by: Elana Hashman <Elana.Hashman@twosigma.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If the file system only has the flex_bg feature enabled (with out the
metadata_csum feature enabled), it won't take a long time time fix up
the checksums after changing the UUID. While it does need to
recalculate all of the checksums in the block group descriptors, that
doesn't take a long time.
Also, if the ea_data feature is enabled, changing the UUID will also
take a long time, and we weren't warning the user about that case.
Fix up the warning message so it doesn't mislead people, and is more
accurate.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
$AWK doesn't use an explicit pathname, and it's perfectly fine to
assume that awk and sed are in the user's PATH. The problem with
using an explicit pathname is that Debian currently allows merged and
non-merged /usr. Avoid using an explicit pathname to prevent
potential problems.
Addresses-Debian-Bug: #914087
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
ext2fs_inline_data_size will happy return 0 and set size to
EXT4_MIN_INLINE_DATA_SIZE even when inode doesn't have
xattr 'system.data', a corrupted i_flags could make e2fsck
enable the inline_data on the superblock.
We should only offer to enable inline_data when i_flags is set
and xattr 'system.data' can be found.
Also use correct prompt for PR_1_INLINE_DATA_FEATURE.
Signed-off-by: Li Dongyang <dongyangli@ddn.com>
If e4defrag is run by root, it will try to open the underlying file
system for files that it is trying to defrag so it can get the file
system parameters. It's currently doing this by searching /etc/mtab.
This isn't the best way to go about doing things, but we'll leave it
for now, at least for a maintenance release. (The better way to do
things would be to look up the device using the blkid library, but
that's a more involved change.)
Since the file system parameters isn't strictly speaking necessary
(after all we get by without them when not running as root), we'll
allow e4defrag to continue running if we can't find the file system.
This can happen if /etc/mtab is pointing at /proc/mounts, and the
kernel can't properly identify the root file system, it is reported as
"/dev/root".
Addresses-Debian-Bug: #907634
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Add a test case for the bug fixed in 4b3038134b: "resize2fs: update
checksums in the extent tree's relocated block"
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
When shrinking an file system, and we need to relocate an inode, the
checksums in its extent tree must get updated to reflect its new inode
number. When doing this, we need to do this *after* we update the
extent tree to reflect any blocks which need to be relocated due to
the file system shrink operation.
Otherwise, in the case where only an interior node of the extent tree
needs to get relocated, and none of the entries in that node need to
be adjusted, the checksum for that interior node is updated in the old
copy of that block, and then after the extent tree is updated to use
the new copy of that interior node, the extent tree is left with an
invalid checksum.
This is a relatively rare case, since it requires the following
conditions to be true:
*) The metadata checksum feature must be enabled.
*) An inode needs to be relocated.
*) The inode needs to have an interior node.
*) The block for that interior node needs to be relocated.
*) None of blocks addressed by entries in that interior node needs
to be relocated.
When all of these conditions are true, though, the file system is left
with corrupted with bad checksum for the extent tree block.
Addresses-Launchpad-Bug: 1798562
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: Jean-Baptiste Lallement <jean-baptiste.lallement@ubuntu.com>
FUSE's parser allows command-line options to be specified before
or after the device/image and mount-path. This commit changes the
value of the fsname mount option to be correct even if options are
specified before the target device/image.
Signed-off-by: Nicholas Clark <nicholas.clark@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
There are a number of error conditions which, due to the way
ext2fs_dir_iterate2 operates, would not be propagated to the upper
layers of the call stack. As a result, certain error conditions,
such as not having enough room to allocate blocks for SELinux
labels, would fail silently, instead of causing a compile
failure.
As suggested in
https://android-review.googlesource.com/c/platform/external/e2fsprogs/+/324363
, add a error field to the caller's private data structure, and use the
bit in the field to indicate an error condition. Now, certain errors
which were silently ignored will cause a compile failure when compiling
Android.
Test: Artifically modify selabel_lookup() to return a failure, and
verify Android doesn't compile.
Test: Verify Android compiles under normal circumstances.
Test: Artifically modify ino_add_xattr() to return a failure, and
verify Android doesn't compile.
Bug: 117502873
Bug: 117567573
Bug: 117473440
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Change-Id: Icdb0105a77e98c3428f20d3c59bf824dcad5db8d
From AOSP commit: 7ca13b8b2953f93536ea09eb2ff19bd7cc85b3c1
f_detect_junk will skip the test by exiting; and in that case we need
to make sure the test's tmpfile gets cleaned up.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The __GNUC_PREREQ convenience macro is defined by glibc's header
files. If it isn't available, make it available for us to use.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Currently in e2fsprogs tools it's possible to access out of bounds
memory when reading list of ids sharing a journal log
(journal_superblock_t->s_users[]) in case where s_nr_users is too high.
This is because we never check whether the s_nr_users fits into the
restriction of JFS_USERS_MAX. Fix it by checking that nr_users is not
bigger than JFS_USERS_MAX and error out when possiblem.
Also add test for dumpe2fs. The rest would require involving external
journal which is not possible to test with e2fsprogs test suite at the
moment.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The e2fsprogs-libs-1.44.x.tar.gz subset distribution had a hack so
that "make install" would install the libraries via an implied "make
install-libs" --- since after all the tarball had was just the
libraries.
This commit makes "make install" behave the same was as the
e2fsprogs-libs distribution in the case of "configure --enable-subset"
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
