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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Arreglar el bloqueo en sendmsg de rxrpc Corrige tres errores en la implementación de sendmsg de rxrpc: (1) rxrpc_new_client_call() debería liberar el bloqueo del socket al devolver un error de rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() retornará sin el mutex de llamada retenido en caso de que seamos interrumpidos por una señal mientras esperamos espacio de transmisión en el socket o volvemos a bloquear el mutex de llamada posteriormente. Corrige esto mediante: (a) mover el desbloqueo/bloqueo del mutex de llamada hasta rxrpc_send_data() de modo que el bloqueo no se mantenga alrededor de todo rxrpc_wait_for_tx_window*() y (b) indicar a los llamadores superiores si retornamos con el bloqueo eliminado. Tenga en cuenta que esto significa que recvmsg() no se bloqueará en esta llamada mientras esperamos. (3) Después de eliminar y recuperar el mutex de llamada, rxrpc_send_data() debe volver a verificar el estado del búfer tx_pending y la comprobación de tx_total_len en caso de que hayamos utilizado otro sendmsg() en la misma llamada. Pensándolo bien, podría tener sentido tener bloqueos diferentes para sendmsg() y recvmsg(). Probablemente no sea necesario que recvmsg() espere a sendmsg(). Esto significa que recvmsg() puede devolver MSG_EOR, lo que indica que una llamada está inactiva antes de que un sendmsg() a esa llamada regrese, pero eso puede ocurrir de todos modos. Sin la corrección (2), se puede inducir algo como lo siguiente: ¡ADVERTENCIA: se detectó un saldo de desbloqueo incorrecto! 5.16.0-rc6-syzkaller #0 No contaminado ------------------------------------- syz-executor011/3597 está intentando liberar el bloqueo (&call->user_mutex) en: [] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 ¡pero no hay más bloqueos para liberar! Otra información que podría ayudarnos a depurar esto: syz-executor011/3597 no tiene bloqueos. ... Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug include/trace/events/lock.h:58 [en línea] __lock_release kernel/locking/lockdep.c:5306 [en línea] lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [en línea] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae [Gracias a Hawkins Jiawei y Khalid Masum por sus intentos de solucionar este problema]