From: Theodore Ts'o Date: Wed, 6 Jul 2016 00:01:52 +0000 (-0400) Subject: ext4: validate s_reserved_gdt_blocks on mount X-Git-Tag: v3.2.84~142 X-Git-Url: https://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff_plain;h=03eaa7470b473b98aacb14dee2d9e9d296307c78 ext4: validate s_reserved_gdt_blocks on mount commit 5b9554dc5bf008ae7f68a52e3d7e76c0920938a2 upstream. If s_reserved_gdt_blocks is extremely large, it's possible for ext4_init_block_bitmap(), which is called when ext4 sets up an uninitialized block bitmap, to corrupt random kernel memory. Add the same checks which e2fsck has --- it must never be larger than blocksize / sizeof(__u32) --- and then add a backup check in ext4_init_block_bitmap() in case the superblock gets modified after the file system is mounted. Reported-by: Vegard Nossum Signed-off-by: Theodore Ts'o [bwh: Backported to 3.2: - Drop the second check in ext4_init_block_bitmap() since it can't return an error code - Adjust context] Signed-off-by: Ben Hutchings --- diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 52b8ac740201..0d3204948ada 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3429,6 +3429,13 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) goto failed_mount; } + if (le16_to_cpu(sbi->s_es->s_reserved_gdt_blocks) > (blocksize / 4)) { + ext4_msg(sb, KERN_ERR, + "Number of reserved GDT blocks insanely large: %d", + le16_to_cpu(sbi->s_es->s_reserved_gdt_blocks)); + goto failed_mount; + } + if (sb->s_blocksize != blocksize) { /* Validate the filesystem blocksize */ if (!sb_set_blocksize(sb, blocksize)) {