linux-kernel - Re: WARNING in jbd2_journal_update_sb_log

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

Message-ID: <20250114133815.GA1997324@mit.edu>
Date: Tue, 14 Jan 2025 08:38:15 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Heming Zhao <heming.zhao@...e.com>
Cc: Jan Kara <jack@...e.cz>, Liebes Wang <wanghaichi0403@...il.com>,
        jack@...e.com, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org, syzkaller@...glegroups.com,
        Joseph Qi <joseph.qi@...ux.alibaba.com>, ocfs2-devel@...ts.linux.dev
Subject: Re: WARNING in jbd2_journal_update_sb_log_tail

On Tue, Jan 14, 2025 at 02:25:21PM +0800, Heming Zhao wrote:
> 
> The root cause appears to be that the jbd2 bypass recovery logic
> is incorrect.

Heming, thanks for taking a look.

I'm not convinced the root cause is what you've stated.  When
jbd2_journal_wipe() calls jbd2_mark_journal_empty(), s_start gets set
to zero:

	sb->s_start    = cpu_to_be32(0);

This then gets checked in jbd2_journal_recovery:

	if (!sb->s_start) {
		jbd2_debug(1, "No recovery required, last transaction %d, head block %u\n",
			  be32_to_cpu(sb->s_sequence), be32_to_cpu(sb->s_head));
		journal->j_transaction_sequence = be32_to_cpu(sb->s_sequence) + 1;
		journal->j_head = be32_to_cpu(sb->s_head);
		return 0;
	}

I suspect that there is something else wrong with jbd2's superblock,
since this normally works in the absence of malicious fs image
fuzzing, such that when jbd2_journal_load() calls reset_journal()
after jbd2_journal_recover() correctly bypasses recovery, the WARN_ON
gets triggered.

I'd suggest that you enable jbd2 debugging so we can see all of the
jbd2_debug() message to understand what might be going on.

By the way, given that this is only a WARN_ON, and it involves
malicious image fuzzing, this is probably a valid jbd2 bug, but it's
not actually a security bug.  Sure, someone silly enough to pick up a
maliciously corrupted USB thumb drive dropped in a parking lot and
insert it into their desktop, and the distribution is silly enoough to
allow automount, the worse that can happen is that the system to
reboot if the system is configured to panic on a WARNING.  So feel
free to prioritize your investigation appropriately.  :-)

Cheers,

						- Ted