Vulnerabilidades

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> smb: cliente: dividir los campos de bits de cached_fid para evitar condiciones de carrera RMW de bytes compartidos<br /> <br /> is_open, has_lease y on_list se almacenan en el mismo byte de campo de bits en la estructura cached_fid, pero se actualizan en diferentes rutas de código que pueden ejecutarse concurrentemente. Las asignaciones de campos de bits generan operaciones de lectura-modificación-escritura de bytes (p. ej., &amp;#39;orb $mask, addr&amp;#39; en x86_64), por lo que al actualizar una bandera (flag) se puede restaurar valores obsoletos de las otras.<br /> <br /> Una posible intercalación es:<br /> CPU1: carga el byte antiguo (has_lease=1, on_list=1)<br /> CPU2: borra ambas banderas (almacena 0)<br /> CPU1: almacena RMW (old | IS_OPEN) -&amp;gt; reintroduce los bits borrados<br /> <br /> Para evitar esta clase de condiciones de carrera, hay que convertir estas banderas a campos bool separados.

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux: <br /> <br /> crypto: virtio - Añadir protección con spinlock con notificación de virtqueue<br /> <br /> Cuando una VM arranca con un dispositivo PCI virtio-crypto y un backend integrado,<br /> ejecutar el comando de benchmark de OpenSSL con múltiples procesos, como<br /> openssl speed -evp aes-128-cbc -engine afalg -seconds 10 -multi 32<br /> <br /> los procesos de OpenSSL se colgarán y se reporta un error como este:<br /> virtio_crypto virtio0: dataq.0:id 3 is not a head!<br /> <br /> Parece que el virtqueue de datos necesita protección cuando se maneja<br /> para la notificación de finalización de virtio. Si se añade la protección con spinlock<br /> en virtcrypto_done_task(), el benchmark de OpenSSL con múltiples procesos<br /> funciona correctamente.

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> smb: servidor: corregir fuga de active_num_conn en ksmbd_tcp_new_connection()<br /> <br /> En caso de fallo de kthread_run() en ksmbd_tcp_new_connection(), se libera el transporte a través de free_transport(), lo que no decrementa active_num_conn, fugando este contador.<br /> <br /> Reemplazar free_transport() con ksmbd_tcp_disconnect().

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> xfs: se corrige UAF en xchk_btree_check_block_owner<br /> <br /> No podemos desreferenciar bs-&amp;gt;cur al intentar determinar si bs-&amp;gt;cur es un alias de bs-&amp;gt;sc-&amp;gt;sa.{bno,rmap}_cur después de que este último haya sido liberado. Esto se soluciona muestreando el tipo antes de que pudiera ocurrir cualquier liberación. El orden temporal correcto se rompió cuando eliminamos xfs_btnum_t.

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> sched/mmcid: No asumir que el CID es propiedad de la CPU en el cambio de modo<br /> <br /> Shinichiro informó de un KASAN UAF, que en realidad es un acceso fuera de límites en el código de gestión de MMCID.<br /> <br /> CPU0 CPU1<br /> T1 se ejecuta en espacio de usuario<br /> T0: fork(T4) -&amp;gt; Cambio a modo CID por CPU<br /> fixup() establece MM_CID_TRANSIT en T1/CPU1<br /> T4 sale()<br /> T3 sale()<br /> T2 sale()<br /> T1 sale() cambia a modo por tarea<br /> ---&amp;gt; Acceso fuera de límites.<br /> <br /> Como T1 no se ha planificado después de que T0 estableciera el bit TRANSIT, sale con el bit TRANSIT establecido. sched_mm_cid_remove_user() borra el bit TRANSIT en la tarea y elimina el CID, pero no toca el almacenamiento por CPU. Eso es el funcionalmente correcto porque un CID solo es propiedad de la CPU cuando el bit ONCPU está establecido, lo cual es mutuamente excluyente con el indicador TRANSIT.<br /> <br /> Ahora sched_mm_cid_exit() asume que el CID es propiedad de la CPU porque el modo anterior era por CPU. Invoca mm_drop_cid_on_cpu() que borra el bit ONCPU no establecido y luego invoca clear_bit() con un número de bit increíblemente grande porque TRANSIT está establecido (bit 29).<br /> <br /> Evitar eso validando realmente que el CID es propiedad de la CPU en mm_drop_cid_on_cpu().

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> drm/exynos: vidi: usar ctx-&amp;gt;lock para proteger las variables miembro de la estructura vidi_context relacionadas con la asignación/liberación de memoria<br /> <br /> El controlador de pantalla virtual de Exynos realiza operaciones de asignación/liberación de memoria sin protección de bloqueo, lo que fácilmente causa un problema de concurrencia.<br /> <br /> Por ejemplo, el uso después de liberación puede ocurrir en un escenario de carrera como este:<br /> ```<br /> CPU0 CPU1 CPU2<br /> ---- ---- ----<br /> vidi_connection_ioctl()<br /> if (vidi-&amp;gt;connection) // true<br /> drm_edid = drm_edid_alloc(); // alloc drm_edid<br /> ...<br /> ctx-&amp;gt;raw_edid = drm_edid;<br /> ...<br /> drm_mode_getconnector()<br /> drm_helper_probe_single_connector_modes()<br /> vidi_get_modes()<br /> if (ctx-&amp;gt;raw_edid) // true<br /> drm_edid_dup(ctx-&amp;gt;raw_edid);<br /> if (!drm_edid) // false<br /> ...<br /> vidi_connection_ioctl()<br /> if (vidi-&amp;gt;connection) // false<br /> drm_edid_free(ctx-&amp;gt;raw_edid); // free drm_edid<br /> ...<br /> drm_edid_alloc(drm_edid-&amp;gt;edid)<br /> kmemdup(edid); // UAF!!<br /> ...<br /> ```<br /> <br /> Para prevenir estas vulnerabilidades, al menos en vidi_context, las variables miembro relacionadas con la asignación/liberación de memoria deberían ser protegidas con ctx-&amp;gt;lock.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> crypto: omap - Asignar correctamente las scatterlists OMAP_CRYPTO_FORCE_COPY<br /> <br /> La asignación existente de scatterlists en omap_crypto_copy_sg_lists() estaba asignando un array de punteros a scatterlist, no objetos scatterlist, lo que resultaba en una asignación 4 veces demasiado pequeña.<br /> <br /> Usar sizeof(*new_sg) para obtener el tamaño de objeto correcto.

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> bus: fsl-mc: corrección de uso después de liberación en driver_override_show()<br /> <br /> La función driver_override_show() lee la cadena driver_override sin mantener el device_lock. Sin embargo, driver_override_store() utiliza driver_set_override(), que modifica y libera la cadena mientras mantiene el device_lock.<br /> <br /> Esto puede resultar en un uso después de liberación concurrente si la cadena es liberada por la función store mientras es leída por la función show.<br /> <br /> Solucionar esto manteniendo el device_lock alrededor de la operación de lectura.

Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux:<br /> <br /> ksmbd: corrige un bucle infinito causado por el reinicio de next_smb2_rcv_hdr_off en las rutas de error<br /> <br /> El problema ocurre cuando una solicitud firmada falla la verificación de firma smb2. En __process_request(), si check_sign_req() devuelve un error, se llama a set_smb2_rsp_status(work, STATUS_ACCESS_DENIED). set_smb2_rsp_status() establece work-&amp;gt;next_smb2_rcv_hdr_off a cero. Al reiniciar next_smb2_rcv_hdr_off a cero, el puntero al siguiente comando en la cadena se pierde. En consecuencia, is_chained_smb2_message() continúa apuntando a la misma cabecera de solicitud en lugar de avanzar. Si el campo NextCommand de la cabecera no es cero, la función devuelve verdadero, lo que hace que __handle_ksmbd_work() procese repetidamente la misma solicitud fallida en un bucle infinito. Esto resulta en el registro del kernel siendo inundado con mensajes de &amp;#39;firma smb2 incorrecta&amp;#39; y un alto uso de CPU.<br /> <br /> Este parche corrige el problema cambiando el valor de retorno de SERVER_HANDLER_CONTINUE a SERVER_HANDLER_ABORT. Esto asegura que el bucle de procesamiento termine inmediatamente en lugar de intentar continuar desde un desplazamiento invalidado.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nilfs2: Corrige un posible desbordamiento de bloque que causa un cuelgue del sistema<br /> <br /> Cuando un usuario ejecuta el comando FITRIM, puede ocurrir un subdesbordamiento al calcular nblocks si end_block es demasiado pequeño. Dado que nblocks es de tipo sector_t, que es u64, un valor negativo de nblocks se convertirá en un entero positivo muy grande. Esto finalmente lleva a que la función de la capa de bloques __blkdev_issue_discard() tarde un tiempo excesivamente largo en procesar la cadena bio, y el bloqueo ns_segctor_sem permanezca retenido durante un largo período. Esto impide que otras tareas adquieran el bloqueo ns_segctor_sem, lo que resulta en el cuelgue reportado por syzbot en [1].<br /> <br /> Si el bloque final es demasiado pequeño, típicamente si es menor que el rango de 4KiB, dependiendo del uso del segmento 0, puede ser posible intentar una solicitud de descarte más allá del tamaño del dispositivo, causando el cuelgue.<br /> <br /> Saliendo con éxito y asignando el tamaño descartado (0 en este caso) a range-&amp;gt;len.<br /> <br /> Aunque los valores de inicio y longitud en el rango de entrada del usuario son demasiado pequeños, se adopta aquí una estrategia conservadora para ignorarlos de forma segura, lo cual es equivalente a una no-op; no realizará ningún recorte y no lanzará un error.<br /> <br /> [1]<br /> tarea:segctord estado:D pila:28968 pid:6093 tgid:6093 ppid:2 flags_de_tarea:0x200040 flags:0x00080000<br /> Traza de Llamada:<br /> rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272<br /> nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357<br /> nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline]<br /> nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684<br /> <br /> [ryusuke: corregida parte del mensaje de commit sobre las consecuencias]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> scsi: qla2xxx: Validar sp antes de liberar la memoria asociada<br /> <br /> Fallo del sistema con la siguiente firma<br /> [154563.214890] nvme nvme2: NVME-FC{1}: conexión del controlador completada<br /> [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Establecer el umbral de intercambio ZIO en 3.<br /> [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: ESTABLECER el umbral de intercambio de actividad ZIO en 5.<br /> [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: base de datos RSCN cambiada – 0078 0080 0000.<br /> [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: base de datos RSCN cambiada – 0078 00a0 0000.<br /> [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=habilitado (tasa de datos).<br /> [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=habilitado (tasa de datos).<br /> [154565.553079] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000f8<br /> [154565.553080] #PF: acceso de lectura de supervisor en modo kernel<br /> [154565.553082] #PF: error_code(0x0000) - página no presente<br /> [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0<br /> [154565.553089] Oops: 0000 1 PREEMPT SMP PTI<br /> [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: cargado Tainted: G OE ------- --- 5.14.0-503.11.1.el9_5.x86_64 #1<br /> [154565.553096] Nombre del hardware: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 30/09/2024<br /> [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx]<br /> [154565.553141] Código: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 &amp;lt;4c&amp;gt; 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b<br /> [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286<br /> [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002<br /> [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47<br /> [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a<br /> [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0<br /> [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000<br /> [154565.553152] FS: 0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000<br /> [154565.553154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0<br /> [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [154565.553159] PKRU: 55555554<br /> [154565.553160] Traza de llamadas:<br /> [154565.553162] <br /> [154565.553165] ? show_trace_log_lvl+0x1c4/0x2df<br /> [154565.553172] ? show_trace_log_lvl+0x1c4/0x2df<br /> [154565.553177] ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx]<br /> [154565.553215] ? __die_body.cold+0x8/0xd<br /> [154565.553218] ? page_fault_oops+0x134/0x170<br /> [154565.553223] ? snprintf+0x49/0x70<br /> [154565.553229] ? exc_page_fault+0x62/0x150<br /> [154565.553238] ? asm_exc_page_fault+0x22/0x30<br /> <br /> Verificar que sp no sea NULL antes de liberar cualquier memoria asociada

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: qla2xxx: Retrasar la descarga del módulo mientras el escaneo de la estructura está en progreso<br /> <br /> Fallo del sistema observado durante la prueba de carga/descarga en un bucle.<br /> <br /> [105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086<br /> [105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0<br /> [105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000<br /> [105954.384923] FS: 0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000<br /> [105954.384925] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0<br /> [105954.384928] PKRU: 55555554<br /> [105954.384929] Call Trace:<br /> [105954.384931] <br /> [105954.384934] qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx]<br /> [105954.384962] ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx]<br /> [105954.384980] ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx]<br /> [105954.384999] ? __wake_up_common+0x80/0x190<br /> [105954.385004] ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx]<br /> [105954.385023] ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx]<br /> [105954.385040] ? __handle_irq_event_percpu+0x3d/0x190<br /> [105954.385044] ? handle_irq_event+0x58/0xb0<br /> [105954.385046] ? handle_edge_irq+0x93/0x240<br /> [105954.385050] ? __common_interrupt+0x41/0xa0<br /> [105954.385055] ? common_interrupt+0x3e/0xa0<br /> [105954.385060] ? asm_common_interrupt+0x22/0x40<br /> <br /> La causa raíz de esto fue que hubo una liberación (dma_free_attrs) en el contexto de interrupción. Había un descubrimiento de dispositivo/escaneo de la estructura en progreso. Se emitió una descarga de módulo que estableció la bandera UNLOADING. Como parte del descubrimiento, después de recibir una interrupción, se programó una cola de trabajo (lo que implicó un trabajo a encolar). Dado que la bandera UNLOADING está establecida, el elemento de trabajo no fue asignado y la memoria mapeada tuvo que ser liberada. La liberación ocurrió en el contexto de interrupción, lo que llevó a un fallo del sistema. Retrasar la descarga del controlador hasta que el escaneo de la estructura esté completo para evitar el fallo.