Linux EXT4 FS development
 help / color / mirror / Atom feed
From: Murphy Zhou <jencce.kernel@gmail.com>
To: linux-ext4@vger.kernel.org
Cc: riteshh@linux.ibm.com
Subject: [PATCH] ext4: validate fiemap iomap begin offset and length value
Date: Sun, 19 Apr 2020 07:32:31 +0800	[thread overview]
Message-ID: <20200418233231.z767yvfiupy7hwgp@xzhoux.usersys.redhat.com> (raw)

Sometimes crazy userspace values can be here causing overflow issue.

After moved ext4_fiemap to using the iomap framework in
  commit d3b6f23f7167 ("ext4: move ext4_fiemap to use iomap framework")
we can hit the WARN_ON at fs/iomap/apply.c:51, then get an EIO error
running xfstests generic/009 (and some others) on ext4 based overlayfs.

The minimal reproducer is:
-------------------------------------
fallocate -l 256M test.img
mkfs.ext4 -Fq -b 4096 -I 256 test.img
mkdir -p test
mount -o loop test.img test || exit
pushd test
rm -rf l u w m
mkdir -p l u w m
mount -t overlay -o lowerdir=l,upperdir=u,workdir=w overlay m || exit
xfs_io -f -c "pwrite 0 4096" -c "fiemap"  m/tf
umount m
rm -rf l u w m
popd
umount -d test
rm -rf test test.img
-------------------------------------

Because we run fiemap command wo/ the offset and length parameters,
xfs_io set values based on fs blocksize etc which is got from
the mounted fs. These values xfs_io passed are way larger on overlayfs
than ext4 directly. So we can't reproduce this directly on ext4 or xfs.
I tried to call ioctl directly with large length value but failed to
reproduce this.

I did not try to get what values xfs_io exactly passing in, but I
confirmed that overflowed value when it made into _ext4_fiemap.
It's a length of 0x7fffffffffffffff which will mess up the calculation
of map.m_lblk and map.m_len, make map.m_len to be 0, then hit WARN_ON
and get EIO in iomap_apply.

Fixing this by ensuring the offset and length values wont exceed
EXT4_MAX_LOGICAL_BLOCK. Also make sure that the length would not
be zero because of crazy overflowed values.

This patch has been tested with LTP/xfstests showing no new issue.

Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com>
Fixes: d3b6f23f7167 ("ext4: move ext4_fiemap to use iomap framework")
---
 fs/ext4/inode.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e416096..3620417 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3523,6 +3523,8 @@ static int ext4_iomap_begin_report(struct inode *inode, loff_t offset,
 	int ret;
 	bool delalloc = false;
 	struct ext4_map_blocks map;
+	ext4_lblk_t last_lblk;
+	ext4_lblk_t lblk;
 	u8 blkbits = inode->i_blkbits;
 
 	if ((offset >> blkbits) > EXT4_MAX_LOGICAL_BLOCK)
@@ -3540,9 +3542,18 @@ static int ext4_iomap_begin_report(struct inode *inode, loff_t offset,
 	/*
 	 * Calculate the first and last logical block respectively.
 	 */
-	map.m_lblk = offset >> blkbits;
-	map.m_len = min_t(loff_t, (offset + length - 1) >> blkbits,
-			  EXT4_MAX_LOGICAL_BLOCK) - map.m_lblk + 1;
+	lblk = offset >> blkbits;
+	last_lblk = (offset + length - 1) >> blkbits;
+
+	if (last_lblk >= EXT4_MAX_LOGICAL_BLOCK)
+		last_lblk = EXT4_MAX_LOGICAL_BLOCK - 1;
+	if (lblk >= EXT4_MAX_LOGICAL_BLOCK)
+		lblk = EXT4_MAX_LOGICAL_BLOCK - 1;
+
+	map.m_lblk = lblk;
+	map.m_len = last_lblk - lblk + 1;
+	if (map.m_len == 0 )
+		map.m_len = 1;
 
 	/*
 	 * Fiemap callers may call for offset beyond s_bitmap_maxbytes.
-- 
1.8.3.1

             reply	other threads:[~2020-04-18 23:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-18 23:32 Murphy Zhou [this message]
2020-04-19  1:56 ` [PATCH] ext4: validate fiemap iomap begin offset and length value Ritesh Harjani
2020-04-19  4:42   ` Theodore Y. Ts'o
2020-04-19  4:46     ` Theodore Y. Ts'o
2020-04-19 16:19       ` Ritesh Harjani
2020-04-20  2:57         ` Murphy Zhou
2020-04-20  4:16           ` Ritesh Harjani
2020-04-20  7:03             ` Ritesh Harjani
2020-04-20  7:27             ` Murphy Zhou
2020-04-20 13:48               ` Ritesh Harjani

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=20200418233231.z767yvfiupy7hwgp@xzhoux.usersys.redhat.com \
    --to=jencce.kernel@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=riteshh@linux.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox