linux-ext4 - RE: EXT3 file system with unsupported revision level can be mounted in R/W mode

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] [day] [month] [year] [list]

Message-ID: <D457AE0D137B9143B30CDD9EB9B2F8D509FDD582@ZZ01X1MB24.ixas.unisys.co.jp>
Date:	Fri, 29 Aug 2008 20:34:41 +0900
From:	<tadao.uchiyama@...adex.co.jp>
To:	<sandeen@...hat.com>
CC:	<linux-ext4@...r.kernel.org>
Subject: RE: EXT3 file system with unsupported revision level can be mounted
 in R/W mode


> For what it's worth, ext2 and ext4 have the same problems...

Thanks a lot for the first response! I really appreciate it.

>> --- linux-2.6.26.2/fs/ext3/super.c.orig 2008-08-18 11:01:02.000000000 +0900
>> +++ linux-2.6.26.2/fs/ext3/super.c      2008-08-18 11:06:29.000000000 +0900
>> @@ -1898,7 +1898,8 @@ static int ext3_fill_super (struct super
>>                 goto failed_mount4;
>>         }
>>
>> -       ext3_setup_super (sb, es, sb->s_flags & MS_RDONLY);
>> +       if (ext3_setup_super (sb, es, sb->s_flags & MS_RDONLY))
>> +                sb->s_flags |= MS_RDONLY;
>>         /*
>>          * akpm: core read_super() calls in here with the superblock locked.
>>          * That deadlocks, because orphan cleanup needs to lock the
>> superblock @@ -2506,8 +2507,8 @@ static int ext3_remount (struct super_bl
>>                         sbi->s_mount_state = le16_to_cpu(es->s_state);
>>                         if ((err = ext3_group_extend(sb, es,
>> n_blocks_count)))

> One other thing I worry about; we are doing group_extend before we check
> the revision.  Is that safe?  We also still do things like replay the
> journal and process orphan inodes before checking the revision.
>
> Should we even worry about this, or is the revision level never going
> to change again, and we can almost just ignore it > > now?  (or assume
> that for recent kernels, a too-high rev level indicates corruption and
> fail the
> mount?)
>
> -Eric

I think I need more time to find an appropriate answer, but I'll be keeping busy for a while. Please wait. Could anyone give us some suggestion? Any comments would be highly appreciated.

> >                                 goto restore_opts;
> > -                       if (!ext3_setup_super (sb, es, 0))
> > -                               sb->s_flags &= ~MS_RDONLY;
> > +                       if (ext3_setup_super (sb, es, 0))
> > +                               *flags &= ~MS_RDONLY;
> >                 }
> >         }
> >  #ifdef CONFIG_QUOTA
> > ----------
> > --

Thanks.
Signed-off-by :Tadao Uchiyama <Tadao.Uchiyama@...adex.co.jp>
--
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