Google: sys-kernel/lakitu-kernel-5_15, sys-kernel/lakitu-kernel-6_1: security update to 17800.372.64

medium Tenable Cloud Security Plugin ID 452060

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: Remove broken LDR
(literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to
use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain
C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access
user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable
entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user
memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g.
lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in
use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor
simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW
PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can
access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB,
and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these
can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first
1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved,
and accesses to this will always fault, meaning this is no worse than (1). Historically, it was
theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address
range, but in practice this is extremely unlikely to occur as this would require either: * Having enough
physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. *
Getting unlucky with KASLR randomization of the linear map such that the populated region happens to
overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the
final page there would be larger problems as the final page would alias with error pointers. Practically
speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken
code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid
these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of
simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal)
and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we
can consider introducing working uprobes support for these instructions, but this will require more
significant work. (CVE-2024-50099)

Solution

Update the sys-kernel/lakitu-kernel-5_15 library and its related packages to version 17800.372.64 or later.

Plugin Details

Severity: Medium

ID: 452060

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-50099

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/5/2024

Reference Information

CVE: CVE-2024-50099

Detections

Analytics