Vulnerabilidad en kernel de Linux (CVE-2022-50202)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: hibernar: aplazar el sondeo del dispositivo al reanudar desde la hibernación syzbot informa una tarea colgada en misc_open() [1], ya que hay una ventana de ejecución de punto muerto AB-BA que involucra a la variable probe_count. Actualmente, wait_for_device_probe() de snapshot_open() de misc_open() puede dormir para siempre con misc_mtx retenido si probe_count no puede llegar a 0. Cuando un dispositivo es sondeado por la función de trabajo hub_event(), probe_count se incrementa antes de que comience la función de sondeo y probe_count se decrementa después de que la función de sondeo se complete. Hay tres casos que pueden evitar que probe_count caiga a 0. (a) Un dispositivo que se está sondeando dejó de responder (es decir, hardware roto/malicioso). (b) Un proceso que emula un dispositivo USB usando la interfaz /dev/raw-gadget dejó de responder por alguna razón. (c) Siguen llegando nuevas solicitudes de sondeo de dispositivo antes de que se completen las solicitudes de sondeo de dispositivo existentes. El fenómeno que syzbot reporta es (b). Un proceso que contiene system_transition_mutex y misc_mtx espera a que probe_count sea 0 dentro de wait_for_device_probe(), pero la función de sonda, llamada desde la función de trabajo hub_event(), espera a que los procesos bloqueados en mutex_lock(&misc_mtx) respondan mediante la interfaz /dev/raw-gadget. Este parche mitiga (b) al posponer wait_for_device_probe() de snapshot_open() a snapshot_write() y snapshot_ioctl(). Tenga en cuenta que la posibilidad de (b) persiste mientras cualquier hilo que emule un dispositivo USB mediante la interfaz /dev/raw-gadget pueda ser bloqueado por operaciones de bloqueo ininterrumpido (p. ej., mutex_lock()). Tenga en cuenta también que (a) y (c) no se abordan. Respecto a (c), debemos modificar el código para que espere solo a un dispositivo que contenga la imagen para reanudar la hibernación. No sé cómo abordar (a), ya que el uso del tiempo de espera para wait_for_device_probe() podría provocar la pérdida de datos de usuario en la imagen. Quizás deberíamos exigir que el espacio de usuario espere al dispositivo de imagen antes de abrir la interfaz /dev/snapshot.