Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: endpoint: pci-epf-test: Se corrige la doble liberación que provoca un error en el kernel. Se corrige un error en el kernel detectado al probar el controlador de endpoint stm32_pcie con el manejo de la deaserción PERST#: Durante la inicialización de EP, pci_epf_test_alloc_space() asigna todos los BAR, que se liberan aún más si epc_set_bar() falla (por ejemplo, debido a que no hay una ventana de entrada libre). Sin embargo, cuando pci_epc_set_bar() falla, la ruta de error: pci_epc_set_bar() -> pci_epf_free_space() no borra la asignación previa a epf_test->reg[bar]. Luego, si el host se reinicia, la desasignación PERST# reinicia la secuencia de asignación de BAR con el mismo fallo de asignación (sin ventana de entrada libre), lo que crea una situación de doble liberación, ya que epf_test->reg[bar] se desasignó y sigue siendo distinto de NULL. Por lo tanto, asegúrese de que las invocaciones de pci_epf_alloc_space() y pci_epf_free_space() sean simétricas y, por lo tanto, establezca epf_test->reg[bar] en NULL cuando se libere memoria. [kwilczynski: registro de confirmaciones]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corregir ejecución entre set_blocksize y las rutas de lectura Con el nuevo soporte para tamaños de sector grandes, ahora es posible que set_blocksize cambie i_blksize y el orden de los folios de forma que entre en conflicto con un lector concurrente y provoque un fallo del kernel. Específicamente, supongamos que udev-worker llama a libblkid para detectar las etiquetas en un dispositivo de bloque. La llamada de lectura puede crear un folio de orden 0 para leer los primeros 4096 bytes del disco. Pero entonces udev es interrumpido. A continuación, alguien intenta montar un sistema de archivos de tamaño de sector de 8k desde el mismo dispositivo de bloque. El sistema de archivos llama a set_blksize, que establece i_blksize en 8192 y el orden mínimo de folio en 1. Ahora udev se reanuda, aún manteniendo el folio de orden 0 que asignó. Entonces intenta programar una biografía de lectura y do_mpage_readahead intenta crear bufferheads para el folio. Desafortunadamente, bloques_por_folio == 0 porque el tamaño de página es 4096, pero el tamaño de bloque es 8192, por lo que no se conectan bufferheads y el bh walk nunca establece bdev. Luego, enviamos la biografía con un dispositivo de bloque nulo y se produce un fallo. Por lo tanto, truncamos la caché de páginas después del vaciado, pero antes de actualizar i_blksize. Sin embargo, esto no es suficiente; también necesitamos bloquear la E/S de archivos y los fallos de página durante la actualización. Use tanto i_rwsem como invalidate_lock en modo exclusivo para invalidaciones y en modo compartido para operaciones de lectura/escritura. No sé si esta sea la solución correcta, pero xfs/259 la encontró.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: iscsi: Se corrige el tiempo de espera en la conexión eliminada. El temporizador de respuesta NOPIN puede expirar en una conexión eliminada y bloquearse con dichos registros: No se recibió respuesta a NOPIN en CID: 0, falla de conexión para I_T Nexus (nulo),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod] Rastreo de llamadas: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410 Esto se debe a que el temporizador de respuesta de nopin puede reiniciarse al expirar. Deténgalo antes de detener el temporizador de respuesta de nopin para asegurarse de que ninguno de ellos se reinicie.

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: libnvdimm/labels: Corregir error de división en nd_label_data_init() Si un dispositivo de memoria CXL defectuoso devuelve un tamaño LSA cero roto en su información de dispositivo de memoria (Identificar dispositivo de memoria (Opcode 4000h), especificación CXL 3.1, 8.2.9.9.1.1), se produce un error de división en el controlador libnvdimm: Oops: error de división: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm] Código y flujo: 1) El comando CXL 4000h devuelve tamaño LSA = 0 2) config_size se asigna a tamaño LSA cero (controlador pmem CXL): drivers/cxl/pmem.c: .config_size = mds->lsa_size, 3) max_xfer se establece en cero (controlador nvdimm): drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size); 4) Un DIV_ROUND_UP() posterior provoca una división por cero: drivers/nvdimm/label.c: /* Hacer que nuestro tamaño de lectura inicial sea un múltiplo del tamaño max_xfer */ drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size); Solucione esto comprobando el parámetro de tamaño de configuración extendiendo una comprobación existente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vhost-scsi: proteger vq->log_used con vq->mutex La ruta de finalización de vhost-scsi puede acceder a vq->log_base cuando vq->log_used ya está configurado como falso. vhost-thread QEMU-thread vhost_scsi_complete_cmd_work() -> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU deshabilita vq->log_used mediante VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex); QEMU gfree(vq->log_base) log_used() -> log_write(vq->log_base) Suponiendo que el VMM es QEMU. La ruta vq->log_base proviene del espacio de usuario de QEMU y se puede recuperar mediante gfree(). Como resultado, esto provoca escrituras de memoria no válidas en el espacio de usuario de QEMU. La ruta de la cola de control presenta el mismo problema.

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: 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: 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: 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: 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.