linux-ext4 - Re: ext3/ext4 filesystem corruption under post 5.1.0 kernels

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: <C24BBE18-1665-4343-9C98-5AF64BACDCA3@internode.on.net>
Date:   Wed, 15 May 2019 21:42:11 +0930
From:   Arthur Marsh <arthur.marsh@...ernode.on.net>
To:     Theodore Ts'o <tytso@....edu>
CC:     Richard Weinberger <richard.weinberger@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, linux-ext4@...r.kernel.org
Subject: Re: ext3/ext4 filesystem corruption under post 5.1.0 kernels



On 15 May 2019 2:27:17 pm ACST, Theodore Ts'o <tytso@....edu> wrote:
>Ah, I think I see the problem.  Sorry, this one was my fault.  Does
>this fix things for you?
>
>						- Ted
>
>>From 0c72924ef346d54e8627440e6d71257aa5b56105 Mon Sep 17 00:00:00 2001
>From: Theodore Ts'o <tytso@....edu>
>Date: Wed, 15 May 2019 00:51:19 -0400
>Subject: [PATCH] ext4: fix block validity checks for journal inodes
>using indirect blocks
>
>Commit 345c0dbf3a30 ("ext4: protect journal inode's blocks using
>block_validity") failed to add an exception for the journal inode in
>ext4_check_blockref(), which is the function used by ext4_get_branch()
>for indirect blocks.  This caused attempts to read from the ext3-style
>journals to fail with:
>
>[  848.968550] EXT4-fs error (device sdb7): ext4_get_branch:171: inode
>#8: block 30343695: comm jbd2/sdb7-8: invalid block
>
>Fix this by adding the missing exception check.
>
>Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using
>block_validity")
>Reported-by: Arthur Marsh <arthur.marsh@...ernode.on.net>
>Signed-off-by: Theodore Ts'o <tytso@....edu>
>---
> fs/ext4/block_validity.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
>diff --git a/fs/ext4/block_validity.c b/fs/ext4/block_validity.c
>index 8d03550aaae3..8e83741b02e0 100644
>--- a/fs/ext4/block_validity.c
>+++ b/fs/ext4/block_validity.c
>@@ -277,6 +277,11 @@ int ext4_check_blockref(const char *function,
>unsigned int line,
> 	__le32 *bref = p;
> 	unsigned int blk;
> 
>+	if (ext4_has_feature_journal(inode->i_sb) &&
>+	    (inode->i_ino ==
>+	     le32_to_cpu(EXT4_SB(inode->i_sb)->s_es->s_journal_inum)))
>+		return 0;
>+
> 	while (bref < p+max) {
> 		blk = le32_to_cpu(*bref++);
> 		if (blk &&

I have built kernels with the attached patch applied and run git gc on the patched kernels (both the 32 bit kernel on the Pentium-D and the 64 bit kernel on the Athlon II X4 640). 

There were a couple of warnings from other processes being blocked while the git gc was taking place but no filesystem corruption detected. (I ran forced fsck checks on the root filesystems after the git gc runs to check for corruption). 

Thanks for the patch! 

Arthur. 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Download attachment "ext4.tmp" of type "application/octet-stream" (506 bytes)

Download attachment "20190515iucode_tool.log" of type "application/octet-stream" (4281 bytes)