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: <CAJNGr6uopyD6dYr2sFT-5k_3=Po-Cc43BKTnwDtaQuk8=Yh+BQ@mail.gmail.com>
Date: Fri, 16 May 2025 14:32:03 +0800
From: Guoyu Yin <y04609127@...il.com>
To: "Theodore Ts'o" <tytso@....edu>
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

Hi,

Thank you for your response and suggestions.I have implemented the
reproduction program based on your suggestions. With these changes, I
have successfully reproduced the kernel BUG in
ext4_mb_release_inode_pa, but the crash triggers after 5-8 runs on
average, please try a few more times.

The new C reproducer: https://pastebin.com/raw/jWYWQHPP

Best regards,
Guoyu

Theodore Ts'o <tytso@....edu> 于2025年5月15日周四 22:16写道：
>
> 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