CVE-2026-68096

In the Linux kernel, the following vulnerability has been resolved:

audit: fix recursive locking deadlock in auditdupeexe()

A deadlock occurs in the audit subsystem when duplicating executable-related rules.

When a file is moved (e.g., via dorenameat2()), the VFS layer locks the parent directory (IMUTEXPARENT), which synchronously triggers an fsnotifymove event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls auditdupeexe() to duplicate the watch and update the rule. Then, auditallocmark() would call kernpathparent() to resolve the path, leading to a blind attempt to acquire the exact same IMUTEXPARENT lock already held by the task, resulting in the following recursive locking deadlock:

============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el100.x8664+debug #1 Not tainted

mv/5099 is trying to acquire lock: ffff888132845358 (&inode->isb->stype->imutexdir_key/1){+.+.}-{3:3}, at: __kernpathlocked+0x10a/0x2f0

but task is already holding lock: ffff888132846b58 (&inode->isb->stype->imutexdirkey/1){+.+.}-{3:3}, at: locktwo_directories+0x13f/0x2b0

other info that might help us debug this: Possible unsafe locking scenario:

    CPU0
    ----

lock(&inode->isb->stype->imutexdirkey/1); lock(&inode->isb->stype->imutexdirkey/1);

*** DEADLOCK ***

May be due to missing lock nesting notation

6 locks held by mv/5099: #0: ffff888112a9c440 (sbwriters#13) at: dorenameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->svfsrenamekey#3) at: dorenameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->isb->stype->imutexdirkey/1) at: locktwodirectories+0x13f/0x2b0 #3: ffff888132845358 (&inode->isb->stype->imutexdirkey/5) at: locktwodirectories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotifymarksrcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (auditfiltermutex) at: auditupdatewatch+0x36/0x11e0

stack backtrace: Call Trace: <TASK> dumpstacklvl+0x6f/0xb0 printdeadlockbug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lockacquire+0xcac/0x1d20 lockacquire.part.0+0x11b/0x360 downwritenested+0x9f/0x230 __kernpathlocked+0x10a/0x2f0 kernpathlocked+0x26/0x40 auditallocmark+0xfb/0x4f0 auditdupeexe+0x6c/0xe0 auditduperule+0x6c2/0xc00 auditupdatewatch+0x4cc/0x11e0 auditwatchhandleevent+0x12c/0x1b0 sendtogroup+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotifymove+0x1d8/0x630 vfsrename+0xdcd/0x1df0 dorenameat2+0x9d4/0xbc0 _x64sysrenameat+0x192/0x260 dosyscall64+0x92/0x180 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIGRAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c </TASK>

The aforementioned deadlock can be consistently reproduced by running the script below:

audit-dupe-exe-deadlock.sh

#!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo

This patch fixes the issue by introducing struct auditwatchctx to pass the fsnotify event context down to auditallocmark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kernpathparent() path resol ---truncated---