From: Theodore Ts'o <tytso@mit.edu>
To: Ext4 Developers List <linux-ext4@vger.kernel.org>
Cc: jslaby@suse.cz, adilger@dilger.ca, Theodore Ts'o <tytso@mit.edu>,
stable@vger.kernel.org
Subject: [PATCH -v2] ext4: avoid arithemetic overflow that can trigger a BUG
Date: Sat, 1 Sep 2018 12:49:27 -0400 [thread overview]
Message-ID: <20180901164927.15260-1-tytso@mit.edu> (raw)
In-Reply-To: <20180901025003.GB27277@thunk.org>
A maliciously crafted file system can cause an overflow when the
results of a 64-bit calculation is stored into a 32-bit length
parameter.
https://bugzilla.kernel.org/show_bug.cgi?id=200623
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: Wen Xu <wen.xu@gatech.edu>
Cc: stable@vger.kernel.org
---
This is a revised version which checks for overflows when caluclating
first_block and last_block. This catches more overflow scenarios than
just checking for an overflow when calculating map.m_len.
fs/ext4/ext4.h | 3 +++
fs/ext4/inode.c | 8 ++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 249bcee4d7b2..ac05bd86643a 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -686,6 +686,9 @@ enum {
/* Max physical block we can address w/o extents */
#define EXT4_MAX_BLOCK_FILE_PHYS 0xFFFFFFFF
+/* Max logical block we can support */
+#define EXT4_MAX_LOGICAL_BLOCK 0xFFFFFFFF
+
/*
* Structure of an inode on the disk
*/
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 8f6ad7667974..694f31364206 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3412,12 +3412,16 @@ static int ext4_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
{
struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
unsigned int blkbits = inode->i_blkbits;
- unsigned long first_block = offset >> blkbits;
- unsigned long last_block = (offset + length - 1) >> blkbits;
+ unsigned long first_block, last_block;
struct ext4_map_blocks map;
bool delalloc = false;
int ret;
+ if ((offset >> blkbits) > EXT4_MAX_LOGICAL_BLOCK)
+ return -EINVAL;
+ first_block = offset >> blkbits;
+ last_block = min_t(loff_t, (offset + length - 1) >> blkbits,
+ EXT4_MAX_LOGICAL_BLOCK);
if (flags & IOMAP_REPORT) {
if (ext4_has_inline_data(inode)) {
--
2.18.0.rc0
prev parent reply other threads:[~2018-09-01 16:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-31 17:41 [PATCH] ext4: avoid arithemetic overflow that can trigger a BUG Theodore Ts'o
2018-08-31 19:31 ` Andreas Dilger
2018-09-01 2:49 ` Theodore Y. Ts'o
2018-08-31 19:31 ` Jiri Slaby
2018-09-01 2:50 ` Theodore Y. Ts'o
2018-09-01 16:49 ` Theodore Ts'o [this message]
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=20180901164927.15260-1-tytso@mit.edu \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=jslaby@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=stable@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.