linux-ext4 - [Bug 23772] oops after mounting ext4 fs in 2.6.36.1 (failed to parse options in superblock)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Nov 2010 21:55:04 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 23772] oops after mounting ext4 fs in 2.6.36.1 (failed to parse
 options in superblock)

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

Andreas Dilger <adilger.kernelbugzilla@...ger.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adilger.kernelbugzilla@...g
                   |                            |er.ca

--- Comment #14 from Andreas Dilger <adilger.kernelbugzilla@...ger.ca>  2010-11-29 21:55:03 ---
(In reply to comment #10)
> Well, one question is how did the stale data get put there in the first place? 
> The entire superblock is zero'ed out by mke2fs.

The s_mount_options field has the unfortunate distinction of being the first
field beyond 0x200 in the superblock (i.e. second sector of 1kB superblock
area).  This means it could have been corrupted at some time in the past by an
incomplete write or similar, and no e2fsck will have checked/fixed this.

Looking at the 'dd' output, it is clear that both the area before and after the
512-bytes of the original superblock were clobbered by 0xffff data at one time
or another, and I suspect the superblock was rewritten from a backup copy but
only the first sector was written to disk.

(In reply to comment #12)
> I there is a way to fix it on the user space side?

Fairly simple, for this specific case.  It should overwrite the 512-byte area
beyond the superblock with zeroes:

dd if=/dev/zero of=/dev/dsk/by-label/MyBook bs=512 count=1 seek=3 skip=3

That said, I don't know how common or unusual this kind of garbage data is in
this area of the filesystem.  It might make sense that errors parsing of the
s_mount_options field is not taken as a fatal error at mount time, since this
can make a system unbootable, and no e2fsck will fix it.

For e2fsck, it probably makes sense to limit the data in s_mount_opts to
printable ASCII characters, and otherwise zero out any remaining data.  I'm not
sure what to do for the rest of the superblock, however.

Should e2fsck zero out that data if s_mount_opts is found to be bad?  Should we
wait until every field is defined, and then fix them on a case-by-case basis? 
The former is preferable because otherwise it means the kernel can never start
using any of these fields without e2fsck having verified the content first, but
it has the drawback that any corruption just to s_mount_opts may wipe out the
rest of the superblock.

In that regard, it would have been preferable to locate the "s_first_error" and
"s_last_error" fields near the end of the 1kB superblock range, instead of
quickly consuming the rest of the space in the first sector (which we know will
be written atomically), which is why it would be nice if such changes were
discussed and reviewed on the mailing list rather than being presented as a
fait-accompli in some kernel update and/or e2fsprogs release.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html