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: <pzyayvjhburtp74auzd7weq73ndy3lttv4e3tw5cpxwlokvkgg@r5v6qjxolxfq>
Date: Tue, 14 Jan 2025 13:29:21 +0100
From: Jan Kara <jack@...e.cz>
To: Heming Zhao <heming.zhao@...e.com>
Cc: Jan Kara <jack@...e.cz>, Liebes Wang <wanghaichi0403@...il.com>, 
	tytso@....edu, 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 14-01-25 14:25:21, Heming Zhao wrote:
> Hi Jan,
> 
> On 1/6/25 23:14, Jan Kara wrote:
> > On Tue 31-12-24 13:53:23, Liebes Wang wrote:
> > > Dear Linux maintainers and reviewers:
> > > 
> > > We are reporting a Linux kernel bug titled **WARNING in
> > > jbd2_journal_update_sb_log_tail**, discovered using a modified version of
> > > Syzkaller.
> > 
> > Very likely this is actually some issue with ocfs2 since the only thing the
> > reproducer seems to be doing is that it is mounting ocfs2 image. Joseph,
> > can you have a look please?
> > 
> 
> The root cause appears to be that the jbd2 bypass recovery logic
> is incorrect.
> 
> From the console log [1]:
>  [   70.568684][ T5316] JBD2: Ignoring recovery information on journal
> 
> The above output indicates that ocfs2 is calling jbd2_journal_wipe()
> to clean up jbd2. (IIUC), Therefore, the subsequent jbd2 initialization
> flow should not perform any recovery tasks.
> 
> However, in this crash issue, after calling jbd2_journal_wipe(),
> jbd2_journal_load() still attempts to perform a recovery, which triggers
> a WARN_ON().
> 
> On the other hand, the jbd2 code logic is correct, ocfs2 should call
> ocfs2_journal_wipe() with the parameter 'write=1' to address this issue.
> 
> code flow:
> ocfs2_mount_volume
>  ocfs2_check_volume
>  + ocfs2_journal_init => jbd2_journal_init_inode
>  + ocfs2_journal_wipe => jbd2_journal_wipe (input write is 0)
>  + ocfs2_journal_load => jbd2_journal_load => do recovery job => WARN_ON()
> 
> [1]: 2024/01/12 06:56 log
> https://syzkaller.appspot.com/text?tag=CrashLog&x=106f2bc4580000

Ah, ok. So the problem essentially is that OCFS2 journal inode has
OCFS2_JOURNAL_DIRTY_FL cleared (hence ocfs2_journal_wipe() is called) but
the journal actually has journal->j_head != journal->j_tail and hence
recovery will replay transactions. I guess calling jbd2_journal_wipe()
with write==1 makes sense (if writing to the block device is allowed).

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR