Hello,
I am writing to report a potential vulnerability identified in the
Linux Kernel version 5.15.169. This issue was discovered using our
custom vulnerability discovery tool.
Affected File: fs/ext4/inode.c
File: fs/ext4/inode.c
Function: ext4_map_blocks
Detailed Call Stack:
------------[ cut here begin]------------
WARNING: possible circular locking dependency detected
------------------------------------------------------
the task is trying to acquire lock:
ffff888018a76428 (&dquot->dq_lock){+.+.}-{3:3}, at:
dquot_commit+0x4d/0x4c0 fs/quota/dquot.c:507
but other task is already holding lock:
ffff88800833a9b8 (&ei->i_data_sem/2){++++}-{3:3}, at:
ext4_map_blocks+0x686/0x1870 fs/ext4/inode.c:665
which lock already depends on the new lock.
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
check_noncircular+0x263/0x2e0 kernel/locking/lockdep.c:2133
check_prev_add kernel/locking/lockdep.c:3053 [inline]
check_prevs_add kernel/locking/lockdep.c:3172 [inline]
validate_chain kernel/locking/lockdep.c:3788 [inline]
__lock_acquire+0x2b72/0x6070 kernel/locking/lockdep.c:5012
lock_acquire kernel/locking/lockdep.c:5623 [inline]
lock_acquire+0x194/0x470 kernel/locking/lockdep.c:5588
__mutex_lock_common kernel/locking/mutex.c:596 [inline]
__mutex_lock+0x135/0x12c0 kernel/locking/mutex.c:729
dquot_commit+0x4d/0x4c0 fs/quota/dquot.c:507
ext4_write_dquot+0x254/0x3f0 fs/ext4/super.c:6173
ext4_mark_dquot_dirty fs/ext4/super.c:6233 [inline]
ext4_mark_dquot_dirty+0x111/0x1b0 fs/ext4/super.c:6227
mark_dquot_dirty fs/quota/dquot.c:372 [inline]
mark_all_dquot_dirty fs/quota/dquot.c:412 [inline]
__dquot_free_space+0x829/0xbd0 fs/quota/dquot.c:1940
dquot_free_space_nodirty include/linux/quotaops.h:376 [inline]
dquot_free_space include/linux/quotaops.h:381 [inline]
dquot_free_block include/linux/quotaops.h:392 [inline]
ext4_mb_clear_bb fs/ext4/mballoc.c:6156 [inline]
ext4_free_blocks+0x1cc1/0x2200 fs/ext4/mballoc.c:6286
ext4_remove_blocks fs/ext4/extents.c:2523 [inline]
ext4_ext_rm_leaf fs/ext4/extents.c:2689 [inline]
ext4_ext_remove_space+0x1e96/0x3ce0 fs/ext4/extents.c:2937
ext4_ext_truncate+0x1ea/0x250 fs/ext4/extents.c:4471
ext4_truncate+0xc37/0x1160 fs/ext4/inode.c:4249
ext4_evict_inode+0xac2/0x1a50 fs/ext4/inode.c:289
evict+0x32c/0x820 fs/inode.c:622
iput_final fs/inode.c:1744 [inline]
iput.part.0+0x4b6/0x6d0 fs/inode.c:1770
iput+0x58/0x70 fs/inode.c:1760
ext4_orphan_cleanup+0x565/0xf80 fs/ext4/orphan.c:474
ext4_fill_super+0x8bb5/0xc920 fs/ext4/super.c:4975
mount_bdev+0x336/0x400 fs/super.c:1400
legacy_get_tree+0x106/0x220 fs/fs_context.c:611
vfs_get_tree+0x8e/0x300 fs/super.c:1530
do_new_mount fs/namespace.c:3012 [inline]
path_mount+0x138a/0x1ff0 fs/namespace.c:3342
do_mount fs/namespace.c:3355 [inline]
__do_sys_mount fs/namespace.c:3563 [inline]
__se_sys_mount fs/namespace.c:3540 [inline]
__x64_sys_mount+0x282/0x300 fs/namespace.c:3540
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x33/0x80 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x6c/0xd6
RIP: 0033:0x7fe399de916a
Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb a6 e8 de 1a 00 00 66 2e 0f
1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe3989b4e68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007fe3989b4ef0 RCX: 00007fe399de916a
RDX: 0000000020000040 RSI: 0000000020000500 RDI: 00007fe3989b4eb0
RBP: 0000000020000040 R08: 00007fe3989b4ef0 R09: 0000000000004500
R10: 0000000000004500 R11: 0000000000000246 R12: 0000000020000500
R13: 00007fe3989b4eb0 R14: 00000000000004b4 R15: 000000000000002c
------------[ cut here end]------------
Root Cause:
The crash is caused by a potential circular locking dependency
detected within the Linux kernel's Ext4 filesystem during quota
management operations. Specifically, the task is attempting to acquire
the dq_lock (&dquot->dq_lock) in the dquot_commit function
(fs/quota/dquot.c:507) while another task already holds the i_data_sem
lock (&ei->i_data_sem) in the ext4_map_blocks function
(fs/ext4/inode.c:665). This situation creates a circular dependency
where each lock is waiting for the other to be released, which can
lead to a deadlock. The call trace reveals that the issue arises
during the writeback process (wb_workfn) when the filesystem is trying
to commit quota information (dquot_commit) while simultaneously
handling inode data (ext4_map_blocks). The Kernel Lock Validator
(lockdep) has flagged this as a possible circular dependency because
the existing lock (i_data_sem) already depends on the new lock
(dq_lock), violating the expected lock acquisition order. This
improper lock ordering within the Ext4 quota handling and inode
management paths indicates a flaw in the synchronization mechanisms,
potentially caused by concurrent operations or incorrect lock
hierarchy implementation. As a result, the kernel emits a warning to
prevent a deadlock scenario, highlighting the need for revising the
locking strategy to ensure that locks are acquired in a consistent and
non-circular manner.
Thank you for your time and attention.
Best regards
Wall
