linux-ext4 - fsck cannot fix block bitmap overlapping group descriptor

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

Message-ID: <08dbf5c5-5296-405c-f739-0baa548821e4@ferienwohnung-altenbeken.de>
Date:   Mon, 6 Aug 2018 19:02:31 +0200
From:   Benjamin Meier <maillists@...ienwohnung-altenbeken.de>
To:     linux-ext4@...r.kernel.org
Subject: fsck cannot fix block bitmap overlapping group descriptor

After switching to a newer kernel (4.9.110) I am not able to mount my 
ext4-filesystem read-write. fsck does not find any errors or anything to 
adjust. After spending hours of reading and learning I found the reason 
in these lines:

 From kernel fs/ext4/super.c, introduced in 2018-06-14:

   ext4_fsblk_t last_bg_block = sb_block + ext4_bg_num_gdb(sb, 0) + 1;

   block_bitmap = ext4_block_bitmap(sb, gdp);

   // ... snip ...

   // For every Group i:

   if (block_bitmap >= sb_block + 1 &&

     block_bitmap <= last_bg_block) {

     ext4_msg(sb, KERN_ERR, "ext4_check_descriptors: "

              "Block bitmap for group %u overlaps "

              "block group descriptors", i);

     if (!(sb->s_flags & MS_RDONLY))

     return 0;

   }

                 }

Consequently my error message is "ext4_check_descriptors: Block bitmap 
for group 1 overlaps block group descriptors".

But I do not understand why this happens (Hey, yesterday at that time I 
didn't know how ext4 works) nor how to solve this issue. See this 
excerpt of dumpe2fs to understand my confusion:

Filesystem features:      has_journal ext_attr dir_index filetype 
meta_bg extent 64bit flex_bg sparse_super large_file huge_file dir_nlink 
extra_isize metadata_csum

Block size:               4096

Fragment size:            4096

Group descriptor size:    64

Blocks per group:         32768

First meta block group:   1217

Flex block group size:    16

Group 0: (Blocks 0-32767) csum 0xb704 [ITABLE_ZEROED]

   Primary superblock at 0, Group descriptors at 1-1217

   Block bitmap at 9441 (+9441), csum 0xe5bcfef3

   Inode bitmap at 1233 (+1233), csum 0x8f9b318c

   Inode table at 1249-1760 (+1249)

   794 free blocks, 8179 free inodes, 2 directories, 8177 unused inodes

   Free blocks: 9446, 31975-32767

   Free inodes: 12-13, 16-8192

Group 1: (Blocks 32768-65535) csum 0x8719 [INODE_UNINIT, ITABLE_ZEROED]

   Backup superblock at 32768, Group descriptors at 32769-33985

   Block bitmap at 1218 (bg #0 + 1218), csum 0x671f0005

   Inode bitmap at 1234 (bg #0 + 1234), csum 0x00000000

   Inode table at 1761-2272 (bg #0 + 1761)

   799 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes

   Free blocks: 34806-34807, 34815, 42178-42207, 42289-42367, 
42463-42495, 45601-45667, 57956-57983, 58202-58367, 59951-60003, 63490, 
63498-63503, 63512-63519, 63552-63615, 63739-63999

   Free inodes: 8193-16384

 From my understanding - please correct me - block_bitmap should be 1218 
(because group i=1 was mentioned). sb_block+1=0+1 should be 1; so 
block_bitmap>=sb_block+1 is true. But shouldn't last_bg_block be 1217 
(or 1 as 64 groups fit into one block?) or less? Which value does 
last_bg_block represent?
  Whats wrong here? By the way: The fs grew a lot in the past years.

Any hint on whats going on here and how I can come back to a read-write 
system?

Thanks in advance, also for reading!