linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 211971] New: Incorrect fix by e2fsck for blocks_count corruption
Date: Fri, 26 Feb 2021 21:39:42 +0000	[thread overview]
Message-ID: <bug-211971-13602@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=211971

            Bug ID: 211971
           Summary: Incorrect fix by e2fsck for blocks_count corruption
           Product: File System
           Version: 2.5
    Kernel Version: Linux 5.4.0-65-generic
          Hardware: x86-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
          Assignee: fs_ext4@kernel-bugs.osdl.org
          Reporter: tmahmud@iastate.edu
        Regression: No

Created attachment 295497
  --> https://bugzilla.kernel.org/attachment.cgi?id=295497&action=edit
log files from mke2fs, dumpe2fs and e2fsck

For an ext4 file system image with only one superblock, if the blocks_count
field in superblock is corrupted, e2fsck fixed it incorrectly. In the fixed
image, the corrupted blocks_count is unchanged and other fields (e.g., free
blocks count) are changed accordingly.
This issue also occurs in images with multiple superblocks too. For example,
For an ext4 image with primary and backup superblock (backup superblocks are
not located in default locations, e.g., it is located on 513rd block), if the
blocks_count field in superblock is corrupted, e2fsck fixed it incorrectly. In
the fixed image, the corrupted blocks_count is unchanged and other fields
(e.g., free blocks count) are changed accordingly.

e2fsprogs_version_used: e2fsprogs 1.45.6 (20-Mar-2020) 
The commands that I ran to recreate the scenario are:
For image with only one superblock:

dd if=/dev/zero bs=1024 count=8193 of=/home/hdd/image
mke2fs -b 1024 image 8193
debugfs -w image
debugfs:  ssv blocks_count 4000
debugfs:  q
e2fsck -yf image
e2fsck -yf image

# e2fsck fixes the blocks_count corruption in correctly
# In the clean image the blocks_count was 8193, in the fixed image the
blocks_count is 4000
#The second run of e2fsck is consistent with the first run, it doesn't fix
anything, but blocks_count is still 4000
# Expected that e2fsck would fix the blocks count corruption instead of
changing other fields (e.g.,free blocks_count)

For image with multiple superblocks:
dd if=/dev/zero bs=1024 count=8193 of=/home/hdd/image1
mke2fs -b 1024 -g 512 image1 8193
debugfs -w image1
debugfs:  ssv blocks_count 4000
debugfs:  q
e2fsck -yf image1
e2fsck -yf image1  

# e2fsck fixes the blocks_count corruption in correctly
# In the clean image the blocks_count was 8193, in the fixed image the
blocks_count is 4000
# The second run of e2fsck is consistent with the first run, it doesn't fix
anything, but blocks_count is still 4000
#There were 16 block groups in the clean image, but there are only 7 block
groups in the fixed image
# Expected that e2fsck would fix the blocks count corruption instead of
changing other fields (e.g.,free blocks_count) and removing the block groups.  

I attached the images and also the logs from mke2fs, dumpe2fs and e2fsck.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

             reply	other threads:[~2021-02-26 21:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-26 21:39 bugzilla-daemon [this message]
2021-02-27  0:58 ` [Bug 211971] New: Incorrect fix by e2fsck for blocks_count corruption Amy Parker
2021-02-27  1:29   ` Theodore Ts'o
2021-02-27  0:58 ` [Bug 211971] " bugzilla-daemon
2021-02-27  1:29 ` bugzilla-daemon
2021-03-03 17:14 ` bugzilla-daemon
2021-03-03 17:18 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-211971-13602@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).