From patchwork Thu Feb 5 12:03:23 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thiemo Nagel X-Patchwork-Id: 22108 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 89E39DDDF9 for ; Thu, 5 Feb 2009 23:03:35 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752645AbZBEMDd (ORCPT ); Thu, 5 Feb 2009 07:03:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753036AbZBEMDd (ORCPT ); Thu, 5 Feb 2009 07:03:33 -0500 Received: from hamlet.e18.physik.tu-muenchen.de ([129.187.154.223]:46306 "EHLO hamlet.e18.physik.tu-muenchen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752919AbZBEMDc (ORCPT ); Thu, 5 Feb 2009 07:03:32 -0500 Received: from [129.187.154.161] (earlgrey.e18.physik.tu-muenchen.de [129.187.154.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hamlet.e18.physik.tu-muenchen.de (Postfix) with ESMTP id 2CE11EEC; Thu, 5 Feb 2009 13:03:30 +0100 (CET) Message-ID: <498AD58B.5000805@ph.tum.de> Date: Thu, 05 Feb 2009 13:03:23 +0100 From: Thiemo Nagel User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Ext4 Developers List , Theodore Tso Subject: [RFC] ext4_bmap() may return blocks outside filesystem Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hello, during testing of ext4 with intentionally corrupted filesystem images I noticed that sometimes ext4_bmap() returns physical block numbers which lie outside of the filesystem. In most cases, the error is caught by the block layer (?) leading to error messages of the kind: attempt to access beyond end of device loop0: rw=0, want=xxx, limit=xxx But there also are cases which are not handled gracefully by bmap() callers. I've attached a conceptual patch against 2.6.29-rc2 which fixes one case in which invalid block numbers are returned (there might be more) by adding sanity checks to ext4_ext_find_extent(), but before I start looking for further occurences, I'd like to ask whether you think my approach is reasonable. Kind regards, Thiemo Nagel --- ../download/linux-2.6.29-rc2-vanilla/fs/ext4/extents.c 2009-02-05 12:31:19.000000000 +0100 +++ fs/ext4/extents.c 2009-02-05 12:42:49.000000000 +0100 @@ -595,8 +595,15 @@ /* find extent */ ext4_ext_binsearch(inode, path + ppos, block); /* if not an empty leaf */ - if (path[ppos].p_ext) + if (path[ppos].p_ext) { path[ppos].p_block = ext_pblock(path[ppos].p_ext); + if (path[ppos].p_block < EXT4_SB(inode->i_sb)->s_es->s_first_data_block + || path[ppos].p_block + path[ppos].p_ext->ee_len + >= ext4_blocks_count(EXT4_SB(inode->i_sb)->s_es)) { + printk("ext4_ext_find_extent: extent out of range\n"); + goto err; + } + } ext4_ext_show_path(inode, path);