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: <CAMuHMdU-vfWjomDpttYTqgp4YzBu7z__p48r7rq6TSUwx7uFqQ@mail.gmail.com>
Date:   Mon, 1 Jul 2019 14:43:14 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     "Theodore Ts'o" <tytso@....edu>,
        Arthur Marsh <arthur.marsh@...ernode.on.net>,
        Richard Weinberger <richard.weinberger@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: ext3/ext4 filesystem corruption under post 5.1.0 kernels

Hi Ted,

On Fri, May 17, 2019 at 6:44 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> On Wed, May 15, 2019 at 6:57 AM 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?
>
> Thanks!
> Sorry for missing this patch in the thread before.
>
> > 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>
>
> Intermittent issue no more seen in 10 test boots, so
> Tested-by: Geert Uytterhoeven <geert@...ux-m68k.org>

Despite this fix having been applied upstream,  the kernel prints from
time to time:

    EXT4-fs (sda1): error count since last fsck: 5
    EXT4-fs (sda1): initial error at time 1557931133:
ext4_get_branch:171: inode 1980: block 27550
    EXT4-fs (sda1): last error at time 1558114349:
ext4_get_branch:171: inode 1980: block 27550

This happens even after a manual run of "e2fsck -f" (while it's mounted
RO), which reports a clean file system.

The inode and block numbers match the numbers printed due to the
previous bug.

Do you have an idea what's wrong?
Note that I run a very old version of e2fsck (from a decade ago).

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds