linux-ext4 - Re: [BUG] kernel BUG in ext4_mb_release_inode

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

Message-ID: <20250515141643.GB325737@mit.edu>
Date: Thu, 15 May 2025 10:16:43 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Guoyu Yin <y04609127@...il.com>
Cc: adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [BUG] kernel BUG in ext4_mb_release_inode_pa

On Thu, May 15, 2025 at 05:58:40PM +0800, Guoyu Yin wrote:
> 
> I discovered a kernel crash described as "kernel BUG in
> ext4_mb_release_inode_pa." This issue occurs in the EXT4 filesystem's
> ext4_mb_release_inode_pa function (fs/ext4/mballoc.c:5339), where a
> BUG() assertion fails due to a mismatch between the calculated free
> block count free and the expected value pa->pa_free during
> preallocated block release.

I can't reproduce the BUG using qemu,with the kernel config, kernel
commit, and C reproducer that you have provided.  This is why I
strongly suggest that if people really feel the need to set up their
own syzkaller instances, perhaps because they are maing changes to
syzkaller, that they replicate the full syzkaler setup, including the
web dashboard and e-mail responder so that people can request that the
reproducer be run on your setup so we can figure out how easily
reproducible the report might be, and whether it has been fixed in a
more recent kernel version, or via a proposed bug fix.

You are most likely correct that it is caused by a corrupted file
system, and this is why I strongly recommend that users run fsck -y on
any file system image of uncertain provenance before trying to mount
said file system.  In addition, note that if the file system had been
mounted with errors=remount-ro, the problem wouldn't have resulted in
a BUG.  For this reason, especially when the C reprducer doesn't
reproduce the reported issue, this sorts of issues are a very low
priority to investigate.

Best regards,

					- Ted