CVE-2022-48922 is a vulnerability identified in the Linux kernel specifically affecting the RISC-V architecture implementation. The issue arises from improper handling of the frame pointer ($fp or $s0 register) in low-level kernel code related to irqsoff latency tracing. The functions trace_hardirqs_on() and trace_hardirqs_off() rely on the macro CALLER_ADDR1, which uses __builtin_return_address(1) to obtain caller information. This macro assumes that the frame pointer is correctly set up. However, in certain assembly entry code paths, the $fp register is repurposed and not used as a frame pointer, leading to invalid memory accesses and kernel oops (crashes) during boot when irqoff tracer is enabled. The oops manifests as a NULL pointer dereference at a low virtual address, causing a paging fault. The root cause is that the assembly code does not preserve the frame pointer convention expected by the tracing macros, resulting in attempts to dereference invalid pointers. The fix involves adding an additional wrapper layer around trace_hardirqs_on/off() functions to ensure they are safely callable from low-level entry code without causing faults. This vulnerability is specific to Linux kernel builds with irqoff latency tracing enabled on RISC-V platforms. It does not affect other architectures or configurations without this tracing enabled. No known exploits are reported in the wild, and no CVSS score has been assigned yet. The vulnerability was published on August 22, 2024, and affects certain Linux kernel versions identified by specific commit hashes.

For European organizations utilizing Linux systems on RISC-V hardware with irqoff latency tracing enabled, this vulnerability could cause system instability or boot failures due to kernel oops. This may lead to denial of service conditions, impacting availability of critical systems. While the vulnerability does not appear to allow privilege escalation or code execution directly, the resulting kernel crashes could disrupt operations, especially in embedded or industrial environments where RISC-V Linux is deployed. Since the issue occurs during boot or low-level kernel operations, affected systems may fail to start or recover without manual intervention, increasing operational risk. The impact is limited to systems compiled with irqoff tracer enabled, which is not common in typical enterprise Linux distributions but may be present in specialized or development builds. European organizations relying on RISC-V Linux for IoT, edge computing, or research platforms should be aware of potential service interruptions. The lack of known exploits reduces immediate threat, but unpatched systems remain vulnerable to accidental crashes or targeted disruption by attackers with kernel-level access.

Organizations should verify if their Linux kernel builds on RISC-V platforms have irqoff latency tracing enabled. If so, they should promptly apply the patch that introduces the wrapper functions around trace_hardirqs_on/off() to prevent invalid memory accesses. Kernel upgrades to versions including this fix are recommended. For environments where irqoff tracing is not required, disabling this feature can mitigate the risk. Additionally, thorough testing of kernel updates in staging environments is advised to ensure stability. Monitoring kernel logs for oops messages related to trace_hardirqs_on/off can help detect attempts to trigger this fault. For embedded or specialized RISC-V Linux deployments, vendors should provide updated kernel images incorporating the fix. Implementing robust boot recovery mechanisms can reduce downtime caused by kernel crashes. Finally, limiting kernel debugging or tracing features in production systems unless necessary reduces attack surface and exposure to such vulnerabilities.