Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mm: Verificar el valor de retorno de memblock_phys_alloc_range(). Al menos con CONFIG_PHYSICAL_START=0x100000, si hay < 4 MiB de memoria libre contigua disponible en este punto, el kernel se bloqueará porque memblock_phys_alloc_range() devuelve 0 en caso de fallo, lo que provoca que memblock_phys_free() descarte los primeros 4 MiB de memoria física. Como mínimo, debería fallar correctamente con un diagnóstico significativo, pero de hecho todo parece funcionar correctamente sin la extraña asignación de reserva.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio: interrumpir y reiniciar dispositivos virtio en device_shutdown() Hongyu informó de un bloqueo en kexec en una máquina virtual. QEMU informó de accesos a memoria no válidos durante el bloqueo. Lectura no válida en la dirección 0x102877002, tamaño 2, región '(null)', motivo: rechazada Escritura no válida en la dirección 0x102877A44, tamaño 2, región '(null)', motivo: rechazada ... Se rastreó hasta virtio-console. Kexec funciona bien si virtio-console no está en uso. El problema es que virtio-console continúa escribiendo en el MMIO incluso después de reiniciar el dispositivo virtio-pci subyacente. Además, Eric notó que las IOMMU se reinician antes que los dispositivos; si los dispositivos no se reinician al apagar, continúan presionando la memoria invitada y obtienen errores de la IOMMU. Algunos dispositivos se bloquean entonces. El problema se puede resolver rompiendo todos los dispositivos virtio al apagar el bus virtio y luego reiniciándolos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: lzo - Corrección de saturación del búfer de compresión. A diferencia del código de descompresión, el código de compresión de LZO nunca verifica si hay saturaciones de salida. En su lugar, asume que quien llama siempre proporciona suficiente espacio en el búfer, sin tener en cuenta la longitud del búfer proporcionada por él. Se ha añadido una interfaz de compresión segura que verifica el final del búfer antes de cada escritura. Se ha utilizado la interfaz segura en crypto/lzo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: orangefs: No truncar el tamaño del archivo. 'len' se utiliza para almacenar el resultado de i_size_read(), por lo que hacer que 'len' sea un size_t da como resultado un truncamiento a 4 GiB en sistemas de 32 bits.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm cache: impide BUG_ON bloqueando los reintentos en reinicios de dispositivos fallidos. Un dispositivo de caché que no se reanuda debido a errores de mapeo no debe reintentarse, ya que el fallo deja un objeto de política parcialmente inicializado. Repetir la operación de reanudación corre el riesgo de activar BUG_ON al recargar los mapeos de caché en el objeto de política incompleto. Reproducir los pasos: 1. Crear metadatos de caché que consten de 512 o más bloques de caché, con algunos mapeos almacenados en el primer bloque de la matriz de mapeo. Aquí usamos cache_restore v1.0 para generar los metadatos. cat <<> cmeta.xml EOF dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta 2. wipe the second array block of the mapping array to simulate data degradations. mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. try bringing up the cache device. The resume is expected to fail due to the broken array block. dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dmsetup create cache --notable dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup resume cache 4. Intente reanudar la caché de nuevo. Se activa un BUG_ON inesperado al cargar las asignaciones de caché. dmsetup resume cache Registros del kernel: (snip) ------------[ cortar aquí ]------------ ¡ERROR del kernel en drivers/md/dm-cache-policy-smq.c:752! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup No contaminado 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570 Se soluciona no permitiendo operaciones de reanudación para dispositivos que fallaron en el intento inicial.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: genirq/msi: Almacenar el IOVA de IOMMU directamente en msi_desc en lugar de en iommu_cookie La traducción de IOMMU para direcciones de mensajes MSI ha sido un proceso de 2 pasos, separados en el tiempo: 1) iommu_dma_prepare_msi(): Un puntero de cookie que contiene la dirección IOVA se almacena en el descriptor MSI cuando se asigna una interrupción MSI. 2) iommu_dma_compose_msi_msg(): este puntero de cookie se utiliza para calcular una dirección de mensaje traducida. Esto tiene un problema de vida útil inherente para el puntero almacenado en la cookie que debe seguir siendo válido entre los dos pasos. Sin embargo, no hay bloqueo en la capa irq que ayude a proteger la vida útil. Hoy en día, esto funciona bajo el supuesto de que el dominio iommu no cambia mientras se programan las interrupciones MSI. Esto aplica a los usuarios normales de la API de DMA dentro del kernel, ya que el dominio iommu se conecta antes de sondear el controlador y no se puede cambiar mientras esté conectado. El tipo 1 de VFIO clásico también impedía cambiar el dominio iommu mientras VFIO se ejecutaba, ya que no admite cambiar el "contenedor" después del inicio. Sin embargo, iommufd ha mejorado esto para que el dominio iommu se pueda cambiar durante la operación de VFIO. Esto potencialmente permite que el espacio de usuario compita directamente con VFIO_DEVICE_ATTACH_IOMMUFD_PT (que llama a iommu_attach_group()) y VFIO_DEVICE_SET_IRQS (que llama a iommu_dma_compose_msi_msg()). Esto potencialmente provoca que tanto el puntero de cookie como la llamada desbloqueada a iommu_get_domain_for_dev() en la ruta de traducción MSI se conviertan en UAF. Corrija el UAF de la cookie MSI eliminando el puntero de cookie. La dirección IOVA traducida ya se conoce durante iommu_dma_prepare_msi() y no puede modificarse. Por lo tanto, puede almacenarse simplemente como un entero en el descriptor MSI. El resto de UAF relacionado con iommu_get_domain_for_dev() se abordará en el parche "iommu: Convertir iommu_dma_prepare_msi() en una operación genérica" mediante el mutex del grupo IOMMU.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm: se corrige la limitación de E/S incondicional causada por REQ_PREFLUSH Cuando se envía una biografía con REQ_PREFLUSH a dm, __send_empty_flush() genera una flush_bio con REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC, lo que hace que wbt_wait() limite la flush_bio. Un ejemplo de v5.4, también existe un problema similar en upstream: crash> bt 2091206 PID: 2091206 TAREA: ffff2050df92a300 CPU: 109 COMANDO: "kworker/u260:0" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs] #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs] #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs] #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs] #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs] #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08 #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc #18 [ffff800084a2fe70] kthread at ffff800040118de4. Tras el commit 2def2845cc33 ("xfs: no permitir la limitación de la E/S del registro"), los metadatos enviados por xlog_write_iclog() no deberían limitarse. Sin embargo, debido a la existencia de la capa dm, limitar la ejecución de flush_bio provoca indirectamente la limitación de los metadatos bio. Solucione esto agregando condicionalmente REQ_IDLE a flush_bio.bi_opf, lo que hace que wbt_should_throttle() devuelva falso para evitar wbt_wait().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rseq: Arreglar violación de segmentación en el registro cuando rseq_cs no es cero El campo rseq_cs está documentado como establecido a 0 por el espacio de usuario antes del registro, sin embargo esto no es aplicado actualmente por el kernel. Esto puede resultar en una violación de segmentación al regresar al espacio de usuario si el valor almacenado en el campo rseq_cs no apunta a una estructura rseq_cs válida. La solución correcta para esto sería fallar el registro de rseq cuando el campo rseq_cs no es cero. Sin embargo, algunas versiones anteriores de glibc reutilizarán el área rseq de subprocesos anteriores sin borrar el campo rseq_cs y también terminarán el proceso si el registro de rseq falla en un subproceso secundario. Esto no fue detectado en las pruebas porque en este caso el rseq_cs restante apunta a una estructura rseq_cs válida. Lo que podemos hacer es borrar el campo rseq_cs durante el registro cuando no sea cero, lo que evitará errores de segmentación en el registro y no dañará las versiones de glibc que reutilizan áreas rseq en la creación de subprocesos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/intel: Corrección de una falla de segmentación con PEBS-via-PT con sample_freq. Actualmente, usar PEBS-via-PT con una frecuencia de muestreo en lugar de un periodo de muestreo provoca una falla de segmentación. Por ejemplo: Error: Desreferencia de puntero nulo del kernel, dirección: 0000000000000195 ? __die_body.cold+0x19/0x27 ? page_fault_oops+0xca/0x290 ? exc_page_fault+0x7e/0x1b0 ? asm_exc_page_fault+0x26/0x30 ? intel_pmu_pebs_event_update_no_drain+0x40/0x60 ? intel_pmu_pebs_event_update_no_drain+0x32/0x60 intel_pmu_drain_pebs_icl+0x333/0x350 handle_pmi_common+0x272/0x3c0 intel_pmu_handle_irq+0x10a/0x2e0 perf_event_nmi_handler+0x2a/0x50 Esto sucede porque intel_pmu_pebs_event_update_no_drain() asume que todos los bits pebs_enabled representan índices de contador, lo que no siempre es el caso. En este caso particular, los bits 60 y 61 se establecen para fines de PEBS a través de PT. El comportamiento de PEBS a través de PT con frecuencia de muestreo es cuestionable porque, aunque se genera un PMI (PEBS_PMI_AFTER_EACH_RECORD), el período no se ajusta de todos modos. Dejando eso de lado, corrija intel_pmu_pebs_event_update_no_drain() pasando la máscara de bits del contador en lugar de 'size'. Tenga en cuenta que, antes de el commit de las correcciones, 'size' estaba limitado al índice máximo del contador, por lo que el problema no se solucionó.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: ocp: Limitar el conteo de señales/frecuencias en las funciones de salida de resumen. La salida de resumen de debugfs podría acceder a elementos no inicializados en las matrices freq_in[] y signal_out[], lo que causa desreferencias de punteros nulos y desencadena un error de kernel (page_fault_oops). Este parche agrega campos u8 (nr_freq_in, nr_signal_out) para rastrear el número de elementos inicializados, con un máximo de 4 por matriz. Las funciones de salida de resumen se actualizan para respetar estos límites, lo que evita el acceso fuera de los límites y garantiza el manejo seguro de la matriz. Amplíe las variables de etiqueta porque el cambio confunde a GCC sobre la longitud máxima de las cadenas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: copy_verifier_state() debería copiar el campo 'loop_entry'. El estado bpf_verifier_state.loop_entry debería ser copiado por copy_verifier_state(). De lo contrario, los valores .loop_entry de estados no relacionados envenenarían env->cur_state. Además, env->stack no debería contener ningún estado con .loop_entry != NULL. Los estados en env->stack aún están por verificar, mientras que .loop_entry está configurado para estados que alcanzaron un estado equivalente. Esto significa que env->cur_state->loop_entry siempre debería ser NULL después de pop_stack(). Vea la autoprueba en la siguiente confirmación para un ejemplo del programa que no es seguro pero es aceptado por el verificador sin esta corrección. Este cambio tiene algún impacto en el rendimiento de la verificación para las autopruebas: Archivo Programa Insns (A) Insns (B) Insns (DIFF) Estados (A) Estados (B) Estados (DIFF) ---------------------------------- ---------------------------- --------- --------- -------------- ---------- ---------- ------------- arena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%)Y un impacto negativo significativo para sched_ext: Archivo Programa Insns (A) Insns (B) Insns (DIFF) Estados (A) Estados (B) Estados (DIFF) ----------------- ---------------------- --------- --------- -------------------- ---------- ---------- ------------------ bpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%) bpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%) bpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%) bpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%) bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%) bpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%) bpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%) bpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%) scx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%) scx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%) scx_qmap.bpf.o qmap_dispatch ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: evitar la desreferencia de puntero NULL si no hay un árbol csum válido [ERROR] Al intentar una limpieza de solo lectura en un btrfs con la opción de montaje rescue=idatacsums, se bloqueará con el siguiente seguimiento de llamada: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000208 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: GO 6.15.0-rc3-custom+ #236 PREEMPT(full) Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS desconocido 02/02/2022 RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs] Seguimiento de llamadas: scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs] scrub_simple_mirror+0x175/0x290 [btrfs] scrub_stripe+0x5f7/0x6f0 [btrfs] scrub_chunk+0x9a/0x150 [btrfs] scrub_enumerate_chunks+0x333/0x660 [btrfs] btrfs_scrub_dev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSE] La opción de montaje "rescue=idatacsums" omitirá por completo la carga del árbol de sumas de comprobación (CSUM), por lo que los datos leídos no encontrarán ninguna CSU, por lo que se ignorará la verificación de la suma de comprobación de datos. Normalmente, los sitios de llamada que utilizan el árbol de CSU comprueban el bit NO_DATA_CSUMS del indicador de estado del sistema de archivos, pero lamentablemente, scrub no lo comprueba en absoluto. Esto provoca que scrub llame a btrfs_search_slot() en un puntero nulo, lo que provocó el bloqueo mencionado anteriormente. [CORRECCIÓN] Compruebe la extensión y la raíz del árbol de CSU antes de realizar cualquier búsqueda en el árbol.