linux-ext4 - Re: [PATCH] ext4: fix extent tree corruption that incurred by hole punch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50C0BE40.5060003@redhat.com>
Date:	Thu, 06 Dec 2012 09:48:16 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Forrest Liu <forrestl@...ology.com>
CC:	"Theodore Ts'o" <tytso@....edu>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] ext4: fix extent tree corruption that incurred by hole
 punch

On 12/6/12 9:45 AM, Eric Sandeen wrote:
> On 12/4/12 6:11 AM, Forrest Liu wrote:
>> Extent indexes didn't update correctly in ext4_ext_rm_idx, when depth
>> of extent tree is greater than 1.
> 
> This is interesting; we had 2 reports of similar corruption on the
> list, I wonder if the application in question was doing hole punching.
> I didn't expect that they were, so TBH I was pretty much ignoring
> the hole-punch cases for parent index updates.  Hm.  I'll have
> to look into that.
> 
> Could you turn your testcase into an xfstest regression test?

Also, please note that I sent an e2fsck patch to try to fix this
problem after the fact; it'd be great if in your testing, you could
also confirm that e2fsck w/ my patch fixes it correctly.

Thanks,
-Eric

> -Eric
> 
>> Signed-off-by: Forrest Liu <forrestl@...ology.com>
>> ---
>>  fs/ext4/extents.c |   24 ++++++++++++++++++++----
>>  1 files changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
>> index d3dd618..b10b8c0 100644
>> --- a/fs/ext4/extents.c
>> +++ b/fs/ext4/extents.c
>> @@ -2190,13 +2190,15 @@ errout:
>>   * removes index from the index block.
>>   */
>>  static int ext4_ext_rm_idx(handle_t *handle, struct inode *inode,
>> -			struct ext4_ext_path *path)
>> +			struct ext4_ext_path *path, int depth)
>>  {
>>  	int err;
>>  	ext4_fsblk_t leaf;
>> +	__le32 border;
>>  
>>  	/* free index block */
>> -	path--;
>> +	depth--;
>> +	path = path + depth;
>>  	leaf = ext4_idx_pblock(path->p_idx);
>>  	if (unlikely(path->p_hdr->eh_entries == 0)) {
>>  		EXT4_ERROR_INODE(inode, "path->p_hdr->eh_entries == 0");
>> @@ -2221,6 +2223,20 @@ static int ext4_ext_rm_idx(handle_t *handle, struct inode *inode,
>>  
>>  	ext4_free_blocks(handle, inode, NULL, leaf, 1,
>>  			 EXT4_FREE_BLOCKS_METADATA | EXT4_FREE_BLOCKS_FORGET);
>> +
>> +	border = path->p_idx->ei_block;
>> +	while (--depth >= 0) {
>> +		if (path->p_idx != EXT_FIRST_INDEX(path->p_hdr))
>> +			break;
>> +		path--;
>> +		err = ext4_ext_get_access(handle, inode, path);
>> +		if (err)
>> +			break;
>> +		path->p_idx->ei_block = border;
>> +		err = ext4_ext_dirty(handle, inode, path);
>> +		if (err)
>> +			break;
>> +	}
>>  	return err;
>>  }
>>  
>> @@ -2557,7 +2573,7 @@ ext4_ext_rm_leaf(handle_t *handle, struct inode *inode,
>>  	/* if this leaf is free, then we should
>>  	 * remove it from index block above */
>>  	if (err == 0 && eh->eh_entries == 0 && path[depth].p_bh != NULL)
>> -		err = ext4_ext_rm_idx(handle, inode, path + depth);
>> +		err = ext4_ext_rm_idx(handle, inode, path, depth);
>>  
>>  out:
>>  	return err;
>> @@ -2760,7 +2776,7 @@ again:
>>  				/* index is empty, remove it;
>>  				 * handle must be already prepared by the
>>  				 * truncatei_leaf() */
>> -				err = ext4_ext_rm_idx(handle, inode, path + i);
>> +				err = ext4_ext_rm_idx(handle, inode, path, i);
>>  			}
>>  			/* root level has p_bh == NULL, brelse() eats this */
>>  			brelse(path[i].p_bh);
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html