From patchwork Fri Jan 16 16:59:08 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Theodore Ts'o X-Patchwork-Id: 19008 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 495C9DE1D8 for ; Sat, 17 Jan 2009 03:59:17 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754028AbZAPQ7N (ORCPT ); Fri, 16 Jan 2009 11:59:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755275AbZAPQ7N (ORCPT ); Fri, 16 Jan 2009 11:59:13 -0500 Received: from thunk.org ([69.25.196.29]:45250 "EHLO thunker.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754028AbZAPQ7L (ORCPT ); Fri, 16 Jan 2009 11:59:11 -0500 Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1LNs2G-0003dc-V8; Fri, 16 Jan 2009 11:59:09 -0500 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1LNs2G-0003ak-4l; Fri, 16 Jan 2009 11:59:08 -0500 From: Theodore Ts'o To: Ext4 Developers List Cc: Theodore Ts'o , stable@kernel.org Subject: [PATCH, RFC] ext4: ignore i_size_high for directories Date: Fri, 16 Jan 2009 11:59:08 -0500 Message-Id: <1232125148-13785-1-git-send-email-tytso@mit.edu> X-Mailer: git-send-email 1.6.0.4.8.g36f27.dirty X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Directories are not allowed to be bigger than 2TB, so don't use i_size_high when reading the inode. E2fsck should complain about these inodes, but the simplest thing to do for the kernel is simply to not consult i_size_high for directory inodes. This prevents an intentially corrupted filesystem from causing the kernel to burn a huge amount of CPU and issuing error messages such as: EXT4-fs warning (device loop0): ext4_block_to_path: block 135090028 > max Thanks to David Maciejak from Fortinet's FortiGuard Global Security Research Team for reporting this issue. http://bugzilla.kernel.org/show_bug.cgi?id=12375 Signed-off-by: "Theodore Ts'o" Cc: stable@kernel.org --- fs/ext4/ext4.h | 7 +++++-- fs/ext4/inode.c | 4 ++-- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index c668e43..42396a6 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1206,8 +1206,11 @@ static inline void ext4_r_blocks_count_set(struct ext4_super_block *es, static inline loff_t ext4_isize(struct ext4_inode *raw_inode) { - return ((loff_t)le32_to_cpu(raw_inode->i_size_high) << 32) | - le32_to_cpu(raw_inode->i_size_lo); + if (S_ISDIR(le16_to_cpu(raw_inode->i_mode))) + return (loff_t) le32_to_cpu(raw_inode->i_size_lo); + else + return ((loff_t)le32_to_cpu(raw_inode->i_size_high) << 32) | + le32_to_cpu(raw_inode->i_size_lo); } static inline void ext4_isize_set(struct ext4_inode *raw_inode, loff_t i_size) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index a6444ce..49484ba 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -360,9 +360,9 @@ static int ext4_block_to_path(struct inode *inode, final = ptrs; } else { ext4_warning(inode->i_sb, "ext4_block_to_path", - "block %lu > max", + "block %lu > max in inode %lu", i_block + direct_blocks + - indirect_blocks + double_blocks); + indirect_blocks + double_blocks, inode->i_ino); } if (boundary) *boundary = final - 1 - (i_block & (ptrs - 1));