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: <24f378c8-7a27-47b8-bd79-dba4a2e92f6d@suse.com>
Date: Tue, 14 Jan 2025 14:25:21 +0800
From: Heming Zhao <heming.zhao@...e.com>
To: Jan Kara <jack@...e.cz>, Liebes Wang <wanghaichi0403@...il.com>
Cc: 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

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?
> 
> 								Honza

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

Thanks,
Heming

> 
>> Linux version: v6.12-rc6:59b723cd2adbac2a34fc8e12c74ae26ae45bf230 (crash is
>> also reproduced in the latest kernel version)
>> The test case and kernel config is in attach.
>>
>> The warning report is (The full report is attached):
>>
>> WARNING: CPU: 0 PID: 6139 at fs/jbd2/journal.c:1887
>> jbd2_journal_update_sb_log_tail+0x32d/0x3b0 fs/jbd2/journal.c:1887
>> Modules linked in:
>> CPU: 0 UID: 0 PID: 6139 Comm: syz.7.135 Not tainted 6.12.0-rc6 #1
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> 1.13.0-1ubuntu1.1 04/01/2014
>> RIP: 0010:jbd2_journal_update_sb_log_tail+0x32d/0x3b0 fs/jbd2/journal.c:1887
>> Code: fe ff ff e8 05 0e a7 ff e9 f4 fd ff ff e8 eb 0e a7 ff e9 16 ff ff ff
>> 4c 89 ef e8 de 0e a7 ff e9 d5 fe ff ff e8 94 ec 54 ff 90 <0f> 0b 90 eb 88
>> 41 bc fb ff ff ff e9 13 ff ff ff e8 7e ec 54 ff be
>> RSP: 0018:ff1100013b6ff818 EFLAGS: 00010246
>> RAX: 0000000000040000 RBX: 0000000000000000 RCX: ffa00000034b3000
>> RDX: 0000000000040000 RSI: ffffffff81fd15ec RDI: 0000000000000005
>> RBP: ff110001405ce000 R08: 0000000000000001 R09: ffe21c00276dfef5
>> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>> R13: ff11000107e3a018 R14: ff11000107e3a000 R15: ff110001405ce0b0
>> FS:  00007ff345cd5700(0000) GS:ff110004ca800000(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00007ff3470375c0 CR3: 0000000117544001 CR4: 0000000000771ef0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> PKRU: 80000000
>> Call Trace:
>>   <TASK>
>>   journal_reset fs/jbd2/journal.c:1779 [inline]
>>   jbd2_journal_load fs/jbd2/journal.c:2109 [inline]
>>   jbd2_journal_load+0x93e/0xcf0 fs/jbd2/journal.c:2074
>>   ocfs2_journal_load+0xbe/0x5e0 fs/ocfs2/journal.c:1143
>>   ocfs2_check_volume fs/ocfs2/super.c:2421 [inline]
>>   ocfs2_mount_volume fs/ocfs2/super.c:1817 [inline]
>>   ocfs2_fill_super+0x19f1/0x4170 fs/ocfs2/super.c:1084
>>   mount_bdev+0x1e6/0x2d0 fs/super.c:1693
>>   legacy_get_tree+0x107/0x220 fs/fs_context.c:662
>>   vfs_get_tree+0x94/0x380 fs/super.c:1814
>>   do_new_mount fs/namespace.c:3507 [inline]
>>   path_mount+0x6b2/0x1eb0 fs/namespace.c:3834
>>   do_mount fs/namespace.c:3847 [inline]
>>   __do_sys_mount fs/namespace.c:4057 [inline]
>>   __se_sys_mount fs/namespace.c:4034 [inline]
>>   __x64_sys_mount+0x283/0x300 fs/namespace.c:4034
>>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>>   do_syscall_64+0xc1/0x1d0 arch/x86/entry/common.c:83
>>   entry_SYSCALL_64_after_hwframe+0x77/0x7f