Este incidente revela una serie de race conditions y fallos en la lógica de detección de deadlocks dentro del rqspinlock (resilient queued spinlock) del kernel Linux, específicamente en el contexto de programas eBPF que interactúan con bpf_ringbuf_reserve. La causa raíz inicial fue una ventana de inconsistencia crítica: una NMI (Non-Maskable Interrupt) de sampling podía interrumpir la adquisición del spinlock después de que el lock fuera marcado como held pero antes de que se registrara en la tabla rqspinlock_held_locks del CPU. Esto impedía que la detección de deadlock AA (recursive lock) funcionara correctamente, llevando a un spinwait de 250ms y congelando el sistema.
La cascada de fallos continuó incluso después de la primera corrección. Se descubrió que la detección de deadlocks no se activaba inmediatamente al entrar en un spinwait, sino solo después de 1ms. Esto significaba que, incluso con la tabla de locks held actualizada correctamente, un deadlock AA seguiría causando un spinwait de al menos 1ms antes de ser detectado, resultando en micro-congelamientos. Finalmente, se identificó un problema más sutil: la alta frecuencia de NMIs podía impedir que el CPU que poseía el spinlock progresara y lo liberara, incluso si no había un deadlock directo, llevando a inanición y stalls más largos (6-26ms).
Las salvaguardas existentes, como la lógica de rqspinlock diseñada para ser resiliente a deadlocks, fallaron debido a la complejidad de las interacciones entre NMIs, eBPF y la implementación específica del spinlock. La suposición de que las interrupciones y la preemption estaban deshabilitadas durante la sección crítica de adquisición del lock fue violada por la naturaleza no enmascarable de las NMIs, exponiendo una race condition que no había sido anticipada en el diseño original del rqspinlock para eBPF. La falta de una detección de deadlock inmediata y la susceptibilidad a la inanición por NMIs recurrentes completaron la serie de vulnerabilidades.