linux-kernel - Re: [PATCH v2] ext4: synchronize free block counter when detecting corruption

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251106153035.GA3125470@mit.edu>
Date: Thu, 6 Nov 2025 10:30:35 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Albin Babu Varghese <albinbabuvarghese20@...il.com>
Cc: Andreas Dilger <adilger.kernel@...ger.ca>,
        syzbot+f3185be57d7e8dda32b8@...kaller.appspotmail.com,
        Ahmet Eray Karadag <eraykrdg1@...il.com>, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ext4: synchronize free block counter when detecting
 corruption

On Fri, Oct 10, 2025 at 03:38:00AM -0400, Albin Babu Varghese wrote:
> When ext4_mb_generate_buddy() detects block group descriptor
> corruption (free block count mismatch between descriptor and
> bitmap), it corrects the in-memory group descriptor (grp->bb_free)
> but does not synchronize the percpu free clusters counter.

Actually, we do.  This happens in ext4_mark_group_bitmap_corrupted in
fs/ext4/super.c.

	if (flags & EXT4_GROUP_INFO_BBITMAP_CORRUPT) {
		ret = ext4_test_and_set_bit(EXT4_GROUP_INFO_BBITMAP_CORRUPT_BIT,
					    &grp->bb_state);
		if (!ret)
			percpu_counter_sub(&sbi->s_freeclusters_counter,
					   grp->bb_free);
	}

So we've *already* subtracted out the blocks that were in the block
group which we've busied out.

> This causes delayed allocation to read stale counter values when
> checking for available space. The allocator believes space is
> available based on the stale counter, makes reservation promises,
> but later fails during writeback when trying to allocate actual
> blocks from the bitmap. This results in "Delayed block allocation
> failed" errors and potential system crashes.

I suspect there is something else going on with s_freeclusters_counter
being incorrect, but adding an additional correction to
s_freeclusters_counter is not the answer.

How is the system crashing?  If we have errors=continue, then we
really shouldn't let the system crash.  If there is delayed allocation
failures, the user might lose data, but if the user really cares about
that, they shouldn't be using errors=continue.

						- Ted