CVE-2024-56786

  1. OpenCVE
  2. Vulnerabilities (CVE)
  3. CVE-2024-56786
In the Linux kernel, the following vulnerability has been resolved: bpf: put bpf_link's program when link is safe to be deallocated In general, BPF link's underlying BPF program should be considered to be reachable through attach hook -> link -> prog chain, and, pessimistically, we have to assume that as long as link's memory is not safe to free, attach hook's code might hold a pointer to BPF program and use it. As such, it's not (generally) correct to put link's program early before waiting for RCU GPs to go through. More eager bpf_prog_put() that we currently do is mostly correct due to BPF program's release code doing similar RCU GP waiting, but as will be shown in the following patches, BPF program can be non-sleepable (and, thus, reliant on only "classic" RCU GP), while BPF link's attach hook can have sleepable semantics and needs to be protected by RCU Tasks Trace, and for such cases BPF link has to go through RCU Tasks Trace + "classic" RCU GPs before being deallocated. And so, if we put BPF program early, we might free BPF program before we free BPF link, leading to use-after-free situation. So, this patch defers bpf_prog_put() until we are ready to perform bpf_link's deallocation. At worst, this delays BPF program freeing by one extra RCU GP, but that seems completely acceptable. Alternatively, we'd need more elaborate ways to determine BPF hook, BPF link, and BPF program lifetimes, and how they relate to each other, which seems like an unnecessary complication. Note, for most BPF links we still will perform eager bpf_prog_put() and link dealloc, so for those BPF links there are no observable changes whatsoever. Only BPF links that use deferred dealloc might notice slightly delayed freeing of BPF programs. Also, to reduce code and logic duplication, extract program put + link dealloc logic into bpf_link_dealloc() helper.

5.5 /10

CVSS v3 : MEDIUM

V3 Legend

Vector :

Exploitability : 1.8 / Impact : 3.6

Attack Vector LOCAL

Attack Complexity LOW

Privileges Required LOW

User Interaction NONE

Confidentiality Impact NONE

Integrity Impact NONE

Availability Impact HIGH

Scope UNCHANGED

References
Link Resource
https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885 Patch
https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b Patch
https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f Patch
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
History

11 Feb 2025, 16:15

Type Values Removed Values Added
CWE CWE-416

10 Jan 2025, 18:53

Type Values Removed Values Added
First Time Linux linux Kernel
Linux
CPE cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
CVSS v2 : unknown
v3 : unknown 		v2 : unknown
v3 : 5.5
CWE NVD-CWE-noinfo
References () https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885 - () https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885 - Patch
References () https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b - () https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b - Patch
References () https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f - () https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f - Patch
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: poner el programa de bpf_link cuando es seguro desasignarlo En general, se debe considerar que el programa BPF subyacente del enlace BPF es accesible a través de la cadena de gancho de conexión -> enlace -> programa y, de manera pesimista, tenemos que asumir que mientras no sea seguro liberar la memoria del enlace, el código del gancho de conexión podría contener un puntero al programa BPF y usarlo. Como tal, no es (generalmente) correcto poner el programa del enlace antes de esperar a que pasen los GP de RCU. El bpf_prog_put() más ansioso que hacemos actualmente es mayormente correcto debido a que el código de lanzamiento del programa BPF hace una espera similar de GP RCU, pero como se mostrará en los parches siguientes, el programa BPF puede no ser inactivo (y, por lo tanto, depender solo del GP RCU "clásico"), mientras que el gancho de conexión del enlace BPF puede tener semántica inactiva y necesita estar protegido por el Seguimiento de tareas RCU, y para tales casos el enlace BPF tiene que pasar por el Seguimiento de tareas RCU + GP RCU "clásicos" antes de ser desasignado. Y entonces, si ponemos el programa BPF temprano, podríamos liberar el programa BPF antes de liberar el enlace BPF, lo que lleva a una situación de use-after-free. Entonces, este parche pospone bpf_prog_put() hasta que estemos listos para realizar la desasignación de bpf_link. En el peor de los casos, esto retrasa la liberación del programa BPF por un GP RCU adicional, pero eso parece completamente aceptable. Alternativamente, necesitaríamos formas más elaboradas de determinar el gancho BPF, el enlace BPF y la duración del programa BPF, y cómo se relacionan entre sí, lo que parece una complicación innecesaria. Tenga en cuenta que, para la mayoría de los enlaces BPF, seguiremos ejecutando bpf_prog_put() y link dealloc con avidez, por lo que para esos enlaces BPF no hay cambios observables en absoluto. Solo los enlaces BPF que usan dealloc diferido pueden notar una liberación ligeramente retrasada de los programas BPF. Además, para reducir la duplicación de código y lógica, extraiga la lógica de put del programa + link dealloc en el asistente bpf_link_dealloc().

08 Jan 2025, 18:15

Type Values Removed Values Added
New CVE
Information

Published : 2025-01-08 18:15

Updated : 2025-02-11 16:15

NVD link : CVE-2024-56786

Mitre link : CVE-2024-56786

CVE.ORG link : CVE-2024-56786

JSON object : View

Products Affected

linux

  • linux_kernel
CWE
NVD-CWE-noinfo CWE-416

Use After Free