https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843
There is a problem in multiple stable kernel releases that is causing data corruption in ext4 filesystems. It is caused by a problematic commit that is in multiple stable kernels:
The commit got merged in 6.5-rc1 so all stable kernels that have 91562895f803 (“ext4: properly sync file size update after O_SYNC direct IO”) before 6.5 are corrupting data - I’ve noticed at least 6.1 is still carrying the problematic commit.
More information can be found in a Debian bug report. It has also delayed the release of Debian 12.3 images. “Please do not upgrade any systems at this time, we urge caution for users with UnattendeUpgrades configured.”
Source:
So please if you do still use LTS kernel with versions smaller 6.1.66-1 please update asap!
The effected versions are [6.1.64-1] and [6.1.65-1]
It is fixed in 6.1.66-1 current is linux-lts 6.1.67-1.
Thank’s to Prathamesh Rockmonstr and indeed also Luis Vegas on Telegram for the hint!
7 Likes
non-serious data loss my @ss! 
2 Likes
@joekamprad
Was Arch even affected?
It seems to be Debian exclusive fucky-wucky, as far as report goes… 
1 Like
it mentions kernel versions arch was using too 6.1.64-1 and 6.1.65-1 and even 6.5 kernels ?
Due to a problematic patch back-ported from Linux 6.5
(https://www.phoronix.com/news/Debian-123-Delayed-EXT4-Corrupt)
and:
The commit got merged in 6.5-rc1 so all stable kernels that have 91562895f803 (“ext4: properly sync file size update after O_SYNC direct IO”) before 6.5 are corrupting data
(https://lwn.net/Articles/954285/)
but:
- Kernels >= 6.5 are not affected, as they will also have 936e114a245b6 (iomap commit)
In the end ? i was only feel right about reporting… in real life? i do not see any users reporting this here?
arch?
https://bbs.archlinux.org/viewtopic.php?id=290989
Hmm confusing…
4 Likes
I guess they don’t know it yet…since it’s “non-serious”
2 Likes
what does it even mean? in case of it is not fatal i bet… but a non-serious filesystem corruption… as the one over at phoronix wrote must be something revertable… in the arch thread there are links to scripts you can use to validate also… i could check …
1 Like
Good questions…Likely revertible, since they advice to fsck
1 Like
https://lwn.net/Articles/954364/
tst_device.c:96: TINFO: Found free device 0 '/dev/loop0'
tst_test.c:1690: TINFO: LTP version: 20230929-201-ge32735252
tst_test.c:1574: TINFO: Timeout per run is 0h 00m 30s
tst_supported_fs_types.c:149: TINFO: WARNING: testing only ext4
tst_supported_fs_types.c:90: TINFO: Kernel supports ext4
tst_supported_fs_types.c:55: TINFO: mkfs.ext4 does exist
tst_test.c:1650: TINFO: === Testing on ext4 ===
tst_test.c:1105: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
mke2fs 1.47.0 (5-Feb-2023)
tst_test.c:1119: TINFO: Mounting /dev/loop0 to /tmp/LTP_preEkfVsw/mntpoint fstyp=ext4 flags=0
preadv03.c:102: TINFO: Using block size 512
preadv03.c:87: TPASS: preadv(O_DIRECT) read 512 bytes successfully with content 'a' expectedly
preadv03.c:87: TPASS: preadv(O_DIRECT) read 512 bytes successfully with content 'a' expectedly
preadv03.c:87: TPASS: preadv(O_DIRECT) read 512 bytes successfully with content 'b' expectedly
Summary:
passed 3
failed 0
broken 0
skipped 0
warnings 0
2 Likes
Affects only pepe and clown directories 
luckily no one reporting data loss … serious!
not really sure …
