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

Message-ID: <CAJNGr6t6cpo3zjANpYObZaWOSeGKdGW4B4+k1Bh2ZWQZBbJrBg@mail.gmail.com>
Date: Thu, 15 May 2025 17:58:40 +0800
From: Guoyu Yin <y04609127@...il.com>
To: tytso@....edu
Cc: adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: [BUG] kernel BUG in ext4_mb_release_inode_pa

Hi,

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.

The call trace indicates that the crash happens when closing a file
via the close system call, with ext4_discard_preallocations invoking
ext4_mb_release_inode_pa. Preliminary analysis suggests this could be
caused by filesystem metadata corruption or unsynchronized concurrent
operations. I recommend reviewing the EXT4 preallocated block
management logic, especially in concurrent scenarios and metadata
consistency.

This can be reproduced on:

HEAD commit:

38fec10eb60d687e30c8c6b5420d86e8149f7557

report: https://pastebin.com/raw/DbusXrC3

console output : https://pastebin.com/raw/rjVjX2cb

kernel config : https://pastebin.com/raw/u0Efyj5P

C reproducer : https://pastebin.com/raw/iKzXm7Ut