All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Andreas Dilger <adilger@whamcloud.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH] e2fsck: avoid overflow with very large dirs
Date: Wed, 4 Mar 2020 18:39:11 -0500	[thread overview]
Message-ID: <20200304233911.GI74069@mit.edu> (raw)
In-Reply-To: <1581469641-85696-1-git-send-email-adilger@whamcloud.com>

On Tue, Feb 11, 2020 at 06:07:21PM -0700, Andreas Dilger wrote:
> In alloc_size_dir() it multiples signed ints when allocating the
> buffer for rehashing an htree-indexed directory.  This will overflow
> when the directory size is above 4GB, which is possible with largedir
> directories having about 100M entries, assuming an average 3/4 leaf
> fullness and 24-byte filenames, or fewer with longer filenames.
> The same problem exisgs in get_next_block().
> 
> Similarly, the out_dir struct used a signed int for the number of
> blocks in the directory, which may result in a negative size if the
> directory is over 2GB (about 50M entries or fewer).
> 
> Use appropriate unsigned variables for block counts, and use larger
> types for calculating the byte count for memory offsets/sizes.
> 
> Such large directories not been seen yet, but are not too far away.
> The ext2fs_get_array() function will properly calculate the needed
> memory allocation, and detect overflow on 32-bit systems.
> Add ext2fs_resize_array() to do the same for array resize.
> 
> Signed-off-by: Andreas Dilger <adilger@whamcloud.com>
> Lustre-bug-id: https://jira.whamcloud.com/browse/LU-13197

Applied, thanks.  I had to make a slight change to fix a "merge
conflict" with the patch.

					- Ted

  reply	other threads:[~2020-03-04 23:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07  1:09 [PATCH 1/9] e2fsck: fix e2fsck_allocate_memory() overflow Andreas Dilger
2020-02-07  1:09 ` [PATCH 2/9] e2fsck: use proper types for variables Andreas Dilger
2020-02-29 23:27   ` Theodore Y. Ts'o
2020-02-07  1:09 ` [PATCH 3/9] e2fsck: avoid mallinfo() if over 2GB allocated Andreas Dilger
2020-02-29 23:28   ` Theodore Y. Ts'o
2020-02-07  1:09 ` [PATCH 4/9] e2fsck: reduce memory usage for many directories Andreas Dilger
2020-02-29 23:29   ` Theodore Y. Ts'o
2020-02-07  1:09 ` [PATCH 5/9] debugfs: allow comment lines in command file Andreas Dilger
2020-02-29 23:32   ` Theodore Y. Ts'o
2020-02-07  1:09 ` [PATCH 6/9] debugfs: print inode numbers as unsigned Andreas Dilger
2020-02-29 23:34   ` Theodore Y. Ts'o
2020-02-07  1:09 ` [PATCH 7/9] e2fsck: fix overflow if more than 4B inodes Andreas Dilger
2020-02-29 23:35   ` Theodore Y. Ts'o
2020-02-07  1:09 ` [PATCH 8/9] e2fsck: consistently use ext2fs_get_mem() Andreas Dilger
2020-02-29 23:36   ` Theodore Y. Ts'o
2020-03-04 23:23     ` Theodore Y. Ts'o
2020-02-07  1:09 ` [PATCH 9/9] misc: handle very large files with filefrag Andreas Dilger
2020-03-04 23:27   ` Theodore Y. Ts'o
2020-02-12  0:58 ` [PATCH] " Andreas Dilger
2020-02-12  1:09   ` Andreas Dilger
2020-02-12  1:07 ` [PATCH] e2fsck: avoid overflow with very large dirs Andreas Dilger
2020-03-04 23:39   ` Theodore Y. Ts'o [this message]
2020-02-29 23:25 ` [PATCH 1/9] e2fsck: fix e2fsck_allocate_memory() overflow Theodore Y. Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200304233911.GI74069@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger@whamcloud.com \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.