CVE-2024-35895

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Evitar el punto muerto de inversión de bloqueo en la eliminación del mapa elem syzkaller comenzó a usar corpus donde un programa de seguimiento BPF elimina elementos de un mapa sockmap/sockhash. Debido a que los programas de seguimiento BPF se pueden invocar desde cualquier contexto de interrupción, los bloqueos realizados durante una operación map_delete_elem deben ser seguros. De lo contrario, es posible que se produzca un punto muerto debido a la inversión del bloqueo, como lo informa lockdep: CPU0 CPU1 ---- ---- lock(&htab->buckets[i].lock); local_irq_disable(); bloquear(&host->bloquear); lock(&htab->cubos[i].lock); bloqueo(&host->bloqueo); Los bloqueos en sockmap son difíciles de inseguro por diseño. Esperamos que los elementos se eliminen de sockmap/sockhash solo en el contexto de la tarea (normal) con las interrupciones habilitadas o en el contexto de softirq. Detecta cuándo se invoca la operación map_delete_elem desde un contexto que _no_ es hardirq-inseguro, es decir, las interrupciones están deshabilitadas y sale con un error. Tenga en cuenta que las actualizaciones de mapas no se ven afectadas por este problema. El verificador de BPF no permite actualizar sockmap/sockhash desde un programa de seguimiento de BPF en la actualidad.

CVE-2024-35895 addresses a vulnerability in the Linux kernel's Berkeley Packet Filter (BPF) subsystem, specifically within the sockmap feature. The issue arises when BPF tracing programs, which can execute in various interrupt contexts, attempt to delete elements from sockmap or sockhash maps. This operation involves acquiring locks that are not safe for use in hard interrupt contexts, leading to potential deadlocks due to lock inversion. BPF tracing programs may delete elements from sockmap/sockhash maps while running in interrupt contexts where the required locks are not hardirq-safe, causing possible deadlocks. System hangs or crashes due to deadlocks when deleting elements from sockmap/sockhash maps in inappropriate contexts.

In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Prevent lock inversion deadlock in map delete elem syzkaller started using corpuses where a BPF tracing program deletes elements from a sockmap/sockhash map. Because BPF tracing programs can be invoked from any interrupt context, locks taken during a map_delete_elem operation must be hardirq-safe. Otherwise a deadlock due to lock inversion is possible, as reported by lockdep: CPU0 CPU1 ---- ---- lock(&htab->buckets[i].lock); local_irq_disable(); lock(&host->lock); lock(&htab->buckets[i].lock); <Interrupt> lock(&host->lock); Locks in sockmap are hardirq-unsafe by design. We expects elements to be deleted from sockmap/sockhash only in task (normal) context with interrupts enabled, or in softirq context. Detect when map_delete_elem operation is invoked from a context which is _not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an error. Note that map updates are not affected by this issue. BPF verifier does not allow updating sockmap/sockhash from a BPF tracing program today.

Ziming Zhang discovered that the DRM driver for VMware Virtual GPU did not properly handle certain error conditions, leading to a NULL pointer dereference. A local attacker could possibly trigger this vulnerability to cause a denial of service. It was discovered that the ATA over Ethernet driver in the Linux kernel contained a race condition, leading to a use-after-free vulnerability. An attacker could use this to cause a denial of service or possibly execute arbitrary code.