In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
audit: fix recursive locking deadlock in audit_dupe_exe()<\/p>\n
A deadlock occurs in the audit subsystem when duplicating
\nexecutable-related rules.<\/p>\n
When a file is moved (e.g., via do_renameat2()), the VFS layer locks
\nthe parent directory (I_MUTEX_PARENT), which synchronously triggers an
\nfsnotify_move event. If an existing executable audit rule matches the
\nfile being moved, the audit subsystem catches this event and calls
\naudit_dupe_exe() to duplicate the watch and update the rule. Then,
\naudit_alloc_mark() would call kern_path_parent() to resolve the path,
\nleading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock
\nalready held by the task, resulting in the following recursive locking
\ndeadlock:<\/p>\n
============================================
\n WARNING: possible recursive locking detected
\n 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted
\n ——————————————–
\n mv\/5099 is trying to acquire lock:
\n ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key\/1){+.+.}-{3:3},
\n at: __kern_path_locked+0x10a\/0x2f0<\/p>\n
but task is already holding lock:
\n ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key\/1){+.+.}-{3:3},
\n at: lock_two_directories+0x13f\/0x2b0<\/p>\n
other info that might help us debug this:
\n Possible unsafe locking scenario:<\/p>\n
CPU0
\n —-
\n lock(&inode->i_sb->s_type->i_mutex_dir_key\/1);
\n lock(&inode->i_sb->s_type->i_mutex_dir_key\/1);<\/p>\n
*** DEADLOCK ***<\/p>\n
May be due to missing lock nesting notation<\/p>\n
6 locks held by mv\/5099:
\n #0: ffff888112a9c440 (sb_writers#13)
\n at: do_renameat2+0x34c\/0xbc0
\n #1: ffff888112a9c790 (&type->s_vfs_rename_key#3)
\n at: do_renameat2+0x415\/0xbc0
\n #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key\/1)
\n at: lock_two_directories+0x13f\/0x2b0
\n #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key\/5)
\n at: lock_two_directories+0x175\/0x2b0
\n #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu)
\n at: fsnotify+0x454\/0x28a0
\n #5: ffffffffaf886230 (audit_filter_mutex)
\n at: audit_update_watch+0x36\/0x11e0<\/p>\n
stack backtrace:
\n Call Trace:<\/p>\n
dump_stack_lvl+0x6f\/0xb0
\n print_deadlock_bug.cold+0xbd\/0xca
\n validate_chain+0x83a\/0xf00
\n __lock_acquire+0xcac\/0x1d20
\n lock_acquire.part.0+0x11b\/0x360
\n down_write_nested+0x9f\/0x230
\n __kern_path_locked+0x10a\/0x2f0
\n kern_path_locked+0x26\/0x40
\n audit_alloc_mark+0xfb\/0x4f0
\n audit_dupe_exe+0x6c\/0xe0
\n audit_dupe_rule+0x6c2\/0xc00
\n audit_update_watch+0x4cc\/0x11e0
\n audit_watch_handle_event+0x12c\/0x1b0
\n send_to_group+0x5d0\/0x8b0
\n fsnotify+0x615\/0x28a0
\n fsnotify_move+0x1d8\/0x630
\n vfs_rename+0xdcd\/0x1df0
\n do_renameat2+0x9d4\/0xbc0
\n __x64_sys_renameat+0x192\/0x260
\n do_syscall_64+0x92\/0x180
\n entry_SYSCALL_64_after_hwframe+0x76\/0x7e
\n RIP: 0033:0x7f0491fe8c4e
\n Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff
\n c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05
\n 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89
\n RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108
\n RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e
\n RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c
\n RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
\n R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a
\n R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c<\/p>\n
The aforementioned deadlock can be consistently reproduced by running
\nthe script below:<\/p>\n
audit-dupe-exe-deadlock.sh
\n ————————–
\n #!\/bin\/bash
\n auditctl -D
\n mkdir -p \/tmp\/foo
\n touch \/tmp\/file
\n auditctl -a always,exit -F exe=\/tmp\/file -F path=\/tmp\/file -S all -k dr
\n mv \/tmp\/file \/tmp\/foo\/file
\n rm -Rf \/tmp\/foo<\/p>\n
This patch fixes the issue by introducing struct audit_watch_ctx to pass
\nthe fsnotify event context down to audit_alloc_mark(). By utilizing the
\nalready-resolved directory inode provided by the event, we bypass the
\nkern_path_parent() path resol
\n—truncated—<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
audit: fix recursive locking deadlock in audit_dupe_exe()<\/p>\n
A deadlock occurs in the audit subsystem when duplicating
\nexecutable-rel<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-5321","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/5321","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5321"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5321"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5321"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}