linux-ext4 - [Bug] "kernel BUG in corrupted" in Linux kernel v6.14

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

Message-ID: <CAP=Rh=P0vsd4FVn+FUWpAM6v72CuD8tX27X9zzr6BhkKNDDjLg@mail.gmail.com>
Date: Wed, 21 May 2025 22:00:51 +0800
From: John <john.cs.hey@...il.com>
To: Andreas Dilger <adilger.kernel@...ger.ca>, "Theodore Ts'o" <tytso@....edu>
Cc: linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [Bug] "kernel BUG in corrupted" in Linux kernel v6.14

Dear Linux Kernel Maintainers,

I hope this message finds you well.

I am writing to report a potential vulnerability I encountered during
testing of the Linux Kernel version v6.14.

Git Commit: 38fec10eb60d687e30c8c6b5420d86e8149f7557 (tag: v6.14)

Bug Location: 0010:ext4_do_writepages+0x273d/0x32b0 fs/ext4/inode.c:2619

Bug report: https://pastebin.com/WwMypbdm

Complete log:https://pastebin.com/WvhAuSgQ

Entire kernel config: https://pastebin.com/MRWGr3nv

Root Cause Analysis:
The crash was caused by a fatal metadata inconsistency in an ext4
filesystem mounted from loop3.
The function ext4_mb_generate_buddy() detected a mismatch between the
block bitmap and group descriptor free cluster count (25 vs.
150994969), which indicates filesystem corruption.
This led to a forced kernel BUG() in ext4_do_writepages(), which was
invoked by the background writeback kernel worker.
The subsequent attempt to exit via do_exit() triggered another warning
due to an invalid instruction pointer, suggesting that the kernel
entered a corrupt execution state.
This bug is indicative of either a malformed or fuzzed ext4 image, or
a logic flaw in metadata accounting in ext4’s delayed allocation and
writeback path.

At present, I have not yet obtained a minimal reproducer for this
issue. However, I am actively working on reproducing it, and I will
promptly share any additional findings or a working reproducer as soon
as it becomes available.

Thank you very much for your time and attention to this matter. I
truly appreciate the efforts of the Linux kernel community.

Best regards,
John