linux-ext4 - Corrupted i

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: <ec9c3d81-dd5e-4a80-9148-1e0b24cddd1e@dybdal.dk>
Date: Fri, 27 Sep 2024 16:38:02 +0200
From: Jesper Dybdal <jd-ext4@...dal.dk>
To: linux-ext4@...r.kernel.org
Subject: Corrupted i_blocks field

I have now a few times experienced a problem with the i_blocks field of 
a few inodes being corrupted (replaced by extremely large numbers).

I don't believe that it is a disk error - the file system is on a RAID1 
partition and the RAID consistency is checked regularly.
I also find it hard to believe that it is a RAM error - the machine has 
run memtest86+ overnight without finding anything.

The files I've seen corrupted are simple small text files that are 
modified only using an ordinary text editor (emacs).

Fsck fixes it.
The system is an up-to-date Debian Bookworm:
     Linux nuser 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 
(2024-08-26) x86_64 GNU/Linux

I do one thing that is not the default for ext4: I use the "nodelalloc" 
option (because several years ago, there was a discussion about 
"delalloc or not" from which I got the impression that nodelalloc was 
probably slightly safer - if the resulting performance reduction is not 
a problem, which it is not for me):
      /dev/md0 on / type ext4 (rw,relatime,nodelalloc,errors=remount-ro)

Three examples follow below.  Note that the bad field values, when 
interpreted as 48-bit signed numbers, are numerically small negative 
numbers (-25, -9, -3, respectively).

Excerpts from the fsck logs:
root: Inode 10748715, i_blocks is 281474976710631, should be 5. FIXED.
root: Inode 10751288, i_blocks is 281474976710647, should be 3. FIXED.
root: Inode 10748542, i_blocks is 281474976710653, should be 1. FIXED.

I don't know when the first two of these corruptions occurred, but the 
last one happened yesterday or the day before.  The file in question was 
/etc/fstab, and I discovered the problem after I had edited fstab on 
Wednesday and rebooted on Thursday.

The corrupted files can be read and copied without problems.  I have not 
dared to delete any of those files before fsck had fixed them.

What is going on here?

Thanks,
Jesper

-- 
Jesper Dybdal
https://www.dybdal.dk