linux-ext4 - Re: What to do when the journal checksum is incorrect

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: <1212488533.3272.23.camel@alpha.linsyssoft.com>
Date:	Tue, 03 Jun 2008 15:52:13 +0530
From:	Girish Shilamkar <Girish.Shilamkar@....COM>
To:	"Theodore Ts'o" <tytso@....EDU>
Cc:	linux-ext4@...r.kernel.org, Andreas Dilger <adilger@...sterfs.com>
Subject: Re: What to do when the journal checksum is incorrect

Hi Ted,
On Sat, 2008-05-24 at 18:34 -0400, Theodore Ts'o wrote: 
> I've been taking a much closer look at the ext4's journal checksum code
> as I integrated it into e2fsck, and I'm finding that what it's doing
> doesn't make a whole lot of sense.
> 
> Suppose the journal has five commits, with transaction ID's 2, 3, 4, 5,
> and 6.  And suppose the CRC in the commit block delineating the end of
> transaction #4 is bad.  At the moment, due to a bug in the code, it
> stops processing at transaction #4, meaning that transactions #2, #3,
> and #4 are replayed into the filesystem --- even though transaction #4
> failed the CRC checksum.  
I went through the code and also re-ran the e2fsprogs tests which we had
sent upstream for journal checksum. And found that if the transaction is
bad it is marked as info->end_transaction which indicates a bad
transaction and is not replayed.

if (chksum_err) {
     info->end_transaction = next_commit_ID;

The end_transaction is set to transaction ID which is found to be
corrupt. So #4 will be set in end_transaction and in PASS_REPLAY the
last transaction to be replayed will be #3 due to this:
----------------------------------------------------------------
if (tid_geq(next_commit_ID, info->end_transaction))
                                break;
-----------------------------------------------------------------

     if (!JFS_HAS_COMPAT_FEATURE(journal,
                                 JFS_FEATURE_INCOMPAT_ASYNC_COMMIT)){
           printk(KERN_ERR "JBD: Transaction %u found to be corrupt.\n",
                next_commit_ID);
   brelse(bh);                                 
   break;
     }
} 
> Worse yet, no indication of any problems is
> sent back to the ext4 filesystem code.
This definitely is not present and needs to be incorporated. 

Thanks,
Girish

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