// For flags

CVE-2024-35917

s390/bpf: Fix bpf_plt pointer arithmetic

Severity Score

"-"
*CVSS v-

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

In the Linux kernel, the following vulnerability has been resolved:

s390/bpf: Fix bpf_plt pointer arithmetic

Kui-Feng Lee reported a crash on s390x triggered by the
dummy_st_ops/dummy_init_ptr_arg test [1]:

[<0000000000000002>] 0x2
[<00000000009d5cde>] bpf_struct_ops_test_run+0x156/0x250
[<000000000033145a>] __sys_bpf+0xa1a/0xd00
[<00000000003319dc>] __s390x_sys_bpf+0x44/0x50
[<0000000000c4382c>] __do_syscall+0x244/0x300
[<0000000000c59a40>] system_call+0x70/0x98

This is caused by GCC moving memcpy() after assignments in
bpf_jit_plt(), resulting in NULL pointers being written instead of
the return and the target addresses.

Looking at the GCC internals, the reordering is allowed because the
alias analysis thinks that the memcpy() destination and the assignments'
left-hand-sides are based on different objects: new_plt and
bpf_plt_ret/bpf_plt_target respectively, and therefore they cannot
alias.

This is in turn due to a violation of the C standard:

When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object
...

From the C's perspective, bpf_plt_ret and bpf_plt are distinct objects
and cannot be subtracted. In the practical terms, doing so confuses the
GCC's alias analysis.

The code was written this way in order to let the C side know a few
offsets defined in the assembly. While nice, this is by no means
necessary. Fix the noncompliance by hardcoding these offsets.

[1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/bpf: Corrección de la aritmética del puntero bpf_plt Kui-Feng Lee informó un bloqueo en s390x provocado por la prueba dummy_st_ops/dummy_init_ptr_arg [1]: [&lt;00000000000000002&gt;] 0x2 [&lt;00000000009d5cde&gt; ] bpf_struct_ops_test_run+0x156/0x250 [&lt;000000000033145a&gt;] __sys_bpf+0xa1a/0xd00 [&lt;00000000003319dc&gt;] __s390x_sys_bpf+0x44/0x50 [&lt;0000000000 c4382c&gt;] __do_syscall+0x244/0x300 [&lt;0000000000c59a40&gt;] system_call+0x70/0x98 Esto es causado por GCC mueve memcpy() después de las asignaciones en bpf_jit_plt(), lo que da como resultado que se escriban punteros NULL en lugar de las direcciones de retorno y de destino. Al observar los aspectos internos de GCC, se permite el reordenamiento porque el análisis de alias piensa que el destino memcpy() y los lados izquierdos de las asignaciones se basan en objetos diferentes: new_plt y bpf_plt_ret/bpf_plt_target respectivamente y, por lo tanto, no pueden crear alias. Esto, a su vez, se debe a una violación del estándar C: cuando se restan dos punteros, ambos apuntarán a elementos del mismo objeto de matriz, o uno más allá del último elemento del objeto de matriz... Desde la perspectiva de C, bpf_plt_ret y bpf_plt son objetos distintos y no se pueden restar. En términos prácticos, hacerlo confunde el análisis de alias del CCG. El código se escribió de esta manera para que el lado C conozca algunas compensaciones definidas en el ensamblaje. Si bien es agradable, esto no es necesario. Corrija el incumplimiento codificando estas compensaciones. [1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/

*Credits: N/A
CVSS Scores
Attack Vector
-
Attack Complexity
-
Privileges Required
-
User Interaction
-
Scope
-
Confidentiality
-
Integrity
-
Availability
-
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-05-17 CVE Reserved
  • 2024-05-19 CVE Published
  • 2024-05-20 EPSS Updated
  • 2024-08-02 CVE 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"
>= 6.3 < 6.6.26
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.3 < 6.6.26"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.3 < 6.8.5
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.3 < 6.8.5"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 6.3 < 6.9
Search vendor "Linux" for product "Linux Kernel" and version " >= 6.3 < 6.9"
en
Affected