linux-kernel - Re: INFO: task hung in add_transaction

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

Date:   Tue, 4 Jan 2022 15:33:16 +0100
From:   Jan Kara <jack@...e.cz>
To:     kvartet <xyru1999@...il.com>
Cc:     Theodore Ts'o <tytso@....edu>, Jan Kara <jack@...e.com>,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzkaller-bugs@...glegroups.com, sunhao.th@...il.com
Subject: Re: INFO: task hung in add_transaction_credits

Hello!

On Tue 04-01-22 18:30:47, kvartet wrote:
> When using Syzkaller to fuzz the latest Linux kernel, the following
> crash was triggered.
> 
> HEAD commit: a7904a538933 Linux 5.16-rc6
> git tree: upstream
> console output: https://paste.ubuntu.com/p/N2WMbfsc5s/plain/
> kernel config: https://paste.ubuntu.com/p/FDDNHDxtwz/plain/
> 
> Sorry, I don't have a reproducer for this crash, hope the symbolized
> report can help.
> 
> If you fix this issue, please add the following tag to the commit:
> Reported-by: Yiru Xu <xyru1999@...il.com>

Thanks for report. I had a look into the stacktraces. What is clear is that
there are several processes waiting in wait_transaction_locked() meaning
that we want to commit a transaction and wait while there are still active
handles attached to the transaction. I can also infer that the process
holding the handle for the transaction is:

4 locks held by syz-executor.1/20606:
 #0: ffff88810c7ec460 (sb_writers#5){.+.+}-{0:0}, at:
filename_create+0xf3/0x490 fs/namei.c:3649
 #1: ffff888028ff7198 (&type->i_mutex_dir_key#4/1){+.+.}-{3:3}, at:
inode_lock_nested include/linux/fs.h:818 [inline]
 #1: ffff888028ff7198 (&type->i_mutex_dir_key#4/1){+.+.}-{3:3}, at:
filename_create+0x158/0x490 fs/namei.c:3654
 #2: ffff88810c7f8990 (jbd2_handle){++++}-{0:0}, at:
start_this_handle+0xf58/0x1360 fs/jbd2/transaction.c:466
 #3: ffff8880287f2e28 (&mapping->i_mmap_rwsem){++++}-{3:3}, at:
i_mmap_lock_read include/linux/fs.h:513 [inline]
 #3: ffff8880287f2e28 (&mapping->i_mmap_rwsem){++++}-{3:3}, at:
rmap_walk_file+0x86d/0xc20 mm/rmap.c:2345

What is not obvious though is why this task is blocked and does not
eventually release the transaction handle. For that we would need a
stacktrace of this task...

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