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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: 9p/trans_fd: syzbot reporta que la tarea se bloquea en p9_fd_close() [1], ya que p9_mux_poll_stop() de p9_conn_destroy() de p9_fd_close() no interrumpe las solicitudes kernel_read() de p9_fd_read() de p9_read_work() o kernel_write() de p9_fd_write() de p9_write_work() ya iniciadas. Dado que p9_socket_open() establece el indicador O_NONBLOCK, p9_mux_poll_stop() no necesita interrumpir kernel_read()/kernel_write(). Sin embargo, dado que p9_fd_open() no establece el indicador O_NONBLOCK, sino que bloquea la tubería a menos que la señal esté pendiente, p9_mux_poll_stop() necesita interrumpir kernel_read()/kernel_write() cuando el descriptor de archivo hace referencia a una tubería. En otras palabras, el descriptor de archivo de la tubería debe manejarse como si fuera un descriptor de archivo de socket. De alguna manera, necesitamos interrumpir kernel_read()/kernel_write() en las tuberías. Un cambio mínimo, que este parche está realizando, es establecer el indicador O_NONBLOCK de p9_fd_open(), ya que el indicador O_NONBLOCK no afecta la lectura/escritura de archivos normales. Pero este enfoque cambia el indicador O_NONBLOCK en los descriptores de archivo proporcionados por el espacio de usuario (lo que podría romper los programas del espacio de usuario), y el indicador O_NONBLOCK podría ser cambiado por el espacio de usuario. Sería posible establecer el indicador O_NONBLOCK cada vez que se invoca p9_fd_read()/p9_fd_write(), pero aún queda una pequeña ventana de tiempo para borrar el indicador O_NONBLOCK. Si no queremos manipular el indicador O_NONBLOCK, podríamos rodear kernel_read()/kernel_write() con set_thread_flag(TIF_SIGPENDING) y recalc_sigpending(). Dado que los trabajos de p9_read_work()/p9_write_work() son procesados por hilos del núcleo que procesan la cola de trabajo global system_wq, no se pudieron enviar señales desde hilos remotos al llamar a p9_mux_poll_stop() de p9_conn_destroy() de p9_fd_close(). Por lo tanto, sería necesario llamar a set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() cada vez si dependemos de señales para que kernel_read()/kernel_write() sea no bloqueante. [Dominique: añadir comentario a la sugerencia de Christian]