Vulnerabilidad en Linux (CVE-2026-23400)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> rust_binder: llamar a set_notification_done() sin el bloqueo de proc<br /> <br /> Considere la siguiente secuencia de eventos en un oyente de muerte:<br /> 1. El proceso remoto muere y envía un mensaje BR_DEAD_BINDER.<br /> 2. El proceso local invoca el comando BC_CLEAR_DEATH_NOTIFICATION.<br /> 3. El proceso local luego invoca el BC_DEAD_BINDER_DONE.<br /> Entonces, el kernel responderá al comando BC_DEAD_BINDER_DONE con una<br /> respuesta BR_CLEAR_DEATH_NOTIFICATION_DONE usando push_work_if_looper().<br /> <br /> Sin embargo, esto puede resultar en un interbloqueo si el hilo actual no es un<br /> looper. Esto se debe a que dead_binder_done() aún mantiene el bloqueo de proc<br /> durante set_notification_done(), que llamó a push_work_if_looper().<br /> Normalmente, push_work_if_looper() toma el bloqueo de hilo, lo cual está bien tomar<br /> bajo el bloqueo de proc. Pero si el hilo actual no es un looper,<br /> entonces recurre a entregar la respuesta a la cola de trabajo del proceso,<br /> lo que implica tomar el bloqueo de proc. Dado que el bloqueo de proc ya está<br /> retenido, esto es un interbloqueo.<br /> <br /> Solucione esto liberando el bloqueo de proc durante set_notification_done(). No<br /> fue intencional que se mantuviera durante esa función para empezar.<br /> <br /> No creo que esto ocurra nunca en Android porque BC_DEAD_BINDER_DONE<br /> solo se invoca en respuesta a mensajes BR_DEAD_BINDER, y el kernel<br /> siempre entrega BR_DEAD_BINDER a un looper. Así que no hay ningún escenario donde<br /> el espacio de usuario de Android llame a BC_DEAD_BINDER_DONE en un hilo que no sea un looper.