On Fri, Nov 18, 2016 at 09:40:02AM +0200, Nikolay Borisov wrote: > > > On 11/18/2016 06:26 AM, Theodore Ts'o wrote: > > If the block size or cluster size is insane, reject the mount. This > > is important for security reasons (although we shouldn't be just > > depending on this check). > > > > Ref: http://www.securityfocus.com/archive/1/539661 > > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506 > > Reported-by: Borislav Petkov <bp@xxxxxxxxx> > > Reported-by: Nikolay Borisov <kernel@xxxxxxxx> > > Signed-off-by: Theodore Ts'o <tytso@xxxxxxx> > > Cc: stable@xxxxxxxxxxxxxxx > > I just tested with the 3 patches applied on 4.9-rc4 and could still > reproduce the issue. I've just tested the dev branch on both x86 and x86_64 and it doesn't reproduce for me; root@xfstests:~# mount -o ro,loop /tmp/OSS-2016-23-image /mnt mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. root@xfstests:~# dmesg | tail -3 [ 910.472554] EXT4-fs (loop0): Unrecognized mount option "" or missing value [ 910.479708] EXT4-fs (loop0): failed to parse options in superblock: [ 910.486279] EXT4-fs (loop0): Invalid log block size: 4286906368 root@xfstests:~# The critical patch should be: ext4: sanity check the block and cluster size at mount time Can you double check your test? Thanks, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
