CVE-2022-50648 in Linux
Summary
by MITRE • 12/09/2025
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix recursive locking direct_mutex in ftrace_modify_direct_caller
Naveen reported recursive locking of direct_mutex with sample ftrace-direct-modify.ko:
[ 74.762406] WARNING: possible recursive locking detected
[ 74.762887] 6.0.0-rc6+ #33 Not tainted
[ 74.763216] --------------------------------------------
[ 74.763672] event-sample-fn/1084 is trying to acquire lock:
[ 74.764152] ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \
register_ftrace_function+0x1f/0x180 [ 74.764922]
[ 74.764922] but task is already holding lock:
[ 74.765421] ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \
modify_ftrace_direct+0x34/0x1f0 [ 74.766142]
[ 74.766142] other info that might help us debug this:
[ 74.766701] Possible unsafe locking scenario:
[ 74.766701]
[ 74.767216] CPU0
[ 74.767437] ----
[ 74.767656] lock(direct_mutex);
[ 74.767952] lock(direct_mutex);
[ 74.768245]
[ 74.768245] *** DEADLOCK ***
[ 74.768245]
[ 74.768750] May be due to missing lock nesting notation
[ 74.768750]
[ 74.769332] 1 lock held by event-sample-fn/1084:
[ 74.769731] #0: ffffffff86c9d6b0 (direct_mutex){+.+.}-{3:3}, at: \
modify_ftrace_direct+0x34/0x1f0 [ 74.770496]
[ 74.770496] stack backtrace:
[ 74.770884] CPU: 4 PID: 1084 Comm: event-sample-fn Not tainted ...
[ 74.771498] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...
[ 74.772474] Call Trace:
[ 74.772696] <TASK>
[ 74.772896] dump_stack_lvl+0x44/0x5b
[ 74.773223] __lock_acquire.cold.74+0xac/0x2b7
[ 74.773616] lock_acquire+0xd2/0x310
[ 74.773936] ? register_ftrace_function+0x1f/0x180
[ 74.774357] ? lock_is_held_type+0xd8/0x130
[ 74.774744] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]
[ 74.775213] __mutex_lock+0x99/0x1010
[ 74.775536] ? register_ftrace_function+0x1f/0x180
[ 74.775954] ? slab_free_freelist_hook.isra.43+0x115/0x160
[ 74.776424] ? ftrace_set_hash+0x195/0x220
[ 74.776779] ? register_ftrace_function+0x1f/0x180
[ 74.777194] ? kfree+0x3e1/0x440
[ 74.777482] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]
[ 74.777941] ? __schedule+0xb40/0xb40
[ 74.778258] ? register_ftrace_function+0x1f/0x180
[ 74.778672] ? my_tramp1+0xf/0xf [ftrace_direct_modify]
[ 74.779128] register_ftrace_function+0x1f/0x180
[ 74.779527] ? ftrace_set_filter_ip+0x33/0x70
[ 74.779910] ? __schedule+0xb40/0xb40
[ 74.780231] ? my_tramp1+0xf/0xf [ftrace_direct_modify]
[ 74.780678] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]
[ 74.781147] ftrace_modify_direct_caller+0x5b/0x90
[ 74.781563] ? 0xffffffffa0201000
[ 74.781859] ? my_tramp1+0xf/0xf [ftrace_direct_modify]
[ 74.782309] modify_ftrace_direct+0x1b2/0x1f0
[ 74.782690] ? __schedule+0xb40/0xb40
[ 74.783014] ? simple_thread+0x2a/0xb0 [ftrace_direct_modify]
[ 74.783508] ? __schedule+0xb40/0xb40
[ 74.783832] ? my_tramp2+0x11/0x11 [ftrace_direct_modify]
[ 74.784294] simple_thread+0x76/0xb0 [ftrace_direct_modify]
[ 74.784766] kthread+0xf5/0x120
[ 74.785052] ? kthread_complete_and_exit+0x20/0x20
[ 74.785464] ret_from_fork+0x22/0x30
[ 74.785781] </TASK>
Fix this by using register_ftrace_function_nolock in ftrace_modify_direct_caller.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/28/2026
The vulnerability CVE-2022-50648 resides within the Linux kernel's ftrace subsystem, specifically in the handling of direct function tracing modifications. This issue manifests as a recursive locking condition involving the direct_mutex lock, which is a critical synchronization primitive used to protect the ftrace infrastructure. The problem occurs when the ftrace_modify_direct_caller function attempts to acquire a lock that is already held by the same execution context, leading to a potential deadlock scenario that can compromise system stability.
The technical flaw stems from improper lock handling within the ftrace subsystem where the function register_ftrace_function is invoked recursively without proper nesting annotations. The stack trace reveals that a thread named event-sample-fn/1084 attempts to acquire the direct_mutex lock while already holding it, creating a classic deadlock condition. This recursive locking scenario is particularly dangerous because it can occur during dynamic tracing operations where the kernel is modifying function call paths in real-time. The lock tracking mechanism in the kernel's locking subsystem detects this condition and generates a warning message indicating the potential deadlock.
The operational impact of this vulnerability extends beyond simple system instability to potentially enable denial-of-service conditions within the kernel. When the recursive lock detection triggers, the system may either hang indefinitely or crash, depending on the kernel's response to the locking violation. This is particularly concerning in production environments where kernel tracing is actively used for debugging, performance monitoring, or security analysis. The vulnerability affects systems using the ftrace framework, especially those with active tracing modules like ftrace_direct_modify.ko, which are commonly employed in kernel debugging and performance analysis scenarios. The issue is exacerbated by the fact that ftrace is widely used across various kernel subsystems and security tools that rely on dynamic function tracing capabilities.
The fix implemented addresses this by modifying the ftrace_modify_direct_caller function to utilize register_ftrace_function_nolock instead of the standard register_ftrace_function. This change eliminates the recursive locking scenario by avoiding the acquisition of locks that are already held by the calling context. This approach aligns with established best practices for kernel lock management and prevents the deadlock condition from occurring. The solution represents a targeted fix that preserves the intended functionality of the ftrace subsystem while eliminating the race condition that leads to the recursive locking issue. This vulnerability demonstrates the complexity of kernel-level synchronization and highlights the importance of careful lock management in high-performance systems, particularly those involving dynamic code modification and tracing capabilities.
This vulnerability maps to CWE-367, which describes the "Time-of-Check Time-of-Use (TOCTOU) vulnerability" in kernel contexts, though the specific nature here involves recursive locking rather than TOCTOU. The fix aligns with ATT&CK technique T1566.001, which involves the exploitation of kernel vulnerabilities to gain system-level access, though in this case the fix prevents such exploitation rather than enabling it. The vulnerability also reflects broader concerns in kernel security related to lock management and concurrency control, which are fundamental to maintaining system integrity and preventing privilege escalation through kernel-level flaws.