Google: sys-kernel/lakitu-kernel-6_1: security update to 18244.236.88

medium Tenable Self-Hosted Container Security Plugin ID 450950

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

- 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 (CVE-2024-50194)

Solution

Update the sys-kernel/lakitu-kernel-6_1 library and its related packages to version 18244.236.88 or later.

Plugin Details

Severity: Medium

ID: 450950

Version: Revision 1.1

Type: Local

Family: Google COS Security Checks

Published: 10/1/2026

Updated: 10/1/2026

Risk Information

VPR

Risk Factor: Low

Score: 3

Percentile: 23.18

Vendor

Vendor Severity: MEDIUM

CVSS v2

Risk Factor: Medium

Base Score: 4.6

Temporal Score: 3.4

Vector: CVSS2#AV:L/AC:L/Au:S/C:N/I:N/A:C

CVSS Score Source: CVE-2024-50194

CVSS v3

Risk Factor: Medium

Base Score: 5.5

Temporal Score: 4.8

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Vulnerability Publication Date: 11/8/2024

Reference Information

CVE: CVE-2024-50194

Detections

Analytics