Vulnerabilidades

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: 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 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 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: 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: bpf: se admite el aplazamiento de la asignación de bpf_link después del período de gracia de RCU. El enlace BPF para algunos tipos de programas se pasa como un "contexto" que pueden utilizar esos programas BPF para buscar información adicional. Por ejemplo, para multi-kprobes y multi-uprobes, el enlace se utiliza para recuperar valores de cookies BPF. Debido a esta dependencia del tiempo de ejecución, cuando bpf_link refcnt cae a cero, todavía podría haber programas BPF activos ejecutándose y accediendo a los datos del enlace. Este parche agrega soporte genérico para diferir la devolución de llamada de bpf_link dealloc después de RCU GP, si se solicita. Esto se hace exponiendo dos devoluciones de llamada de desasignación diferentes, una sincrónica y otra diferida. Si se proporciona uno diferido, bpf_link_free() programará la devolución de llamada de dealloc_deferred() para que se realice después de RCU GP. BPF utiliza dos tipos de RCU: uno "clásico" que no se puede dormir y uno de seguimiento de tareas de RCU. Este último se utiliza cuando se utilizan programas BPF que se pueden dormir. bpf_link_free() se adapta a eso al verificar el indicador de suspensión del programa BPF subyacente, y pasa por la GP de RCU normal solo para los no dormidos, o a través de tareas de RCU rastrean la GP *y* luego la GP de RCU normal (teniendo en cuenta la optimización de rcu_trace_implies_rcu_gp()), si El programa BPF se puede dormir. Usamos esto para enlaces multi-kprobe y multi-uprobe, que desreferencian el enlace durante la ejecución del programa. También cambiamos preventivamente el enlace raw_tp para usar la devolución de llamada de dealloc diferida, ya que los próximos cambios en el árbol bpf-next también exponen los datos del enlace raw_tp (específicamente, el valor de la cookie) al programa BPF en tiempo de ejecución.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: corrige UAF potencial en cifs_signal_cifsd_for_reconnect() 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: client: corrige UAF potencial en smb2_is_network_name_deleted() 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 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 smb2_is_valid_lease_break() Omita las sesiones que se están eliminando (estado == SES_EXITING) para evitar UAF.

Una vulnerabilidad fue encontrada en SourceCodester Simple Inventory System 1.0 y clasificada como crítica. Una función desconocida del archivo updateprice.php es afectada por esta vulnerabilidad. La manipulación del argumento ITEM conduce a la inyección SQL. El ataque puede lanzarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse. VDB-265082 es el identificador asignado a esta vulnerabilidad.