CVE-2022-50648
BaseFortify
Publication date: 2025-12-09
Last updated on: 2025-12-09
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | 6.0.0-rc6 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a recursive locking issue in the Linux kernel's ftrace subsystem. Specifically, the direct_mutex lock is acquired recursively in the function ftrace_modify_direct_caller, which can lead to a deadlock situation. This happens because the code tries to acquire a lock that it already holds, causing the system to hang or crash. The fix involved changing the locking mechanism to use register_ftrace_function_nolock to avoid this recursive locking.
How can this vulnerability impact me? :
This vulnerability can cause a deadlock in the Linux kernel, potentially leading to system hangs or crashes. This can disrupt normal system operations, cause denial of service, and affect the stability and reliability of systems running vulnerable kernel versions.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring the system logs for warnings about recursive locking of direct_mutex related to ftrace. Specifically, look for messages similar to: "WARNING: possible recursive locking detected" and stack traces involving ftrace_modify_direct_caller and direct_mutex. You can use the command 'dmesg | grep -i "recursive locking"' or 'journalctl -k | grep -i "recursive locking"' to find such warnings in kernel logs.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation is to update the Linux kernel to a version that includes the fix for this vulnerability, which involves using register_ftrace_function_nolock in ftrace_modify_direct_caller instead of the vulnerable code. Until the kernel is updated, monitoring for the recursive locking warnings and avoiding use of the affected ftrace-direct-modify module may help reduce risk.