Package: e2fsprogs / 1.44.5-1+deb10u3


Package Version Patches format
e2fsprogs 1.44.5-1+deb10u3 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
revert e4defrag use 64 bit counters to t.patch | (download)

misc/e4defrag.c | 26 14 + 12 - 0 !
1 file changed, 14 insertions(+), 12 deletions(-)

 revert "e4defrag: use 64-bit counters to track # files defragged"

This reverts commit 3293ea9ecbe1d622f9cf6c41d705d82fbae6a3e3.

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 <>

libsupport add checks to prevent buffer .patch | (download)

lib/support/mkquota.c | 1 1 + 0 - 0 !
lib/support/quotaio_tree.c | 71 47 + 24 - 0 !
lib/support/quotaio_v2.c | 28 28 + 0 - 0 !
3 files changed, 76 insertions(+), 24 deletions(-)

 libsupport: add checks to prevent buffer overrun bugs in quota code

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

Addresses: CVE-2019-5094
Addresses: TALOS-2019-0887
Signed-off-by: Theodore Ts'o <>
(cherry picked from commit 8dbe7b475ec5e91ed767239f0e85880f416fc384)

e2fsck abort if there is a corrupted directory block.patch | (download)

e2fsck/rehash.c | 9 9 + 0 - 0 !
1 file changed, 9 insertions(+)

 e2fsck: abort if there is a corrupted directory block when rehashing

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 <>
(cherry picked from commit 8dd73c149f418238f19791f9d666089ef9734dff)

e2fsck don t try to rehash a deleted directory.patch | (download)

e2fsck/pass1b.c | 4 4 + 0 - 0 !
e2fsck/rehash.c | 2 2 + 0 - 0 !
2 files changed, 6 insertions(+)

 e2fsck: don't try to rehash a deleted directory

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 <>
(cherry picked from commit 71ba13755337e19c9a826dfc874562a36e1b24d3)

e2fsck fix use after free in calculate_tree.patch | (download)

e2fsck/rehash.c | 17 16 + 1 - 0 !
1 file changed, 16 insertions(+), 1 deletion(-)

 e2fsck: fix use after free in calculate_tree()

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 <>
Signed-off-by: Theodore Ts'o <>
(cherry picked from commit 101e73e99ccafa0403fcb27dd7413033b587ca01)