CVE-2024-56786

19 Jun 2025, 13:15

Type	Values Removed	Values Added
References	{'url': 'https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885', 'tags': ['Patch'], 'source': '416baaa9-dc9f-4396-8d5f-8c081fb06d67'} {'url': 'https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b', 'tags': ['Patch'], 'source': '416baaa9-dc9f-4396-8d5f-8c081fb06d67'} {'url': 'https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f', 'tags': ['Patch'], 'source': '416baaa9-dc9f-4396-8d5f-8c081fb06d67'}
CVSS	v2 : unknown v3 : 5.5	v2 : unknown v3 : unknown
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().
Summary	(en) 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.	(en) Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CPE	cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
CWE	NVD-CWE-noinfo CWE-416

---

11 Feb 2025, 16:15

Type	Values Removed	Values Added
CWE		CWE-416

---

10 Jan 2025, 18:53

Type	Values Removed	Values Added
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
CVSS	v2 : unknown v3 : unknown	v2 : unknown v3 : 5.5
CPE		cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
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().
CWE		NVD-CWE-noinfo
First Time		Linux Linux linux Kernel

---

08 Jan 2025, 18:15

Type	Values Removed	Values Added
New CVE

---