Vulnerabilidades

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 en smb2_reconnect_server() El error de UAF se debe a que smb2_reconnect_server() accede a una sesión que ya está siendo cancelada por otro hilo que está ejecutando __cifs_put_smb_ses(). Esto puede suceder cuando (a) el cliente tiene conexión al servidor pero no tiene sesión o (b) otro hilo termina configurando @ses->ses_status nuevamente en algo diferente a SES_EXITING. Para solucionar este problema, debemos asegurarnos de establecer incondicionalmente @ses->ses_status en SES_EXITING y evitar que otros hilos establezcan un nuevo estado mientras todavía lo estamos derribando. Lo siguiente se puede reproducir agregando algo de retraso justo después de que se libera el ipc en __cifs_put_smb_ses(), lo que le dará al trabajador smb2_reconnect_server() la oportunidad de ejecutarse y luego acceder a @ses->ipc: kinit ... mount.cifs // srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10 [disconnect srv] ls /mnt/1 &>/dev/null dormir 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verifique que el usuario tenga un ticket krb5 y keyutils esté instalado CIFS: VFS: \\srv Enviar error en SessSetup = -126 CIFS: VFS: Verifique que el usuario tenga un ticket krb5 y keyutils esté instalado CIFS: VFS: \\srv Enviar error en SessSetup = -126 fallo de protección general, probablemente para dirección no canónica 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Nombre de hardware : PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 01/04/2014 Cola de trabajo: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0 Código: 4f 08 48 85 d2 4 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 9 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: muerto000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Seguimiento de llamadas: < TASK> ? die_addr+0x36/0x90? exc_general_protection+0x1c1/0x3f0? asm_exc_general_protection+0x26/0x30? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] Process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

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 ha resuelto la siguiente vulnerabilidad: smb: cliente: garantiza que los hijos recontados desde la sesión principal Evite posibles errores de use after free al recorrer referencias DFS, montar y realizar la conmutación por error de DFS asegurándose de que todos los hijos del padre @tcon- >ses también se cuentan nuevamente. Todos son necesarios en todo el montaje DFS. Deshazte de @tcon->dfs_ses_list mientras estamos en eso también.

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