linux-ext4 - [Bug 220288] A typo Leads to loss of all data on disk

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: <bug-220288-13602-W848vhM7oV@https.bugzilla.kernel.org/>
Date: Sat, 28 Jun 2025 02:48:42 +0000
From: bugzilla-daemon@...nel.org
To: linux-ext4@...r.kernel.org
Subject: [Bug 220288] A typo Leads to loss of all data on disk

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

--- Comment #1 from Theodore Tso (tytso@....edu) ---
I don't see how that happened.  /dev/sdc has a partition table at the
beginning of the disk.  That partition table contains the definition
of /dev/sdc1.

So if you ran "fsck.ext4 /dev/sdc" instead of "fsck.ext4 /dev/sdc1",
you should have gotten something like this:

   root@...tests:~# fsck.ext4 /dev/sdb
   e2fsck 1.47.2-rc1 (28-Nov-2024)
   ext2fs_open2: Bad magic number in super-block
   fsck.ext4: Superblock invalid, trying backup blocks...
   fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb

   The superblock could not be read or does not describe a valid ext2/ext3/ext4
   filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
   filesystem (and not swap or ufs or something else), then the superblock
   is corrupt, and you might try running e2fsck with an alternate superblock:
       e2fsck -b 8193 <device>
    or
       e2fsck -b 32768 <device>

   Found a gpt partition table in /dev/sdb

In any case, fsck.ext4 will not make any changes unless you give it
permission by answering "yes".  For example (do not try this at home,
kids):

    root@...tests:~# debugfs  -w -R "clri <2>" /dev/sdb1 ; debugfs -w -R "ssv
state 2" /dev/sdb1
    debugfs 1.47.2-rc1 (28-Nov-2024)
    debugfs 1.47.2-rc1 (28-Nov-2024)
    root@...tests:~# fsck.ext4 /dev/sdb1
    e2fsck 1.47.2-rc1 (28-Nov-2024)
    /dev/sdb1 contains a file system with errors, check forced.
    Pass 1: Checking inodes, blocks, and sizes
    Root inode is not a directory.  Clear<y>? yes
    Pass 2: Checking directory structure
    Entry '..' in <2>/<11> (11) has deleted/unused inode 2.  Clear<y>? yes
    Pass 3: Checking directory connectivity
    Root inode not allocated.  Allocate<y>? yes
    Unconnected directory inode 11 (was in /)
    Connect to /lost+found<y>? yes
    /lost+found not found.  Create<y>? yes
    Pass 3A: Optimizing directories
    Pass 4: Checking reference counts
    Inode 11 ref count is 3, should be 2.  Fix<y>? yes
    Pass 5: Checking group summary information

    /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
    /dev/sdb1: 13/655360 files (0.0% non-contiguous), 67263/2620928 blocks

See how fsck.ext4 asks for permission before it makes any change to
the filesystem?

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

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