Bug 1093446
| Summary: | mkfs can create filesystems with a revision that breaks e2fsprogs support | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Ryan Crews <rcrews> | ||||
| Component: | e2fsprogs | Assignee: | Eric Sandeen <esandeen> | ||||
| Status: | CLOSED ERRATA | QA Contact: | dhe | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.5 | CC: | eguan, fsorenso, lczerner, sct | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | e2fsprogs-1.41.12-19.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1093471 1212378 (view as bug list) | Environment: | |||||
| Last Closed: | 2014-10-14 07:54:16 UTC | Type: | Bug | ||||
| 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: | |||||||
| Bug Blocks: | 1093471 | ||||||
| Attachments: |
|
||||||
(In reply to Ryan Crews from comment #0) > Description of problem: The mkfs.ext4 utility can create a filesystem with a > revision number that breaks support in e2fsprogs utilities such as dumpe2fs > and e2fsck. The filesystem can be mounted fine, but eventually an automatic > fsck will fail (if enabled). > > Version-Release number of selected component (if applicable): > e2fsprogs-1.41.12-18.el6.x86_64 > 2.6.32-431.11.2.el6.x86_64 > > How reproducible: 100% > > Steps to Reproduce: > 1. Add storage. (dd if=/dev/zero of=~/test.fs bs=1M count=100) > 2. Make filesystem with non 0/1 revision number (mkfs.ext4 -r 999 ~/test.fs) Ok, but - why on earth would you do that? there are all sorts of administrative missteps that can be taken; this looks like one of them. <looks at case ...> Oh, I see, they were trying to set reserved space. Hohum. So, there is a test in the kernel at mount time: if (le32_to_cpu(es->s_rev_level) > EXT4_MAX_SUPP_REV) { ext4_msg(sb, KERN_ERR, "revision level too high, " "forcing read-only mode"); res = MS_RDONLY; } but it's not working, apparently. Agreed that userspace shouldn't be able to set a level higher than it knows about, I'll send a patch upstream, and see why the kernel test is failing. Thanks, -Eric Well, the kernel test is working to some degree: EXT4-fs (sdc): revision level too high, forcing read-only mode but it's ... not actually making the fs read-only. Ah:
commit 7e84b6216467b84cd332c8e567bf5aa113fd2f38
Author: Eric Sandeen <sandeen>
Date: Mon May 28 14:17:25 2012 -0400
ext4: force ro mount if ext4_setup_super() fails
If ext4_setup_super() fails i.e. due to a too-high revision,
the error is logged in dmesg but the fs is not mounted RO as
indicated.
Which is only present in kernels v3.5 and higher.
-Eric
[PATCH] mke2fs: don't accept too-high revision levels
It's a bit strange to accept revision levels higher than
the code creating the filesystem can understand, so don't
allow it.
At least the kernel will mount the fs readonly if it's too
high, but no other utility will touch it, so you can't
fix the error.
Just reject anything > EXT2_MAX_SUPP_REV at mkfs time.
Signed-off-by: Eric Sandeen <sandeen>
---
diff --git a/misc/mke2fs.c b/misc/mke2fs.c
index aecd5d5..82019dc 100644
--- a/misc/mke2fs.c
+++ b/misc/mke2fs.c
@@ -1679,9 +1679,10 @@ profile_error:
break;
case 'r':
r_opt = strtoul(optarg, &tmp, 0);
- if (*tmp) {
+ if (*tmp || r_opt > EXT2_MAX_SUPP_REV ) {
com_err(program_name, 0,
- _("bad revision level - %s"), optarg);
+ _("bad revision level - %s (max %d)"),
+ optarg, EXT2_MAX_SUPP_REV);
exit(1);
}
fs_param.s_rev_level = r_opt;
Setting request for RHEL6.6, no reason to wait on a fix, IMHO.
Created attachment 891628 [details]
patch to limit filesystem revision number
Frank, I took the liberty of sending your patch as a V2 for mine; yours is cleaner, thanks! (It was worth the extra 20 mins) :) -Eric Built in e2fsprogs-1.41.12-19.el6 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1566.html |
Description of problem: The mkfs.ext4 utility can create a filesystem with a revision number that breaks support in e2fsprogs utilities such as dumpe2fs and e2fsck. The filesystem can be mounted fine, but eventually an automatic fsck will fail (if enabled). Version-Release number of selected component (if applicable): e2fsprogs-1.41.12-18.el6.x86_64 2.6.32-431.11.2.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. Add storage. (dd if=/dev/zero of=~/test.fs bs=1M count=100) 2. Make filesystem with non 0/1 revision number (mkfs.ext4 -r 999 ~/test.fs) 3. Test filesystem: [rcrews@cirno ~]$ mkdir ~/test [rcrews@cirno ~]$ sudo mount -o loop ~/test.fs ~/test [rcrews@cirno ~]$ df -h ~/test Filesystem Size Used Avail Use% Mounted on /home/rcrews/test.fs 97M 5.6M 87M 7% /home/rcrews/test [rcrews@cirno ~]$ touch ~/test/file 4. Unmount and attempt to fsck or dumpe2fs: [rcrews@cirno ~]$ sudo umount ~/test.fs [rcrews@cirno ~]$ e2fsck ~/test.fs e2fsck 1.41.12 (17-May-2010) e2fsck: Filesystem revision too high while trying to open /home/rcrews/test.fs The filesystem revision is apparently too high for this version of e2fsck. (Or the filesystem superblock is corrupt) The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 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> [rcrews@cirno ~]$ dumpe2fs ~/test.fs dumpe2fs 1.41.12 (17-May-2010) dumpe2fs: Filesystem revision too high while trying to open /home/rcrews/test.fs Couldn't find valid filesystem superblock. Actual results: See above. Expected results: mkfs will error out when attempting to create an unsupported filesystem revision, or utilities like dumpe2fs and fsck will work normally. Additional info: