[PATCH 1/2] ext4: lock i_mutex when truncating orphan inodes

[PATCH 1/2] ext4: lock i_mutex when truncating orphan inodes

[Theodore Ts'o]

Commit c278531d39f3 added a warning when ext4_flush_unwritten_io() is
called without i_mutex being taken.  It had previously not been taken
during orphan cleanup since races weren't possible at that point in
the mount process, but as a result of this commit, we will now see a
kernel WARN_ON in this case.  Take the i_mutex in
ext4_orphan_cleanup() to suppress this warning.

Reported-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
---
 fs/ext4/super.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 183ae34..3d4fb81 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2220,7 +2220,9 @@ static void ext4_orphan_cleanup(struct super_block *sb,
 				__func__, inode->i_ino, inode->i_size);
 			jbd_debug(2, "truncating inode %lu to %lld bytes\n",
 				  inode->i_ino, inode->i_size);
+			mutex_lock(&inode->i_mutex);
 			ext4_truncate(inode);
+			mutex_unlock(&inode->i_mutex);
 			nr_truncates++;
 		} else {
 			ext4_msg(sb, KERN_DEBUG,
-- 
1.7.12.rc0.22.gcdd159b

[PATCH 2/2] ext4: avoid hang when mounting non-journal filesystems with orphan list

[Theodore Ts'o]

When trying to mount a file system which does not contain a journal,
but which does have a orphan list with an inode which needs to be
truncated, the mount call with hang forever in ext4_orphan_cleanup()
because ext4_orphan_del() will return immediately if no journal is
present.

This can be trivially reproduced by trying to mount the file system
found in tests/f_orphan_extents_inode/image.gz in the e2fsprogs
sources.  If a malicious user were to put this on a USB stick, and
mount it on a Linux desktop which automatically mounts newly inserted
USB sticks, this could be considered a potential denial of service
attack.  (Not a big deal in practice, but professional paranoids worry
about such things, and have even been known to allocate CVE numbers
on occasion.)

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
---
 fs/ext4/namei.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index cac4482..8990165 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -2648,7 +2648,8 @@ int ext4_orphan_del(handle_t *handle, struct inode *inode)
 	struct ext4_iloc iloc;
 	int err = 0;
 
-	if (!EXT4_SB(inode->i_sb)->s_journal)
+	if ((!EXT4_SB(inode->i_sb)->s_journal) &&
+	    !(EXT4_SB(inode->i_sb)->s_mount_state & EXT4_ORPHAN_FS))
 		return 0;
 
 	mutex_lock(&EXT4_SB(inode->i_sb)->s_orphan_lock);
-- 
1.7.12.rc0.22.gcdd159b

Re: [PATCH 1/2] ext4: lock i_mutex when truncating orphan inodes

[Zheng Liu]

On Thu, Dec 27, 2012 at 01:43:14AM -0500, Theodore Ts'o wrote:
> Commit c278531d39f3 added a warning when ext4_flush_unwritten_io() is
> called without i_mutex being taken.  It had previously not been taken
> during orphan cleanup since races weren't possible at that point in
> the mount process, but as a result of this commit, we will now see a
> kernel WARN_ON in this case.  Take the i_mutex in
> ext4_orphan_cleanup() to suppress this warning.
> 
> Reported-by: Alexander Beregalov <a.beregalov@gmail.com>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> Cc: stable@vger.kernel.org

Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>

Regards,
                                        - Zheng

Re: [PATCH 2/2] ext4: avoid hang when mounting non-journal filesystems with orphan list

[Zheng Liu]

On Thu, Dec 27, 2012 at 01:43:15AM -0500, Theodore Ts'o wrote:
> When trying to mount a file system which does not contain a journal,
> but which does have a orphan list with an inode which needs to be
> truncated, the mount call with hang forever in ext4_orphan_cleanup()
> because ext4_orphan_del() will return immediately if no journal is
> present.
> 
> This can be trivially reproduced by trying to mount the file system
> found in tests/f_orphan_extents_inode/image.gz in the e2fsprogs
> sources.  If a malicious user were to put this on a USB stick, and
> mount it on a Linux desktop which automatically mounts newly inserted
> USB sticks, this could be considered a potential denial of service
> attack.  (Not a big deal in practice, but professional paranoids worry
> about such things, and have even been known to allocate CVE numbers
> on occasion.)
> 
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> Cc: stable@vger.kernel.org

Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>

Regards,
                                        - Zheng