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  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]
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)

Powered by blists - more mailing lists