| 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
| ||
|
Message-ID: <20241112073421.GD1458936@google.com>
Date: Tue, 12 Nov 2024 16:34:21 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Theodore Ts'o <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>
Cc: linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: ext4: possible circular locking dependency at ext4_xattr_inode_create
Hi,
I've a following syzkaller report (no reproducer); the report is
against 5.15, but the same call-chain seems possible in current
upstream as well. So I suspect that maybe ext4_xattr_inode_create()
should take nested inode_lock (I_MUTEX_XATTR) instead. Does the
patch below make any sense?
======================================================
WARNING: possible circular locking dependency detected
5.15.168-syzkaller-23766-g3f37c55c6291 #0 Not tainted
------------------------------------------------------
syz-executor297/1452 is trying to acquire lock:
ffff888120b5e750 (&ea_inode->i_rwsem#8/1){+.+.}-{3:3}, at: inode_lock
ffff888120b5e750 (&ea_inode->i_rwsem#8/1){+.+.}-{3:3}, at: ext4_xattr_inode_create
ffff888120b5e750 (&ea_inode->i_rwsem#8/1){+.+.}-{3:3}, at: ext4_xattr_inode_lookup_create
ffff888120b5e750 (&ea_inode->i_rwsem#8/1){+.+.}-{3:3}, at: ext4_xattr_set_entry+0x2aeb/0x3200
but task is already holding lock:
ffff888120b58c68 (&ei->i_data_sem/3){++++}-{3:3}, at: ext4_setattr+0x12b5/0x1950
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&ei->i_data_sem/3){++++}-{3:3}:
down_write+0x38/0x60
ext4_update_i_disksize
ext4_xattr_inode_write
ext4_xattr_inode_lookup_create
ext4_xattr_set_entry+0x2839/0x3200
ext4_xattr_ibody_set+0x113/0x320
ext4_xattr_set_handle+0xa31/0x1440
ext4_xattr_set+0x266/0x3d0
__vfs_setxattr+0x15e/0x1c0
__vfs_setxattr_noperm+0x128/0x5e0
vfs_setxattr+0x1c6/0x410
setxattr+0x1d6/0x270
path_setxattr+0x1cc/0x2b0
__do_sys_lsetxattr
__se_sys_lsetxattr
__x64_sys_lsetxattr+0xb4/0xd0
do_syscall_x64
do_syscall_64+0x69/0xc0
entry_SYSCALL_64_after_hwframe+0x66/0xd0
-> #0 (&ea_inode->i_rwsem#8/1){+.+.}-{3:3}:
check_prev_add
check_prevs_add
validate_chain
__lock_acquire+0x2c95/0x7850
lock_acquire+0x1d2/0x4e0
down_write+0x38/0x60
inode_lock
ext4_xattr_inode_create
ext4_xattr_inode_lookup_create
ext4_xattr_set_entry+0x2aeb/0x3200
ext4_xattr_block_set+0xdc1/0x2de0
ext4_xattr_move_to_block
ext4_xattr_make_inode_space
ext4_expand_extra_isize_ea+0xe58/0x19c0
__ext4_expand_extra_isize+0x2fd/0x400
ext4_try_to_expand_extra_isize
__ext4_mark_inode_dirty+0x58b/0x840
ext4_setattr+0x1341/0x1950
notify_change+0xafb/0xd80
do_truncate+0x218/0x2f0
handle_truncate
do_open
path_openat+0x27d3/0x2e10
do_filp_open+0x23a/0x360
do_sys_openat2+0x188/0x720
do_sys_open+0x1d1/0x220
do_syscall_x64
do_syscall_64+0x69/0xc0
entry_SYSCALL_64_after_hwframe+0x66/0xd0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ei->i_data_sem/3);
lock(&ea_inode->i_rwsem#8/1);
lock(&ei->i_data_sem/3);
lock(&ea_inode->i_rwsem#8/1);
*** DEADLOCK ***
5 locks held by syz-executor297/1452:
#0: ffff88811231c460 (sb_writers#5){.+.+}-{0:0}, at: mnt_want_write+0x3b/0x80
#1: ffff888120b58de0 (&sb->s_type->i_mutex_key#8){++++}-{3:3}, at: inode_lock
#1: ffff888120b58de0 (&sb->s_type->i_mutex_key#8){++++}-{3:3}, at: do_truncate+0x204/0x2f0
#2: ffff888120b58f80 (mapping.invalidate_lock){++++}-{3:3}, at: filemap_invalidate_lock
#2: ffff888120b58f80 (mapping.invalidate_lock){++++}-{3:3}, at: ext4_setattr+0xd49/0x1950
#3: ffff888120b58c68 (&ei->i_data_sem/3){++++}-{3:3}, at: ext4_setattr+0x12b5/0x1950
#4: ffff888120b58ab8 (&ei->xattr_sem){++++}-{3:3}, at: ext4_write_trylock_xattr
#4: ffff888120b58ab8 (&ei->xattr_sem){++++}-{3:3}, at: ext4_try_to_expand_extra_isize
#4: ffff888120b58ab8 (&ei->xattr_sem){++++}-{3:3}, at: __ext4_mark_inode_dirty+0x4f7/0x840
stack backtrace:
Call Trace:
<TASK>
__dump_stack
dump_stack_lvl+0x1e3/0x2d0
check_noncircular+0x2f3/0x3a0
check_prev_add
check_prevs_add
validate_chain
__lock_acquire+0x2c95/0x7850
lock_acquire+0x1d2/0x4e0
down_write+0x38/0x60
inode_lock
ext4_xattr_inode_create
ext4_xattr_inode_lookup_create
ext4_xattr_set_entry+0x2aeb/0x3200
ext4_xattr_block_set+0xdc1/0x2de0
ext4_xattr_move_to_block
ext4_xattr_make_inode_space
ext4_expand_extra_isize_ea+0xe58/0x19c0
__ext4_expand_extra_isize+0x2fd/0x400
ext4_try_to_expand_extra_isize
__ext4_mark_inode_dirty+0x58b/0x840
ext4_setattr+0x1341/0x1950
notify_change+0xafb/0xd80
do_truncate+0x218/0x2f0
handle_truncate
do_open
path_openat+0x27d3/0x2e10
do_filp_open+0x23a/0x360
do_sys_openat2+0x188/0x720
do_sys_open+0x1d1/0x220
do_syscall_x64
do_syscall_64+0x69/0xc0
entry_SYSCALL_64_after_hwframe+0x66/0xd0
---
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7647e9f6e190..db3c68fbbadf 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1511,7 +1511,7 @@ static struct inode *ext4_xattr_inode_create(handle_t *handle,
*/
dquot_free_inode(ea_inode);
dquot_drop(ea_inode);
- inode_lock(ea_inode);
+ inode_lock_nested(inode, I_MUTEX_XATTR);
ea_inode->i_flags |= S_NOQUOTA;
inode_unlock(ea_inode);
}
Powered by blists - more mailing lists