Bug 450767 - e2fsck: potential data corruption on log replay
e2fsck: potential data corruption on log replay
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: e2fsprogs (Show other bugs)
4.8
All Linux
medium Severity medium
: rc
: ---
Assigned To: Eric Sandeen
:
Depends On: 450765
Blocks: 456462
  Show dependency treegraph
 
Reported: 2008-06-10 16:53 EDT by Eric Sandeen
Modified: 2009-05-18 16:25 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
* if a block's first four bytes consisted of the JFS_MAGIC_NUMBER (0xc03b3998), these bytes were replaced with zeros when the block was written into the file system's journal. If the file system was subsequently recovered, a typo, associated with the Linux Journaling Block Device (JBD), could result in data corruption on recovery. The Linux kernel typo has been corrected but the fix was not carried over to e2fsprogs, where the equivalent problem could present during an e2fsck log replay. It has now been carried over and data corruption will not occur in the circumstances described above. Note: the data corruption potential was always low. It is unlikely ext3 metadata blocks will ever contain the JFS_MAGIC_NUMBER in their first four bytes and the "data=journaled" mode is rarely used.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 16:25:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Sandeen 2008-06-10 16:53:26 EDT
+++ This bug was initially created as a clone of Bug #450765 +++

From e5ea6b14eb93671525e01ec4a6100febe541bf67 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Tue, 20 May 2008 14:51:14 -0400
Subject: [PATCH] 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, 

NB: actually more recently, in commit 439aeec639d7c57f3561054a6d315c40fd24bb74 --ERS

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.
Comment 2 Eric Sandeen 2008-09-22 16:38:21 EDT
Built in e2fsprogs-1.35-12.18.EL4
Comment 5 Ruediger Landmann 2009-01-27 23:55:30 EST
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
* if a block's first four bytes consisted of the JFS_MAGIC_NUMBER (0xc03b3998), these bytes were replaced with zeros when the block was written into the file system's journal. If the file system was subsequently recovered, a typo, associated with the Linux Journaling Block Device (JBD), could result in data corruption on recovery. The Linux kernel typo has been corrected but the fix was not carried over to e2fsprogs, where the equivalent problem could present during an e2fsck log replay. It has now been carried over and data corruption will not occur in the circumstances described above.

Note: the data corruption potential was always low. It is unlikely ext3 metadata blocks will ever contain the JFS_MAGIC_NUMBER in their first four bytes and the "data=journaled" mode is rarely used.
Comment 8 errata-xmlrpc 2009-05-18 16:25:41 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0996.html

Note You need to log in before you can comment on or make changes to this bug.