CVE-2026-68096

What it actually does

This is a Linux kernel audit subsystem denial-of-service flaw caused by recursive directory locking during audit watch duplication. When a file rename or move operation triggers an fsnotify move event, an executable-related audit rule can cause audit_dupe_exe() to duplicate the rule and call audit_alloc_mark(), which attempts to resolve the parent path with kern_path_parent() while the VFS rename path already holds the parent directory inode mutex. The same task can then attempt to reacquire the same I_MUTEX_PARENT-style directory lock, producing a recursive locking deadlock. The practical impact is local kernel-level deadlock of the task performing the operation, with potential audit, filesystem, or workload disruption depending on where the affected lock is held and how the system responds.

Why it matters to the business

Systems that rely on Linux audit rules for executable or path monitoring may experience hangs or service disruption when watched files are moved or renamed. The most likely consequence is local denial of service rather than data theft or privilege escalation. Because exploitation generally requires either administrative ability to configure audit rules or the presence of vulnerable audit rules already configured, the business risk is highest on servers with complex audit policies, compliance monitoring, endpoint detection tooling, or automated file movement workflows. No known exploitation or CISA KEV listing is currently indicated, and no public exploit maturity was provided, but kernel availability issues can still affect production reliability.

How an attack unfolds

An attacker or administrator-level user first ensures the Linux audit subsystem has an executable/path audit rule referencing a specific file. The actor then performs a rename or move operation on that file. During the VFS rename path, the kernel locks the relevant parent directory or directories and emits an fsnotify move event. The audit subsystem processes the event, determines that an existing executable audit rule matches the moved file, and attempts to duplicate/update the audit watch. In the vulnerable path, audit_alloc_mark() resolves the parent directory again instead of reusing the already-resolved fsnotify context, causing the task to attempt to acquire a directory inode mutex it already holds. This results in a recursive locking deadlock, potentially hanging the operation and affecting kernel audit/filesystem processing on the host.

How to fix it

Apply a vendor kernel update that includes the audit subsystem fix for recursive locking in audit_dupe_exe()/audit_alloc_mark(). The corrected implementation passes fsnotify event context through audit watch handling so the already-resolved directory inode can be reused instead of calling kern_path_parent() while rename locks are held. No exact affected package list or fixed kernel versions were provided in the input, so administrators should consult their Linux distribution, appliance, or cloud image vendor advisories for the first fixed kernel build. Until patched, reduce exposure by reviewing audit rules that combine executable and path filters for movable files, avoiding audit rules that target files frequently moved or renamed, limiting CAP_AUDIT_CONTROL/root access, and scheduling risky audit policy changes during maintenance windows. Mitigations should not replace patching because the defect is in kernel locking behavior.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version is at or above the fixed build supplied by the relevant Linux distribution or kernel vendor, not merely that the package is installed on disk. Review changelogs or advisory text for references to fixing recursive locking deadlock in audit_dupe_exe(), audit_alloc_mark(), or Linux audit watch handling. On non-production test systems only, validation can include reproducing the known trigger pattern: create an audit rule with exe and path filters for a test file, move that file into another directory, and confirm the operation completes without kernel lockdep warnings, hung tasks, or audit subsystem stalls. Also verify that auditd remains running, audit rules remain intact, and system logs do not contain recursive locking or hung task reports after the test.

Typical attack path

1. Obtain local access with sufficient privileges to configure audit rules, or identify a system where matching executable/path audit rules already exist.
2. Create or identify a file referenced by an audit rule using executable and path filters.
3. Move or rename the watched file into another directory using rename, renameat, renameat2, mv, or equivalent filesystem operations.
4. Trigger the fsnotify move event while the VFS layer holds parent directory locks.
5. Cause the audit subsystem to duplicate/update the executable-related watch and attempt recursive path resolution.
6. Induce a kernel deadlock that hangs the triggering task and may degrade host availability.

How to detect it

Look for signs of attempted or accidental triggering in kernel logs, audit logs, and command history. Relevant log sources include dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, journald kernel messages, auditd logs, shell history for privileged users, and configuration management records that modify audit rules. Search for kernel lockdep warnings, recursive locking messages, hung task reports, and stack traces containing audit_dupe_exe(), audit_alloc_mark(), audit_update_watch(), audit_watch_handle_event(), fsnotify_move(), vfs_rename(), do_renameat2(), or kern_path_parent(). In audit configuration, look for rules using both -F exe= and -F path= against files that are later moved or renamed. Because this issue is a denial-of-service condition rather than a typical compromise primitive, indicators may reflect instability or misuse rather than confirmed malicious activity. Correlate any matching kernel messages with privileged auditctl/augenrules activity and file move or rename events around the same time.

• WARNING: possible recursive locking detected
• *** DEADLOCK ***
• audit_dupe_exe
• audit_alloc_mark
• audit_update_watch
• audit_watch_handle_event
• kern_path_parent
• __kern_path_locked
• fsnotify_move
• vfs_rename
• do_renameat2
• I_MUTEX_PARENT
• inode->i_sb->s_type->i_mutex_dir_key
• audit_filter_mutex
• fsnotify_mark_srcu
• auditctl -a always,exit -F exe=
• -F path=
• auditctl -D
• renameat2
• __x64_sys_renameat
• hung task
• blocked for more than

What your security team should do

• Prioritize kernel updates on systems with Linux audit enabled, strict compliance audit policies, EDR audit integrations, or workloads that frequently move/rename monitored files.
• Inventory Linux hosts using audit rules with exe= and path= filters, especially rules targeting files under writable or frequently modified directories.
• Restrict the ability to create or modify audit rules to trusted administrators and monitor use of auditctl or augenrules for unexpected changes.
• Before patching, avoid monitoring highly volatile files with combined executable/path audit filters where operationally feasible.
• Monitor kernel logs for recursive locking, audit_dupe_exe(), audit_alloc_mark(), kern_path_parent(), and hung task messages.
• If symptoms appear, preserve kernel logs and audit configuration, then consider rebooting affected hosts only after collecting forensic and operational evidence.
• Track vendor advisories for exact fixed kernel package versions and ensure systems boot into the patched kernel after installation.