Bug 450767

Summary:	e2fsck: potential data corruption on log replay
Product:	Red Hat Enterprise Linux 4	Reporter:	Eric Sandeen <esandeen>
Component:	e2fsprogs	Assignee:	Eric Sandeen <esandeen>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.8	CC:	sct
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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 20:25:41 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	450765
Bug Blocks:	456462

Description Eric Sandeen 2008-06-10 20:53:26 UTC

+++ 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>
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 20:38:21 UTC

Built in e2fsprogs-1.35-12.18.EL4

Comment 5 Ruediger Landmann 2009-01-28 04:55:30 UTC

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 20:25:41 UTC

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