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

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: Corregir ejecución en el desmontaje del socket Corrige una ejecución en el código de desmontaje del socket xsk que puede provocar un splat de desreferencia de puntero NULL. El código de desvinculación xsk actual en xsk_unbind_dev() comienza estableciendo xs->state en XSK_UNBOUND, establece xs->dev en NULL y luego espera a que finalice cualquier procesamiento NAPI utilizandosynchronous_net(). Después de eso, el código de lanzamiento comienza a desmantelar el estado del socket y a liberar la memoria asignada. ERROR: desreferencia de puntero NULL del núcleo, dirección: 00000000000000c0 PGD 8000000932469067 P4D 8000000932469067 PUD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Contaminado: GI 5.16.0+ #2 Nombre del hardware: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 09/03/2015 RIP: 0010:__xsk_sendmsg+0x2c/0x690 [...] RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246 RAX: 00000000000000000 RBX: 00000000000000040 RCX: ffff8d5fc632d258 RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800 RBP: ffffa2348bd13db0 R08: 000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000 FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0 Seguimiento de llamadas: ? aa_sk_perm+0x43/0x1b0 xsk_sendmsg+0xf0/0x110 sock_sendmsg+0x65/0x70 __sys_sendto+0x113/0x190 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x23/0x50 ? exit_to_user_mode_prepare+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Hay dos problemas con el código actual. Primero, establecer xs->dev en NULL antes de esperar a que todos los usuarios dejen de usar el socket no es correcto. La entrada a las funciones del plano de datos xsk_poll(), xsk_sendmsg() y xsk_recvmsg() están todas protegidas por una prueba de que xs->state está en el estado XSK_BOUND y, si no, regresa de inmediato. Pero un proceso podría haber pasado esta prueba pero aún no haber llegado al punto en el que usa xs->dev en el código. Mientras tanto, un segundo proceso que ejecuta xsk_unbind_dev() podría haber establecido xs->dev en NULL, lo que provocará un bloqueo para el primer proceso. La solución aquí es simplemente deshacerse de esta asignación NULL ya que ya no se usa. Antes de el commit 42fddcc7c64b ("xsk: usar miembro de estado para sincronización de socket"), xs->dev era el guardián para admitir procesos en las funciones del plano de datos, pero fue reemplazado por la variable de estado xs->state en el commit mencionada anteriormente. El segundo problema es quesynchronous_net() no espera a que se complete ningún proceso en xsk_poll(), xsk_sendmsg() o xsk_recvmsg(), lo que significa que el estado en el que se basan podría limpiarse prematuramente. Esto puede suceder cuando se llama al notificador (por ejemplo, al descargar el controlador) ya que utiliza xsk_unbind_dev(). Resuelva esto extendiendo la región crítica de RCU desde solo ndo_xsk_wakeup a todas las funciones mencionadas anteriormente, de modo que tanto la prueba de xs->state == XSK_BOUND como el último uso de cualquier miembro de xs estén cubiertos por la sección crítica de RCU. Esto garantizará que cuando se completesynchronous_net(), no habrá procesos restantes ejecutando xsk_poll(), xsk_sendmsg() o xsk_recvmsg() y el estado se puede limpiar de forma segura. Tenga en cuenta que debemos eliminar el bloqueo de RCU para la ruta de transmisión de skb, ya que utiliza funciones que podrían estar inactivas. Debido a esto, tenemos que volver a probar xs->state después de obtener el mutex que protege el código xmit de skb de, entre varias cosas, un xsk_unbind_dev() que se ejecuta desde el notificador al mismo tiempo.