Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: soc-pcm: Agregar comprobación NULL en la reparentalización de BE Agregar comprobación NULL en la API dpcm_be_reparent para manejar el error de desreferencia de puntero NULL del kernel. El problema se produjo en la prueba de fuzzing.

Motivo del rechazo: esta autoridad de numeración CVE ha rechazado o retirado esta ID CVE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: seq: Fix function prototipo desajuste en snd_seq_expand_var_event Con la integridad del flujo de control del kernel de clang (kCFI, CONFIG_CFI_CLANG), los objetivos de llamada indirecta se validan contra el prototipo de puntero de función esperado para asegurarse de que el objetivo de llamada sea válido para ayudar a mitigar los ataques ROP. Si no son idénticos, hay un error en el tiempo de ejecución, que se manifiesta como un pánico del kernel o la muerte del hilo. seq_copy_in_user() y seq_copy_in_kernel() no tenían prototipos que coincidieran con snd_seq_dump_func_t. Ajústelo y elimine las conversiones. No hay diferencias de salida binaria resultantes. Esto se encontró como resultado del nuevo indicador -Wcast-function-type-strict de Clang, que es más sensible que el más simple -Wcast-function-type, que solo verifica los desajustes de ancho de tipo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: raydium_ts_i2c - arregla pérdida de memoria en raydium_i2c_send() Hay una pérdida de kmem cuando se prueba raydium_i2c_ts con bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] dispositivo_de_sonda_de_controlador+0x49/0x120 [<00000000264fe082>] __controlador_de_adjuntar_dispositivo+0xf7/0x150 [<00000000f919423c>] bus_para_cada_unidad+0x114/0x180 [<00000000e067feca>] __adjuntar_dispositivo+0x1e5/0x2d0 [<0000000054301fc2>] dispositivo_de_sonda_de_bus+0x126/0x140 [<00000000aad93b22>] dispositivo_agregar+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 objeto sin referencia 0xffff88812d3675c8 (tamaño 8): comm "python3", pid 349, jiffies 4294741070 (antigüedad 95,692 s) volcado hexadecimal (primeros 8 bytes): 22 00 36 2d 81 88 ff ff ".6-.... traza inversa: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] realmente_sondeo+0x17c/0x3f0 [<00000000096ba499>] __dispositivo_de_sonda_de_controlador+0xe3/0x170 [<00000000c5acb4d9>] dispositivo_de_sonda_de_controlador+0x49/0x120 [<00000000264fe082>] __dispositivo_adjunto_controlador+0xf7/0x150 [<00000000f919423c>] bus_para_cada_unidad+0x114/0x180 [<00000000e067feca>] __dispositivo_adjunto+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 Después del comando BANK_SWITCH del BUS i2c, sin importar si se produjo un éxito o un error, se debe liberar el tx_buf.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/sysfs: se corrige la suposición incorrecta de esquemas vacíos durante el ajuste en línea en damon_sysfs_set_schemes(). el commit da87878010e5 ("mm/damon/sysfs: soporte para la actualización de entradas en línea") hizo que se llamara a 'damon_sysfs_set_schemes()' para ejecutar el contexto DAMON, que podría tener esquemas. En este caso, se supone que la interfaz sysfs de DAMON actualiza, elimina o agrega esquemas para reflejar los archivos sysfs. Sin embargo, el código asume que el contexto DAMON no tendría esquemas en absoluto y, por lo tanto, crea y agrega nuevos esquemas. Como resultado, el código no funciona como se esperaba para el ajuste de esquemas en línea y podría tener una huella de memoria mayor a la esperada. Todos los esquemas están en el contexto DAMON, por lo que no pierde memoria. Elimine la suposición incorrecta (el contexto DAMON no tendría esquemas) en 'damon_sysfs_set_schemes()' para corregir el error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: char: tpm: Proteger tpm_pm_suspend con bloqueos Actualmente, las transacciones tpm se ejecutan incondicionalmente en la función tpm_pm_suspend(), lo que puede generar ejecuciones con otros accesores tpm en el sistema. Específicamente, el controlador tpm hw_random hace uso de tpm_get_random(), y esta función se llama en un bucle desde un kthread, lo que significa que no está congelada junto con el espacio de usuario, y por lo tanto puede competir con el trabajo realizado durante la suspensión del sistema: tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: TPM_STS.x 0xff no válido, volcando pila para análisis forense CPU: 0 PID: 1 Comm: init No contaminado 6.1.0-rc5+ #135 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Rastreo de llamadas: tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80 __pnp_bus_suspend+0x35/0xe0 __device_suspend+0x10f/0x350 Solucione este problema llamando a tpm_try_get_ops(), que es un contenedor de tpm_chip_start(), pero toma el mutex apropiado. [Jason: mensaje de confirmación rediseñado, metadatos agregados]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/bpf/32: Se ha corregido el error Oops en las pruebas de llamadas de cola. Las pruebas de llamadas de cola test_bpf terminan como: test_bpf: #0 Tail call leaf jited:1 85 PASS test_bpf: #1 Tail call 2 jited:1 111 PASS test_bpf: #2 Tail call 3 jited:1 145 PASS test_bpf: #3 Tail call 4 jited:1 170 PASS test_bpf: #4 Tail call load/store leaf jited:1 190 PASS test_bpf: #5 Tail call load/store jited:1 ERROR: No se puede manejar el acceso a los datos del kernel en escritura en 0xf1b4e000 Dirección de instrucción errónea: 0xbe86b710 Oops: Acceso al kernel de un área defectuosa, firma: 11 [#1] BE PAGE_SIZE=4K MMU=Hash Módulos PowerMac vinculados en: test_bpf(+) CPU: 0 PID: 97 Comm: insmod No contaminado 6.1.0-rc4+ #195 Nombre del hardware: PowerMac3,1 750CL 0x87210 PowerMac NIP: be86b710 LR: be857e88 CTR: be86b704 REGS: f1b4df20 TRAP: 0300 No contaminado (6.1.0-rc4+) MSR: 00009032 CR: 28008242 XER: 00000000 DAR: f1b4e000 DSISR: 42000000 GPR00: 00000001 f1b4dfe0 c11d2280 00000000 00000000 00000000 00000002 00000000 GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8 GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000 GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00 NIP [be86b710] 0xbe86b710 LR [be857e88] __run_one+0xec/0x264 [test_bpf] Seguimiento de llamada: [f1b4dfe0] [00000002] 0x2 (no confiable) Volcado de instrucción: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ fin del seguimiento 000000000000000 ]--- Esto es una tentativa de escribir sobre la pila. El problema se encuentra con las pruebas agregadas por el commit 38608ee7b690 ("bpf, pruebas: Agregar caso de prueba de almacenamiento de carga para llamada de cola") Esto sucede porque la llamada de cola se realiza a un programa BPF con una profundidad de pila diferente. En ese momento, la pila se mantiene como está cuando el llamador llama a la cola de su llamado. Pero al salir, el llamado restaura la pila en función de sus propias propiedades. Por lo tanto, aquí, en cada ejecución, r1 se incrementa erróneamente en 32 - 16 = 16 bytes. Esto se hizo de esa manera para pasar el recuento de llamadas de cola del llamador al llamado a través de la pila. Como powerpc32 no tiene una zona roja en la pila, fue necesario mantener la pila como está para la llamada de cola. Pero no se anticipó que el tamaño del marco BPF podría ser diferente. Tomemos un nuevo enfoque. Use el registro r4 para llevar el recuento de llamadas de cola durante la llamada de cola y guárdelo en la pila en la entrada de la función si es necesario. Esto significa que el parámetro de entrada debe estar en r3, lo cual es más correcto ya que es un parámetro de 32 bits, por lo que la llamada de cola coincide mejor con la entrada de la función BPF normal, la desventaja es que movemos ese parámetro de entrada de ida y vuelta entre r3 y r4. Esto se puede optimizar más adelante. Hacer eso también tiene la ventaja de maximizar las partes comunes entre las llamadas de cola y una salida de función normal. Con la corrección, las pruebas de llamadas de cola ahora son exitosas: test_bpf: #0 Hoja de llamada de cola jited:1 53 PASS test_bpf: #1 Llamada de cola 2 jited:1 115 PASS test_bpf: #2 Llamada de cola 3 jited:1 154 PASS test_bpf: #3 Llamada de cola 4 jited:1 165 PASS test_bpf: #4 Hoja de carga/almacenamiento de llamadas de cola jited:1 101 PASS test_bpf: #5 Carga/almacenamiento de llamadas de cola jited:1 141 PASS test_bpf: #6 Ruta de error de llamada de cola, recuento máximo alcanzado jited:1 994 PASS test_bpf: #7 Recuento de llamadas de cola conservado en todas las llamadas de función jited:1 140975 PASS test_bpf: #8 Ruta de error de llamada de cola, objetivo NULL jited:1 110 PASS test_bpf: #9 --- truncado ----

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4: Controlar el intento de eliminar una ruta multipath cuando fib_info contiene una referencia nh Gwangun Jung informó un acceso fuera de los límites en fib_nh_match: fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961 fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753 inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874 Los objetos de siguiente salto separados son mutuamente excluyentes con la especificación multipath heredada. Arreglar fib_nh_match para que regrese si la configuración de la ruta que se va a eliminar contiene una especificación de rutas múltiples mientras fib_info usa un objeto nexthop.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se soluciona la fuga de recuento de referencias del dispositivo PCI en has_external_pci(). for_each_pci_dev() se implementa mediante pci_get_device(). El comentario de pci_get_device() dice que aumentará el recuento de referencias para el pci_dev devuelto y también disminuirá el recuento de referencias para el pci_dev de entrada @from si no es NULL. Si interrumpimos el bucle for_each_pci_dev() con pdev no NULL, debemos llamar a pci_dev_put() para disminuir el recuento de referencias. Agregue el pci_dev_put() faltante antes de 'return true' para evitar la fuga del recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: arregla la ejecución cuando se desborda la pila de vmap Actualmente, al detectar un desbordamiento de la pila de vmap, riscv primero cambia a la llamada pila de sombra, luego usa esta pila de sombra para llamar a get_overflow_stack() para obtener la pila de desbordamiento. Sin embargo, aquí hay una ejecución si dos o más harts usan la misma pila de sombra al mismo tiempo. Para resolver esta ejecución, introducimos la variable atómica spin_shadow_stack, que se intercambiará entre su propia dirección y 0 de forma atómica, cuando la variable está configurada, significa que se está usando shadow_stack; cuando la variable se borra, significa que no se está usando shadow_stack. [Palmer: Agrega AQ al intercambio y también algunos comentarios].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige la pérdida de recuento de referencias del dispositivo PCI en dmar_dev_scope_init(). for_each_pci_dev() se implementa mediante pci_get_device(). El comentario de pci_get_device() dice que aumentará el recuento de referencias para el pci_dev devuelto y también disminuirá el recuento de referencias para el pci_dev de entrada @from si no es NULL. Si interrumpimos el bucle for_each_pci_dev() con pdev no NULL, debemos llamar a pci_dev_put() para disminuir el recuento de referencias. Agregue el pci_dev_put() faltante para la ruta de error para evitar la pérdida del recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme: se corrige la protección SRCU de la lista nvme_ns_head El recorrido por la lista de hermanos nvme_ns_head está protegido por el srcu del cabezal en nvme_ns_head_submit_bio() pero no por nvme_mpath_revalidate_paths(). La eliminación de espacios de nombres de la lista también fallo al sincronizar el srcu. Por lo tanto, el trabajo de escaneo simultáneo puede causar use-after-free. Mantenga el bloqueo del srcu del cabezal en nvme_mpath_revalidate_paths() y sincronice con el srcu, no con el RCU global, en nvme_ns_remove(). Se observó el siguiente pánico al realizar conexiones NVMe/RDMA con multipath nativo en el kernel Rocky Linux 8.6 (parece que el kernel ascendente tiene la misma condición de ejecución). El desensamblaje muestra que la instrucción que fallo es cmp 0x50(%rdx),%rcx; capacidad de cómputo != get_capacity(ns->disk). La dirección 0x50 está desreferenciada porque ns->disk es NULL. El disco NULL parece ser el resultado de un trabajo de escaneo simultáneo que libera el espacio de nombres (observe la línea de registro en el medio del pánico). [37314.206036] ERROR: no se puede manejar la desreferencia del puntero NULL del núcleo en 0000000000000050 [37314.206036] nvme0n3: se detectó un cambio de capacidad de 0 a 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: cargado Tainted: GWX --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1 [37314.299762] Nombre del hardware: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 23/05/2018 [37314.299763] Cola de trabajo: nvme-wq nvme_scan_work [nvme_core] [37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core] [37314.299790] Código: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 [37315.713871] CR2: 000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Seguimiento de llamadas: [37315.828515] nvme_update_ns_info+0x1ac/0x250 [núcleo_nvme] [37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [núcleo_nvme] [37315.961871] ? __blk_mq_free_request+0x6b/0x90 [37316.015021] nvme_scan_work+0x151/0x240 [núcleo_nvme] [37316.073371] process_one_work+0x1a7/0x360 [37316.121318] ? crear_trabajador+0x1a0/0x1a0 [37316.168227] subproceso_trabajador+0x30/0x390 [37316.212024] ? crear_trabajador+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? Módulos vinculados en: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc superposición nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me---truncado---