Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPICA: corrección de fuga de caché de operandos de ACPI en dswstate.c, confirmación de ACPICA 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732. Se detectó una fuga de caché de ACPI en el caso de terminación anticipada de ACPI y continuación del arranque. Cuando se produce una terminación anticipada debido a una tabla ACPI maliciosa, el kernel de Linux finaliza la función ACPI y continúa el proceso de arranque. Mientras el kernel finaliza la función ACPI, kmem_cache_destroy() informa de una fuga de caché de operandos de ACPI. El registro de arranque de la fuga de caché de operandos de ACPI es el siguiente: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continuar con el arranque y se omite el registro ... Analicé esta pérdida de memoria en detalle y encontré que la función acpi_ds_obj_stack_pop_and_delete() calculó mal la parte superior de la pila. La función acpi_ds_obj_stack_push() usa walk_state->operand_index para la posición inicial del top, pero la función acpi_ds_obj_stack_pop_and_delete() considera el índice 0. Por lo tanto, esto provoca una fuga de memoria de operandos de ACPI. Esta fuga de caché representa una amenaza para la seguridad, ya que un kernel antiguo (<= 4.9) muestra las ubicaciones de memoria de las funciones del kernel en el volcado de pila. Algunos usuarios maliciosos podrían usar esta información para neutralizar la ASLR del kernel. Creé un parche para corregir la fuga de caché de operandos de ACPI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPICA: se corrigen las fugas de caché de ACPI parse y parseext. Confirmación de ACPICA 8829e70e1360c81e7a5a901b5d4f48330e021ea5. Soy Seunghun Han y trabajo para el Instituto de Investigación de Seguridad Nacional de Corea del Sur. He estado investigando sobre ACPI y he encontrado una fuga de caché en casos de aborto temprano de ACPI. El registro de arranque de la pérdida de caché ACPI es el siguiente: [0.352414] ACPI: _OSI(Dispositivo de módulo) añadido [0.353182] ACPI: _OSI(Dispositivo de procesador) añadido [0.353182] ACPI: _OSI(Extensiones 3.0 _SCP) añadido [0.353182] ACPI: _OSI(Dispositivo agregador de procesador) añadido [0.356028] ACPI: No se puede iniciar el intérprete ACPI [0.356799] Error ACPI: No se pudo eliminar el controlador SCI (20170303/evmisc-281) [0.360215] kmem_cache_destroy Estado Acpi: La caché Slab todavía tiene objetos [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Rastreo de llamadas: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 Analicé esta fuga de memoria en detalle. Descubrí que las cachés "Acpi-State" y "Acpi-Parse" se fusionaron porque el tamaño de los objetos de la caché era el mismo que el de la caché slab. Finalmente, descubrí que las cachés "Acpi-Parse" y "Acpi-parse_ext" se filtraron mediante el indicador SLAB_NEVER_MERGE de la función kmem_cache_create(). El punto de fuga de caché ACPI real es el siguiente: [0.360101] ACPI: _OSI(Dispositivo de módulo) añadido [0.360101] ACPI: _OSI(Dispositivo de procesador) añadido [0.360101] ACPI: _OSI(Extensiones 3.0 _SCP) añadido [0.361043] ACPI: _OSI(Dispositivo agregador de procesador) añadido [0.364016] ACPI: No se puede iniciar el intérprete ACPI [0.365061] Error ACPI: No se pudo eliminar el controlador SCI (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: La caché Slab aún tiene objetos [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Rastreo de llamadas: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: La caché Slab aún tiene objetos [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Rastreo de llamadas: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x3 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nodo de software: Se corrige una comprobación OOB en software_node_get_reference_args(). software_node_get_reference_args() busca obtener el elemento @index-ésimo, por lo que el valor de la propiedad requiere al menos '(index + 1) * sizeof(*ref)' bytes, pero esto no se puede garantizar con la comprobación OOB actual y puede causar OOB para una propiedad mal formada. Se corrige usando como comprobación OOB '((index + 1) * sizeof(*ref) > prop->length)'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: fbnic: evita la doble liberación al no poder asignar DMA a FW msg. La semántica es que quien llama a fbnic_mbx_map_msg() conserva la propiedad del mensaje en caso de error. Todos los que llaman liberan la página correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: cs_dsp: Se corrige el acceso de lectura de memoria OOB en la prueba KUnit KASAN informó un acceso fuera de los límites - cs_dsp_mock_bin_add_name_or_info(), porque la longitud de la cadena de origen se redondeó al tamaño de asignación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/bpf: corrección del cálculo del tamaño del código JIT del trampolín BPF. arch_bpf_trampoline_size() proporciona el tamaño JIT del trampolín BPF antes de asignar el búfer para su procesamiento JIT. El número total de instrucciones emitidas para el código JIT del trampolín BPF depende de la ubicación de la imagen final. Por lo tanto, el tamaño obtenido con el paso ficticio en arch_bpf_trampoline_size() puede variar del tamaño real necesario en arch_prepare_bpf_trampoline(). Cuando las instrucciones contabilizadas en arch_bpf_trampoline_size() son menores que la cantidad de instrucciones emitidas durante la compilación JIT real del trampolín, se produce la siguiente advertencia: ADVERTENCIA: CPU: 8 PID: 204190 en arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc que es: /* Asegúrese de que la lógica de generación del trampolín no se desborde */ if (image && WARN_ON_ONCE(&image[ctx->idx] > (u32 *)rw_image_end - BPF_INSN_SAFETY)) { Entonces, durante el pase ficticio, en lugar de proporcionar una ubicación de imagen arbitraria, tenga en cuenta la máxima cantidad de instrucciones posibles si y cuando exista una dependencia con la ubicación de la imagen para JIT.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/nfs/read: corrige error de doble desbloqueo en nfs_return_empty_folio() En ocasiones, cuando se leía un archivo mientras otro cliente NFS lo estaba truncando, el kernel podía bloquearse porque se llamaba a folio_unlock() dos veces y la segunda llamada XOR devolvería el indicador `PG_locked`. La mayoría de las veces (dependiendo del momento del truncamiento), nadie nota el problema porque folio_unlock() se llama tres veces, lo que desactiva `PG_locked`: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio El problema es que nfs_read_add_folio() no debe desbloquear el folio si fscache está habilitado, y falta una comprobación nfs_netfs_folio_unlock() en nfs_return_empty_folio(). En raras ocasiones, esto genera una advertencia en netfs_read_collection(): ------------[ cortar aquí ]------------ R=0000031c: el folio 10 no está bloqueado ADVERTENCIA: CPU: 0 PID: 29 en fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Cola de trabajo: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Rastreo de llamadas: netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0worker_thread+0x295/0x3a0 Sin embargo, la mayoría de las veces, los procesos simplemente se quedan atascados para siempre en folio_wait_bit_common(), esperando que `PG_locked` desaparezca, lo que nunca sucede porque nadie está realmente reteniendo el cerradura de folio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jbd2: se corrigieron los errores data-race y null-ptr-deref en jbd2_journal_dirty_metadata(). Dado que handle->h_transaction puede ser un puntero nulo, debemos modificarlo para que llame primero a is_handle_aborted(handle) antes de desreferenciarlo. La siguiente vulnerabilidad data-race se reportó en mi fuzzer: ======================================================================== BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... value changed: 0x00000000 -> 0x00000001 ======================================================================== Este problema se debe a la falta de la anotación de carrera de datos para jh->b_modified. Por lo tanto, es necesario agregarla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: pata_via: Forzar PIO para dispositivos ATAPI en VT6415/VT6330 El controlador tiene un error de hardware que puede bloquear el sistema al realizar DMA ATAPI sin dejar rastro de lo sucedido. Dependiendo del dispositivo conectado, también puede impedir que el sistema arranque. En este caso, el sistema se bloquea al leer el ATIP desde un medio óptico con cdrecord -vvv -atip en un _NEC DVD_RW ND-4571A 1-01 y un Optiarc DVD RW AD-7200A 1.06 conectados a un ASRock 990FX Extreme 4, corriendo en UDMA/33. El problema se puede reproducir ejecutando el mismo comando con una compilación cygwin de cdrecord en WinXP, aunque requiere más intentos para provocarlo. El bloqueo en ese caso también se resuelve forzando PIO. No parece que VIA haya producido ningún controlador para ese sistema operativo, por lo que no existe ninguna solución alternativa conocida. Los discos duros conectados al controlador no sufren ningún problema de DMA.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: gpio-keys - corrige un fallo de suspensión mientras es atómico con PREEMPT_RT Al habilitar PREEMPT_RT, la devolución de llamada gpio_keys_irq_timer() se ejecuta en un contexto de irq duro, pero input_event() toma un spin_lock, que no está permitido allí ya que se convierte en un rt_spin_lock(). [ 4054.289999] ERROR: función de suspensión llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 [ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0 ... [ 4054.290195] __might_resched+0x13c/0x1f4 [ 4054.290209] rt_spin_lock+0x54/0x11c [ 4054.290219] input_event+0x48/0x80 [ 4054.290230] gpio_keys_irq_timer+0x4c/0x78 [ 4054.290243] __hrtimer_run_queues+0x1a4/0x438 [ 4054.290257] hrtimer_interrupt+0xe4/0x240 [ 4054.290269] arch_timer_handler_phys+0x2c/0x44 [ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c [ 4054.290297] handle_irq_desc+0x40/0x58 [ 4054.290307] generic_handle_domain_irq+0x1c/0x28 [ 4054.290316] gic_handle_irq+0x44/0xcc Teniendo en cuenta que gpio_keys_irq_isr() puede ejecutarse en cualquier contexto, por ejemplo, puede ser Enhebrado, parece que no tiene sentido solicitar que el temporizador ISR se ejecute en un contexto de IRQ estricto. Reduzca la velocidad del temporizador hr para que no use dicho contexto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: cortina: Usar TOE/TSO en todos los protocolos TCP. Es deseable que el acelerador de hardware también procese tramas TCP no segmentadas: pasamos el comando skb->len al descargador "TOE/TSO" y este las gestionará. Sin esta peculiaridad, el controlador se vuelve inestable, se bloquea y se bloquea. No sé exactamente por qué, pero probablemente se deba a la función TOE (motor de descarga TCP) que está acoplada a la función de segmentación: no es posible desactivar una parte y no la otra, ya sea que tanto TOE como TSO estén activos, o ninguno de ellos. No tener activa la función TOE parece perjudicial, como si esa función de hardware no debiera estar desactivada. La hoja de datos indica: "Con base en el análisis de paquetes y los resultados de la búsqueda de la conexión TCP/tabla NAT, NetEngine coloca los paquetes pertenecientes a la misma conexión TCP en la misma cola para que el software los procese. NetEngine coloca los paquetes entrantes en el búfer o en una serie de búferes para un paquete jumbo. Con esta aceleración de hardware, el análisis de encabezados IP/TCP, la validación de la suma de comprobación y la búsqueda de conexión se descargan del procesamiento del software". Tras numerosas pruebas con el hardware bloqueándose después de minutos u horas, dependiendo de la carga, utilizando iperf3, he concluido que esto es necesario para estabilizar el hardware.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Usar memcpy() para la versión de BIOS. La función strlcat() compatible con FORTIFY genera un pánico porque cree que el búfer de destino se desbordará, aunque se haya proporcionado el tamaño correcto. En cualquier caso, en lugar de usar memset() con 0 seguido de strlcat(), simplemente use memcpy() y asegúrese de que el búfer resultante termine en NULL. BIOSVersion solo se usa para lpfc_printf_log(), que espera una cadena con la terminación correcta.