Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: no acepte skbs GSO que no sean de túnel que aterricen en un túnel Cuando rx-udp-gro-forwarding está habilitado, los paquetes UDP pueden recibir GRO al reenviarse. Si dichos paquetes pudieran aterrizar en un túnel, esto puede causar varios problemas y udp_gro_receive se asegura de que este no sea el caso buscando un socket coincidente. Esto se realiza en udp4/6_gro_lookup_skb pero sólo en las redes actuales. Este es un problema con los paquetes tunelizados cuando el punto final está en otra red. En tales casos, los paquetes se almacenarán en el nivel UDP, lo que generará varios problemas más adelante. Lo mismo puede pasar con rx-gro-list. Vimos esto con paquetes geneve siendo GRO en el nivel UDP. En tal caso, se establece gso_size; luego, el paquete pasa por la ruta geneve rx, se extrae el encabezado geneve, se ajusta el desplazamiento y los skbs frag_list no se ajustan con respecto a geneve. Cuando esos skbs lleguen a skb_fragment, se comportará mal. Son posibles diferentes resultados dependiendo del aspecto de los skbs GROed; desde paquetes corruptos hasta fallas del kernel. Un ejemplo es un BUG_ON[1] activado en skb_segment mientras se procesa frag_list. Debido a que gso_size es incorrecto (se extrajo el encabezado geneve), skb_segment cree que hay un "tamaño de encabezado geneve" de datos en frag_list, aunque en realidad es el siguiente paquete. El BUG_ON en sí no tiene nada que ver con el problema. Éste es sólo uno de los posibles problemas. Buscar un socket coincidente en udp_gro_receive es frágil: la búsqueda podría extenderse a todas las redes (sin hablar de rendimiento), pero nada impide que esos paquetes se modifiquen en el medio y todavía no pudimos encontrar un socket coincidente. Está bien mantener la lógica actual allí, ya que debería cubrir la mayoría de los casos, pero también debemos asegurarnos de manejar los paquetes de túnel que se procesan en GRO demasiado pronto. Esto se hace ampliando las comprobaciones en udp_unexpected_gso: los paquetes OSG que carecen de los bits SKB_GSO_UDP_TUNNEL/_CSUM y que aterrizan en un túnel deben segmentarse. [1] ¡BUG del kernel en net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: of:dynamic: Sincronizar of_changeset_destroy() con las eliminaciones de devlink En la siguiente secuencia: 1) of_platform_depopulate() 2) of_overlay_remove() Durante el paso 1, los dispositivos se destruyen y los devlinks son remoto. Durante el paso 2, los nodos OF se destruyen, pero __of_changeset_entry_destroy() puede generar advertencias relacionadas con la falta de of_node_put(): ERROR: pérdida de memoria, recuento esperado 1 en lugar de 2... De hecho, durante las eliminaciones de devlink realizadas en el paso 1, la eliminación La liberación del dispositivo (y el of_node adjunto) se realiza mediante un trabajo en cola en una cola de trabajo y, por lo tanto, se realiza de forma asincrónica con respecto a las llamadas a funciones. Cuando la advertencia está presente, se llamará a of_node_put() pero erróneamente demasiado tarde desde el trabajo de la cola de trabajo. Para asegurarse de que cualquier eliminación de devlink en curso se realice antes de la destrucción de of_node, sincronice of_changeset_destroy() con las eliminaciones de devlink.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corrige UAF potencial en smb2_is_valid_oplock_break() Omita las sesiones que se están eliminando (estado == SES_EXITING) para evitar UAF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corrige UAF potencial en cifs_stats_proc_write() Omita las sesiones que se están eliminando (estado == SES_EXITING) para evitar UAF.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/secretmem: corrige el éxito rápido de GUP en folios secretmem folio_is_secretmem() actualmente depende de que los folios secretmem sean folios LRU, para guardar algunos ciclos. Sin embargo, las publicaciones pueden residir en un lote de publicaciones sin el indicador LRU establecido o tener su indicador LRU borrado temporalmente. En consecuencia, la bandera LRU no es fiable para este fin. En particular, este es el caso cuando secretmem_fault() asigna una página nueva y llama a filemap_add_folio()->folio_add_lru(). La publicación podría agregarse al lote de publicaciones por CPU y no se establecerá el indicador LRU hasta que el lote se drene usando, por ejemplo, lru_add_drain(). En consecuencia, es posible que folio_is_secretmem() no detecte folios secretmem y GUP-fast puede lograr capturar un folio secretmem, bloqueando el kernel cuando más tarde intentemos leer/escribir en el folio, porque el folio no se ha desasignado del mapa directo. Solucionarlo eliminando ese cheque poco confiable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: corrige la restauración del estado del vector en rt_sigreturn() La especificación del vector RISC-V indica en el "Apéndice D: Llamando convención por el estado del vector" [1] que "La ejecución de una llamada al sistema causa todos los registros vectoriales guardados por la persona que llama (v0-v31, vl, vtype) y vstart quedarán sin especificar". En el kernel RISC-V, esto se denomina "descartar el vstate". Al regresar de un controlador de señales a través de la llamada al sistema rt_sigreturn(), también se realiza el descarte de vectores. Sin embargo, esto no es un problema ya que el estado del vector debe restaurarse desde el contexto de señal y, por lo tanto, no preocuparse por el descarte del vector. El "estado en vivo" es el registro vectorial real en el contexto de ejecución, y el "vstate" es el estado vectorial de la tarea. Un estado en vivo sucio significa que el vstate y el estado en vivo no están sincronizados. Cuando se introdujo user_from_copy() vectorizado, se coló un error en el código de restauración, relacionado con el descarte del estado activo. Un ejemplo de cuando esto sale mal: 1. Una aplicación de usuario está ejecutando código vectorial. 2. La aplicación recibe una señal y se ingresa el controlador de señales. 3. La aplicación regresa del controlador de señales, utilizando la llamada al sistema rt_sigreturn(). 4. El estado del vector en vivo se descarta al ingresar a rt_sigreturn() y el estado en vivo se marca como "sucio", lo que indica que el estado en vivo debe sincronizarse con el vstate actual. 5. rt_sigreturn() restaura el vstate, excepto los registros Vector, desde el sigcontext 6. rt_sigreturn() restaura los registros Vector, desde el sigcontext, y ahora se usa el user_from_copy() vectorizado. El estado activo sucio del descarte se guarda en el vstate, lo que hace que el vstate sea corrupto. 7. rt_sigreturn() regresa a la aplicación, que falla debido a un vstate dañado. Tenga en cuenta que el usuario_from_copy() vectorizado se invoca dependiendo del valor de CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD. El valor predeterminado es 768, lo que significa que vlen debe ser mayor que 128b para que se active este error. La solución es simplemente marcar el estado activo como no sucio/limpio antes de realizar la restauración de vstate.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: aio: corrige el ptr deref null en aio_complete() wakeup list_del_init_careful() debe ser el último acceso a la entrada de la cola de espera; efectivamente desbloquea el acceso. Anteriormente, Finish_wait() veía el encabezado de la lista vacía y omitía tomar el bloqueo, y luego regresabamos, pero la ruta de finalización aún intentaría realizar la reactivación después de que se hubiera sobrescrito el puntero task_struct.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/coco: requiere inicialización de RNG con RDRAND en sistemas CoCo. Hay pocos usos de CoCo que no dependan de una criptografía funcional y, por lo tanto, de un RNG funcional. Desafortunadamente, el modelo de amenaza CoCo significa que no se puede confiar en el host de la VM y puede trabajar activamente contra los invitados para extraer secretos o manipular los cálculos. Dado que un host malicioso puede modificar u observar casi todas las entradas de los invitados, la única fuente de entropía restante para los invitados CoCo es RDRAND. Si RDRAND se rompe (debido a una falla del hardware de la CPU), el RNG en su conjunto debe continuar recopilando entropía de otras fuentes, pero como no hay otras fuentes en CoCo, esto es catastrófico. Esto es principalmente una preocupación en el momento del arranque cuando se siembra inicialmente el RNG, ya que después de eso las consecuencias de un RDRAND roto son mucho más teóricas. Entonces, intente en el arranque inicializar el RNG usando 256 bits de salida RDRAND. Si esto falla, entra en pánico(). Esto también se activará si el sistema se inicia sin RDRAND, ya que RDRAND es esencial para un inicio CoCo seguro. Agregue esto deliberadamente para que sea "solo una característica del controlador CoCo x86" y no parte del RNG en sí. Muchos controladores de dispositivos y plataformas desean contribuir con algo al RNG, y add_device_randomness() está diseñado específicamente para este propósito. Cualquier conductor puede llamarlo con datos semilla de cualquier calidad, o incluso calidad basura, y solo puede mejorar la calidad del RNG o no tener ningún efecto, pero nunca puede empeorarlo. En lugar de intentar construir algo en el núcleo del RNG, considere el problema particular de CoCo solo como un problema de CoCo y, por lo tanto, sepárelo todo en código de controlador (bueno, arco/plataforma).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/mce: asegúrese de tomar mce_sysfs_mutex en set_bank() La modificación de los bits MCA_CTL de un banco MCA que controlan qué tipos de errores se informarán se realiza a través de /sys/devices/system/machinecheck / ??? machinecheck0? ??? bank0? ??? bank1? ??? bank10? ??? bank11 ... nodos sysfs escribiendo la nueva máscara de bits de eventos para habilitar. Cuando se acepta la escritura, el kernel elimina todos los temporizadores actuales y reinicia todos los banks. Hacer eso en paralelo puede llevar a inicializar un temporizador que ya está armado y en la rueda del temporizador, es decir, que ya está en uso: ODEBUG: init active (estado activo 0) objeto: ffff888063a28000 tipo de objeto: timer_list sugerencia: mce_timer_fn+0x0/0x240 arch /x86/kernel/cpu/mce/core.c:2642 ADVERTENCIA: CPU: 0 PID: 8120 en lib/debugobjects.c:514 debug_print_object+0x1a0/0x2a0 lib/debugobjects.c:514 Solucione eso tomando el mutex sysfs como el resto del código sysfs de MCA lo hace. Reportado por: Yue Sun Reportado por: xingwei lee

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corrige UAF potencial en cifs_stats_proc_show() Omita las sesiones que se están eliminando (estado == SES_EXITING) para evitar UAF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mm/pat: corrige el manejo de VM_PAT en asignaciones COW El manejo de PAT no funcionará correctamente en las asignaciones COW: la primera PTE (o, de hecho, todas las PTE) pueden ser reemplazado durante fallos de escritura para señalar folios anónimos. Recuperar de manera confiable el PFN y el modo de caché correctos usando follow_phys() de las PTE no funcionará en las asignaciones COW. Usando follow_phys(), podríamos obtener la dirección+protección de la publicación anónima (lo cual es muy incorrecto), o fallar en las entradas de intercambio/no intercambio, fallando en follow_phys() y activando un WARN_ON_ONCE() en untrack_pfn() y track_pfn_copy() , no llamando correctamente a free_pfn_range(). En free_pfn_range(), no llamaríamos a memtype_free() o lo llamaríamos con el rango incorrecto, posiblemente perdiendo memoria. Para solucionarlo, actualicemos follow_phys() para rechazar la devolución de publicaciones anónimas y recurramos al uso del PFN almacenado dentro de vma->vm_pgoff para asignaciones COW si nos encontramos con eso. Ahora manejaremos adecuadamente untrack_pfn() con asignaciones COW, donde no necesitamos el modo caché. Sin embargo, tendremos que fallar fork()->track_pfn_copy() si la primera página fue reemplazada por una publicación anónima: tendríamos que almacenar el modo de caché en el VMA para que esto funcione, probablemente aumentando el tamaño del VMA. Por ahora, mantengámoslo simple y dejemos que track_pfn_copy() simplemente falle en ese caso: ya habría fallado en el pasado con entradas de intercambio/no intercambio, y habría hecho algo incorrecto con folios anónimos. Reproductor simple para activar WARN_ON_ONCE() en untrack_pfn(): <--- Reproductor C ---> #include #include #include #include int main(void) { struct io_uring_params p = {}; int anillo_fd; tamaño_t tamaño; carbón *mapa; ring_fd = io_uring_setup(1, &p); if (ring_fd < 0) { perror("io_uring_setup"); devolver 1; } tamaño = p.sq_off.array + p.sq_entries * tamaño de (sin firmar); /* Asigna el anillo de cola de envío MAP_PRIVATE */ map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, ring_fd, IORING_OFF_SQ_RING); if (mapa == MAP_FAILED) { perror("mmap"); devolver 1; } /* Tenemos al menos una página. Vamos a acobardarnos. */ *mapa = 0; pausa(); devolver 0; } <--- Reproductor C ---> En un sistema con 16 GiB de RAM y swap configurado: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut aquí ]------------ [ 301.553285] ADVERTENCIA: CPU: 7 PID: 1402 en arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100 [ 301.553989] Módulos vinculados en : binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g [ 301.558232] CPU: 7 PID: 1402 Comm: iouring No contaminado 6.7.5-100.fc38.x86_64 #1 [ 301.558772] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100 [ 301.559893] Código: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 455e047 [301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [301.562628] RBP: 0000000000000000 R08: 8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 00000 R14: ffffba2c0377fc08 R15: 00000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 0 [301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] KRU: 55555554 [ 301.565944] Seguimiento de llamadas: [ 301.566148] [ 301.566325] ? untrack_pfn+0xf4/0x100 [301.566618]? __advertir+0x81/0x130 [ 301.566876] ? untrack_pfn+0xf4/0x100 [ 3 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: proceso: corregir la fuga de gp del kernel. Los registros secundarios representan los registros que están activos para el nuevo hilo en el contexto del usuario. Para un subproceso del kernel, childregs->gp nunca se usa ya que switch_to no toca el gp del kernel. Para un asistente en modo de usuario, el valor gp se puede observar en el espacio del usuario después de execve o posiblemente por otros medios. [Del hilo del correo electrónico] El comentario /* Hilo del kernel */ es algo inexacto porque también se usa para los hilos user_mode_helper, que ejecutan un proceso de usuario, por ejemplo, /sbin/init o cuando /proc/sys/kernel/core_pattern es un tubo. Dichos subprocesos no tienen PF_KTHREAD configurado y son objetivos válidos para ptrace, etc., incluso antes de ejecutarse. childregs es el contexto *usuario* durante la ejecución de la llamada al sistema y es observable desde el espacio de usuario de al menos cinco maneras: 1. kernel_execve actualmente no borra registros enteros, por lo que el estado de registro inicial para PID 1 y otros procesos de usuario iniciados por el núcleo tiene sp = pila de usuario, gp = kernel __global_pointer$, todos los demás registros enteros puestos a cero por el memset en el comentario del parche. Esto es un error en sí mismo, pero no estoy dispuesto a apostar que es la única forma de explotar el problema solucionado por este parche. 2. ptrace(PTRACE_GETREGSET): puede PTRACE_ATTACH a un subproceso user_mode_helper antes de que se ejecute, pero ptrace requiere que se entregue SIGSTOP, lo que solo puede ocurrir en los límites del usuario/kernel. 3. /proc/*/task/*/syscall: es un placer leer pt_regs para user_mode_helpers antes de que se complete el ejecutivo, pero gp no es uno de los registros que devuelve. 4. PERF_SAMPLE_REGS_USER: LOCKDOWN_PERF normalmente impide el acceso a las direcciones del kernel a través de PERF_SAMPLE_REGS_INTR, pero debido a este error, las direcciones del kernel también se exponen a través de PERF_SAMPLE_REGS_USER, que está permitido bajo LOCKDOWN_PERF. No he intentado escribir código de explotación. 5. Gran parte de la infraestructura de rastreo permite el acceso a los registros de usuarios. No he intentado determinar qué formas de rastreo permiten el acceso a los registros de usuarios sin permitir ya el acceso a los registros del kernel.