From: Theodore Ts'o <tytso@mit.edu> Date: Tue, 20 May 2008 18:51:14 +0000 (-0400) Subject: e2fsck: Fix potential data corruptor bug in journal recovery X-Git-Tag: v1.40.10~3 X-Git-Url: http://git.kernel.org/?p=fs%2Fext2%2Fe2fsprogs.git;a=commitdiff_plain;h=e5ea6b14eb93671525e01ec4a6100febe541bf67 e2fsck: Fix potential data corruptor bug in journal recovery While synchronizing e2fsck's recovery.c with the latest 2.6 kernel sources, I discovered a serious bug that apparently had been fixed in the kernel sometime between Deceber 2003 and April 2005, but which had not been carried over to e2fsprogs. Specifically, when blocks whose first 4 bytes are JFS_MAGIC_NUMBER (0xc03b3998) are written into the journal, the first 4 bytes zero'ed out. A one character typo meant that when the blocks were replayed by e2fsck, the JFS_MAGIC_NUMBER would not be restored. Oops. Fortunately, it is *highly* unlikely that ext4 metadata blocks will contain that magic number in the first four bytes, and data=journalled is a relatively rarely used. This commit fixes this bug, as well as updating e2fsck's recovery.c to be in sync with 2.6.25. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> --- Index: e2fsprogs-1.39/e2fsck/recovery.c =================================================================== --- e2fsprogs-1.39.orig/e2fsck/recovery.c 2006-05-14 15:48:09.000000000 -0500 +++ e2fsprogs-1.39/e2fsck/recovery.c 2008-06-11 16:26:39.309731769 -0500 @@ -473,7 +473,7 @@ static int do_one_pass(journal_t *journa memcpy(nbh->b_data, obh->b_data, journal->j_blocksize); if (flags & JFS_FLAG_ESCAPE) { - *((unsigned int *)bh->b_data) = + *((unsigned int *)nbh->b_data) = htonl(JFS_MAGIC_NUMBER); }