// For flags

CVE-2024-50099

arm64: probes: Remove broken LDR (literal) uprobe support

Severity Score

"-"
*CVSS v-

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

-
*SSVC
Descriptions

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: sondas: Eliminar el soporte roto de uprobe LDR (literal). Las funciones simulation_ldr_literal() y simulation_ldrsw_literal() no son seguras para usar con uprobes. Ambas funciones se escribieron originalmente para usar con kprobes y acceder a la memoria con accesos C simples. Cuando se agregó uprobes, se reutilizaron sin modificar a pesar de que no pueden acceder de manera segura a la memoria del usuario. Hay tres problemas clave: 1) Los accesos C simples no tienen entradas extable correspondientes y, por lo tanto, si encuentran un fallo, el kernel los tratará como accesos no intencionales a la memoria del usuario, lo que resultará en un BUG() que matará el hilo del kernel y probablemente conducirá a más problemas (por ejemplo, bloqueo o panic()). 2) Los accesos C simples están sujetos a HW PAN y SW PAN, y por lo tanto, cuando cualquiera de ellos está en uso, cualquier intento de simular un acceso a la memoria del usuario fallará. Por lo tanto, ni simulation_ldr_literal() ni simulation_ldrsw_literal() pueden hacer nada útil al simular una instrucción de usuario en cualquier sistema con HW PAN o SW PAN. 3) Los accesos C simples son privilegiados, ya que se ejecutan en el contexto del núcleo y, en la práctica, pueden acceder a un pequeño rango de direcciones virtuales del núcleo. Las instrucciones que simulan tienen un rango de +/-1 MiB y, dado que las instrucciones simuladas deben ser instrucciones de usuario en el rango de direcciones TTBR0, estas pueden direccionar el último MiB del rango de direcciones de TTBR1 envolviendo hacia abajo desde una dirección en el primer MiB del rango de direcciones TTBR0. En los núcleos contemporáneos, los últimos 8 MiB del rango de direcciones TTBR1 están reservados y los accesos a estos siempre fallarán, lo que significa que esto no es peor que (1). Históricamente, era teóricamente posible que el mapa lineal o vmemmap se derramara en los últimos 8 MiB del rango de direcciones TTBR1, pero en la práctica esto es extremadamente improbable que ocurra ya que esto requeriría: * Tener suficiente memoria física para llenar todo el mapa lineal hasta el último 1 MiB del rango de direcciones TTBR1. * Tener mala suerte con la aleatorización KASLR del mapa lineal de modo que la región poblada se superponga con el último 1 MiB del rango de direcciones TTBR. ... y en cualquier caso, si nos desbordáramos en la página final, habría problemas más grandes ya que la página final tendría alias con punteros de error. Prácticamente hablando, (1) y (2) son los grandes problemas. Dado que no ha habido informes de problemas desde que se introdujo el código roto, parece que nadie confía en sondear estas instrucciones con uprobes. Evite estos problemas al no permitir uprobes en LDR (literal) y LDRSW (literal), y al limitar el uso de simulation_ldr_literal() y simulation_ldrsw_literal() a kprobes. Los intentos de colocar uprobes en LDR (literal) y LDRSW (literal) serán rechazados ya que arm_probe_decode_insn() devolverá INSN_REJECTED. En el futuro, podemos considerar la introducción de compatibilidad con uprobes funcionales para estas instrucciones, pero esto requerirá un trabajo más significativo.

*Credits: N/A
CVSS Scores
Attack Vector
-
Attack Complexity
-
Privileges Required
-
User Interaction
-
Scope
-
Confidentiality
-
Integrity
-
Availability
-
* Common Vulnerability Scoring System
SSVC
  • Decision:-
Exploitation
-
Automatable
-
Tech. Impact
-
* Organization's Worst-case Scenario
Timeline
  • 2024-10-21 CVE Reserved
  • 2024-11-05 CVE Published
  • 2024-11-05 CVE Updated
  • 2024-11-06 EPSS Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 4.10 < 5.10.228
Search vendor "Linux" for product "Linux Kernel" and version " >= 4.10 < 5.10.228"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 4.10 < 5.15.169
Search vendor "Linux" for product "Linux Kernel" and version " >= 4.10 < 5.15.169"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 4.10 < 6.1.114
Search vendor "Linux" for product "Linux Kernel" and version " >= 4.10 < 6.1.114"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 4.10 < 6.6.58
Search vendor "Linux" for product "Linux Kernel" and version " >= 4.10 < 6.6.58"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 4.10 < 6.11.5
Search vendor "Linux" for product "Linux Kernel" and version " >= 4.10 < 6.11.5"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 4.10 < 6.12-rc4
Search vendor "Linux" for product "Linux Kernel" and version " >= 4.10 < 6.12-rc4"
en
Affected