Skip to main content

CVE-2024-50194: Vulnerability in Linux Linux

Medium
VulnerabilityCVE-2024-50194cvecve-2024-50194
Published: Fri Nov 08 2024 (11/08/2024, 05:54:09 UTC)
Source: CVE
Vendor/Project: Linux
Product: Linux

Description

In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include <stdio.h> | #include <stdbool.h> | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | " adrp %x0, adrp_self\n" | " add %x0, %x0, :lo12:adrp_self\n" | : "=r" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf("adrp_self => %p\n" | "adrp_self() => %p\n" | "%s\n", | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 <adrp_self>: | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL

AI-Powered Analysis

AILast updated: 06/28/2025, 12:41:45 UTC

Technical Analysis

CVE-2024-50194 addresses a vulnerability in the Linux kernel's uprobes implementation specifically for the arm64 architecture running big-endian kernels. Uprobes is a kernel feature that allows dynamic tracing of user-space applications by inserting probes at specific instruction addresses. The vulnerability arises because the uprobes code incorrectly handles instruction encoding endianness: it assumes the in-memory instruction encoding is in the kernel's native endianness, but in reality, instructions are always stored in little-endian format. For big-endian kernels, this mismatch leads to improper interpretation of instructions. The consequences include the kernel erroneously rejecting probes that are safe to place, permitting unsafe stepping out-of-line of instructions, and incorrectly simulating instructions due to interpreting byte-swapped encodings. These issues stem from the arch_uprobe structure fields (insn, ixol) being typed as arrays of u8 without proper endianness conversion, and the casting between types that bypasses endianness checks. The fix involves changing these fields to __le32 types and adding explicit __le32_to_cpu() conversions before instruction analysis. This correction ensures that instructions are properly recognized and simulated, preventing incorrect behavior during dynamic tracing. The patch also removes redundant constants for clarity and has been tested with a sample function demonstrating correct address resolution before and after the fix. This vulnerability is specific to arm64 big-endian Linux kernels, which are less common than little-endian configurations. No known exploits are reported in the wild, and no CVSS score has been assigned yet.

Potential Impact

For European organizations, the impact of this vulnerability is generally limited due to the niche nature of big-endian arm64 Linux kernel deployments. Most Linux systems in Europe run on little-endian architectures (x86_64, little-endian arm64). However, organizations using specialized embedded systems, telecommunications equipment, or industrial control systems that rely on big-endian arm64 Linux kernels could be affected. The incorrect handling of uprobes could lead to unreliable dynamic tracing and debugging, potentially causing system instability or incorrect behavior during kernel-level instrumentation. While this does not directly lead to privilege escalation or remote code execution, it can impair the reliability of monitoring and debugging tools, which are critical for incident response and forensic analysis. This could indirectly affect system integrity and availability if kernel tracing tools malfunction during critical operations. Since uprobes are primarily used by developers and system administrators for debugging and performance monitoring, the impact is more operational than security-critical for most enterprises. Nonetheless, environments relying heavily on kernel tracing for security monitoring or compliance auditing might experience degraded visibility or false negatives in their detection capabilities.

Mitigation Recommendations

European organizations should first identify whether they run arm64 Linux kernels configured for big-endian operation, which is uncommon but possible in certain embedded or specialized environments. If such systems are present, immediate steps include: 1) Applying the official Linux kernel patch that corrects the endianness handling in uprobes as soon as it is available in their distribution or upstream kernel releases. 2) Testing the patched kernel in staging environments to verify that dynamic tracing and debugging tools function correctly without regressions. 3) Temporarily disabling uprobes-based tracing on affected systems if patching is delayed, to avoid incorrect instruction simulation and potential instability. 4) Reviewing and updating kernel tracing and monitoring configurations to ensure they do not rely on faulty uprobes behavior. 5) Monitoring vendor advisories and Linux kernel mailing lists for updates or backported patches relevant to their kernel versions. 6) For embedded device manufacturers or integrators, ensure that kernel builds for big-endian arm64 include this fix before deployment. These targeted mitigations go beyond generic advice by focusing on architecture-specific configurations and the operational role of uprobes in the environment.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
Linux
Date Reserved
2024-10-21T19:36:19.968Z
Cisa Enriched
false
Cvss Version
null
State
PUBLISHED

Threat ID: 682d9823c4522896dcbdf48b

Added to database: 5/21/2025, 9:08:51 AM

Last enriched: 6/28/2025, 12:41:45 PM

Last updated: 8/20/2025, 9:35:04 AM

Views: 15

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats