linux-ext4 - [Bug 201685] ext4 file system corruption

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bug-201685-13602-bXAnDhp9Gf@https.bugzilla.kernel.org/>
Date:   Tue, 04 Dec 2018 06:04:10 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 201685] ext4 file system corruption

https://bugzilla.kernel.org/show_bug.cgi?id=201685

--- Comment #216 from Jukka Santala (donwulff@....fi) ---
This time the corrupt inode block came clearly from one of the JPG files I was
checksumming (without writing) with rsync at the same time. Poor test because I
was checking against BTRFS filesystem, so I don't know which fs the corrupt
block came from. Also first time I hit actual corruption with filesystem
mounted errors=remount-ro, somehow two blocks of inodes had multiply claimed
inodes. To me this suggests that the corrupting block came from another
reservation block, the kernel didn't notice that because the data structure was
valid and wrote it back. If so, this would indicate it happens inside single
filesystem and with metadata blocks as source as well.

It seems to me like metadata blocks are remaining linked when evicted due to
memory pressure. BTRFS csum errors probably from same source. Steps for
reproducing would be causing evictions in large pagecache while re-accessing
same inode blocks. Backup scripts do this when same block contains inodes
created at different times, ie. for me it happens constantly when reading files
in date-specific directories where files from different days are in same inode
block so the copy command re-reads the same block after some evictions. Likely
some race-condition in block reservation or the like, because otherwise it'd be
crashing all the time, but the corrupt block stays in the cache.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.