CVE-2022-49721 is a vulnerability in the Linux kernel specifically affecting the arm64 architecture's ftrace subsystem, which is used for function tracing and debugging. The issue arises from inconsistent handling of Procedure Linkage Table (PLT) entries when modifying function call sites via ftrace. The vulnerability is rooted in the ftrace_modify_call() function, which unlike ftrace_make_call() and ftrace_make_nop(), does not correctly handle cases where a PLT entry is required for a trampoline call. This leads to two problematic scenarios: (a) when the old address requires a trampoline, ftrace_modify_call() attempts to generate a branch instruction with an out-of-range address, causing warnings and internal ftrace errors without modifying instructions, and (b) when the new address requires a trampoline but the old does not, the function generates an out-of-range branch instruction replaced by a BRK (breakpoint) instruction, which triggers a kernel panic upon execution. The more common scenario is (a), which results in internal ftrace errors that may not immediately affect system stability, but scenario (b) can cause a kernel panic, leading to a denial of service. The vulnerability can be triggered by loading a specially crafted kernel module that invokes ftrace_modify_call() improperly, as demonstrated by a test module example. The root cause is a logic inconsistency introduced in commit 3b23e4991fb66f6d, where ftrace_modify_call() was introduced without proper PLT handling. The fix involves consistently determining when to use a PLT entry for an address to avoid out-of-range branch instructions and subsequent kernel panics. This vulnerability affects Linux kernel versions containing the faulty commit and impacts systems running on arm64 architecture that utilize ftrace for tracing and debugging.

For European organizations, the impact of CVE-2022-49721 depends largely on their deployment of Linux systems running on arm64 architecture, which is increasingly common in servers, embedded devices, and IoT infrastructure. The vulnerability can cause kernel panics leading to denial of service, potentially disrupting critical services and operations. Systems relying on ftrace for performance monitoring, debugging, or security auditing could experience instability or crashes if exploited. Although exploitation requires loading a kernel module, which typically demands root privileges, the vulnerability could be leveraged by attackers who have already gained elevated access to cause system outages or interfere with kernel tracing mechanisms. This could affect cloud service providers, telecom infrastructure, industrial control systems, and other sectors using arm64 Linux servers or devices. The denial of service could lead to downtime, loss of availability, and operational disruption. Additionally, internal ftrace errors might complicate debugging and monitoring efforts, impacting incident response and system maintenance. Since no known exploits are reported in the wild, the immediate risk is moderate but should be addressed proactively to prevent potential exploitation in targeted attacks or insider threat scenarios.

1. Apply the official Linux kernel patches that address CVE-2022-49721 as soon as they become available from trusted sources or Linux distributions. 2. Restrict the ability to load kernel modules to trusted administrators only, enforcing strict access controls and auditing module loading activities. 3. Employ kernel lockdown features where possible to prevent unauthorized kernel modifications. 4. Monitor system logs for ftrace-related warnings or errors that could indicate attempts to trigger the vulnerability. 5. For environments using custom or out-of-tree kernel modules, review and test these modules for compatibility with the patched kernel and ensure they do not invoke ftrace_modify_call() in a way that could trigger the bug. 6. Consider disabling ftrace functionality on arm64 systems if not required, to reduce the attack surface. 7. Maintain robust incident response plans to quickly address kernel panics or system crashes potentially related to this vulnerability. 8. Use security tools that can detect anomalous kernel module loading or unusual kernel behavior indicative of exploitation attempts.