GHSA-MPG4-CV8Q-2GFG
Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-14 00:31In the Linux kernel, the following vulnerability has been resolved:
audit: fix recursive locking deadlock in audit_dupe_exe()
A deadlock occurs in the audit subsystem when duplicating executable-related rules.
When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock:
============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted
mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0
but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1);
*** DEADLOCK ***
May be due to missing lock nesting notation
6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0
stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+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 ORIG_RAX: 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
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 audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-68096"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T13:19:53Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\naudit: fix recursive locking deadlock in audit_dupe_exe()\n\nA deadlock occurs in the audit subsystem when duplicating\nexecutable-related rules.\n\nWhen 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:\n\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 (\u0026inode-\u003ei_sb-\u003es_type-\u003ei_mutex_dir_key/1){+.+.}-{3:3},\n at: __kern_path_locked+0x10a/0x2f0\n\n but task is already holding lock:\n ffff888132846b58 (\u0026inode-\u003ei_sb-\u003es_type-\u003ei_mutex_dir_key/1){+.+.}-{3:3},\n at: lock_two_directories+0x13f/0x2b0\n\n other info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026inode-\u003ei_sb-\u003es_type-\u003ei_mutex_dir_key/1);\n lock(\u0026inode-\u003ei_sb-\u003es_type-\u003ei_mutex_dir_key/1);\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n 6 locks held by mv/5099:\n #0: ffff888112a9c440 (sb_writers#13)\n at: do_renameat2+0x34c/0xbc0\n #1: ffff888112a9c790 (\u0026type-\u003es_vfs_rename_key#3)\n at: do_renameat2+0x415/0xbc0\n #2: ffff888132846b58 (\u0026inode-\u003ei_sb-\u003es_type-\u003ei_mutex_dir_key/1)\n at: lock_two_directories+0x13f/0x2b0\n #3: ffff888132845358 (\u0026inode-\u003ei_sb-\u003es_type-\u003ei_mutex_dir_key/5)\n at: lock_two_directories+0x175/0x2b0\n #4: ffffffffb3a1fb10 (\u0026fsnotify_mark_srcu)\n at: fsnotify+0x454/0x28a0\n #5: ffffffffaf886230 (audit_filter_mutex)\n at: audit_update_watch+0x36/0x11e0\n\n stack backtrace:\n Call Trace:\n \u003cTASK\u003e\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 \u003c48\u003e\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\n \u003c/TASK\u003e\n\nThe aforementioned deadlock can be consistently reproduced by running\nthe script below:\n\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\n\nThis 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---",
"id": "GHSA-mpg4-cv8q-2gfg",
"modified": "2026-08-14T00:31:51Z",
"published": "2026-08-10T15:33:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68096"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36eb77f14b4e6f2dc1008c1fabe31236397be27a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3b601938314c24fcd1afb6659cad92fe96c9c2f8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/40879c39d6740f3dddfb52b5d6ba7fb8cceb84d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7d1f66c69898ffb1a718926c32a777ecc471caca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/81905b5acbe77284734438df3fbec1158e6429a3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.