CVE-2026-68096

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