Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Vuelva a aplicar "drm/qxl: simplificar qxl_fence_wait" Esto revierte el commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea. Stephen Rostedt informa: "Fui a ejecutar mis pruebas en mis máquinas virtuales y las pruebas se colgaron al arrancar. Desafortunadamente, lo máximo que obtuve fue: [ 93.607888] Probando evento de initcall del sistema: OK [ 93.667730] Ejecutando pruebas en todos los eventos de seguimiento : [93.669757] Probando todos los eventos: OK [95.631064] ------------[ cortar aquí ]------------ Se agotó el tiempo de espera después de 60 segundos" y más puntos de depuración a una posible dependencia de bloqueo circular entre el bloqueo del propietario de la consola y el bloqueo del grupo de trabajadores. Revertir el commit permite que la máquina virtual de Steve se inicie nuevamente. [Obviamente, esto puede provocar que aparezcan nuevamente los mensajes "[TTM] Error en el desalojo del búfer", que fue el motivo de la reversión original. Pero en este punto esto parece preferible a un sistema sin arranque...]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: corrige la fuga de vecino y rtable en smc_ib_find_route() En smc_ib_find_route(), el vecino encontrado por neigh_lookup() y rtable resuelto por ip_route_output_flow() no se liberan ni se colocan antes devolver. Puede causar la fuga de recuento, así que corríjalo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: qibfs: arreglar la fuga de dentry simple_recursive_removal() elimina las referencias de fijación a todos los positivos en el subárbol. Para los casos en los que su argumento se ha mantenido vivo solo mediante la fijación, eso es exactamente lo correcto, pero aquí el argumento proviene de la búsqueda de dcache, que debe equilibrarse con dput() explícito. Jodido por: Al Viro

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/xe/xe_migrate: conversión a precisión de salida antes de multiplicar operandos. Abordar el posible desbordamiento como resultado de la multiplicación de dos operandos de menor precisión (u32) antes de ampliarlo a mayor precisión (u64). -v2 Corregir mensaje de commit y descripción. (Rodrigo) (cereza escogida del commit 34820967ae7b45411f8f4f737c2d63b0c608e0d7)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: amd/amdkfd: sincroniza todos los dispositivos para esperar a que se desalojen todos los procesos. Si hay más de un dispositivo reiniciando en paralelo, el primer dispositivo llamará a kfd_suspend_all_processes() para desalojar todos los procesos en todos los dispositivos, esta llamada tarda un tiempo en finalizar. El otro dispositivo comenzará a restablecerse y recuperarse sin esperar. Si el proceso no ha sido desalojado antes de realizar la recuperación, se restaurará y luego provocará un error de página.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phonet: corrige la asignación de skb de rtm_phonet_notify() fill_route() almacena tres componentes en el skb: - struct rtmsg - RTA_DST (u8) - RTA_OIF (u32) Por lo tanto, rtm_phonet_notify() debería usar NLMSG_ALIGN(tamañode(struct rtmsg)) + nla_total_size(1) + nla_total_size(4)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/qeth: soluciona el pánico del kernel después de configurar hsuid Síntoma: cuando el atributo hsuid se establece por primera vez en un dispositivo IQD Layer3 mientras la interfaz de red correspondiente ya está activa, el kernel Intentará ejecutar un puntero de función napi que sea NULL. Ejemplo: ------------------------------------------------ --------------------- [ 2057.572696] operación ilegal: 0001 ilc:1 [#1] SMP [ 2057.572702] Módulos vinculados en: af_iucv qeth_l3 zfcp scsi_transport_fc sunrpc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_tables_set nft_chain_nat nf_nat pista nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink ghash_s390 prng xts aes_s390 des_s390 de s_generic sha3_512_s390 sha3_256_s390 sha512_s390 vfio_ccw vfio_mdev mdev _iommu_type1 eadm_sch vfio ext4 mbcache jbd2 qeth_l2 puente stp llc dasd_eckd_mod qeth dasd_mod qdio ccwgroup pkey zcrypt [2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: cargado No contaminado 4.18.0-541.el8.s390x #1 [2057.572742] Nombre de hardware: IBM 3931 A01 704 (LPAR) [2057.572744] PSW : 0704f00180000000 0000000000000002 (0x2) [ 2057.572748] R:0 T:1 IO:1 EX:1 Clave:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000 [2057.572754] 00000000a3b008d8 cb923a29c779abc5 000000000000000 00000000814cfd80 [ 2057.572756] 000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8 [ 2057.5727 58] 00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68 [2057.572762] Código Krnl:#0000000000000000: 0000 ilegal >00000000000 00002: 0000 ilegal 0000000000000004: 0000 ilegal 0000000000000006: 0000 ilegal 0000000000000008: 0000 ilegal 000000000000000a: 0000 ilegal 000000000000000c: 0000 ilegal 000000000000000e: 0000 ilegal [ 2057.572800] Rastreo de llamadas: [ 57.572801] ([<00000000ec639700>] 0xec639700) [ 2057.572803] [<00000000913183e2>] net_rx_action+0x2ba/0x398 [ 2057.572809 ] [<0000000091515f76>] __do_softirq+0x11e/0x3a0 [ 2057.572813] [<0000000090ce160c>] do_softirq_own_stack+0x3c/0x58 [ 2057.572817 ([<0000000090d] 2cbd6>] do_softirq.part.1+0x56/0x60) [ 2057.572822] [<0000000090d2cc60> ] __local_bh_enable_ip+0x80/0x98 [ 2057.572825] [<0000000091314706>] __dev_queue_xmit+0x2be/0xd70 [ 2057.572827] [<000003ff803dd6d6>] 24e/0x300 [af_iucv] [ 2057.572830] [<000003ff803dd88a>] iucv_send_ctrl+0x102/0x138 [af_iucv ] [ 2057.572833] [<000003ff803de72a>] iucv_sock_connect+0x37a/0x468 [af_iucv] [ 2057.572835] [<00000000912e7e90>] __sys_connect+0xa0/0xd8 [ 2057.57283 9] [<00000000912e9580>] sys_socketcall+0x228/0x348 [ 2057.572841] [<0000000091514e1a> ] system_call+0x2a6/0x2c8 [ 2057.572843] Última dirección del evento de última hora: [ 2057.572844] [<0000000091317e44>] __napi_poll+0x4c/0x1d8 [ 2057.572846] [ 2057.572847] pánico - no se sincroniza: excepción fatal en la interrupción ----- -------------------------------------------------- ------------------------------------ Análisis: Hay una estructura napi por out_q: tarjeta->qdio .out_qs[i].napi Las funciones napi.poll se configuran durante qeth_open(). Desde la confirmación 1cfef80d4c2b ("s390/qeth: No llamar a dev_close/dev_open (DOWN/UP)") qeth_set_offline()/qeth_set_online() ya no llama a dev_close()/dev_open(). Entonces, si qeth_free_qdio_queues() borró card->qdio.out_qs[i].napi.poll mientras la interfaz de red estaba activa y la tarjeta estaba fuera de línea, no se vuelven a configurar. Reproducción: chzdev -e $devno Layer2=0 ip link set dev $network_interface up echo 0 > /sys/bus/ccw ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: corrige la desreferencia del puntero nulo dentro de spi_sync Si se llama a spi_sync() con la cola no vacía y luego se reutiliza el mismo spi_message, la devolución de llamada completa para el mensaje permanece configurada mientras el el contexto se borra, lo que lleva a una desreferencia del puntero nulo cuando se invoca la devolución de llamada desde spi_finalize_current_message(). Con la función incorporada deshabilitada, la pila de llamadas podría verse así: _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58 complete_with_flags from spi_complete+0x8/0xc spi_complete from spi_finalize_current_message+0xec/0x184 spi_finalize_current_message from spi_transfer_one_message+0x2 a8/0x474 spi_transfer_one_message de __spi_pump_transfer_message+0x104/0x230 __spi_pump_transfer_message de __spi_transfer_message_noqueue+0x30/0xc4 __spi_transfer_message_noqueue de __spi_sync+0x204/0x248 __spi_sync de spi_sync+0x24/0x3c spi_sync de mcp251xfd_regmap_crc_read+0x124/0x28c fd] mcp251xfd_regmap_crc_read [mcp251xfd] de _regmap_raw_read+0xf8/0x154 _regmap_raw_read de _regmap_bus_read+0x44/0x70 _regmap_bus_read de _regmap_read+ 0x60/0xd8 _regmap_read de regmap_read+0x3c/0x5c regmap_read de mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd] mcp251xfd_alloc_can_err_skb [mcp251xfd] de mcp251xfd_irq+0x19 4/0xe70 [mcp251xfd] mcp251xfd_irq [mcp251xfd] de irq_thread_fn+0x1c/0x78 irq_thread_fn de irq_thread+0x118/0x1f4 irq_thread de kthread+0xd8/0xf4 kthread de ret_from_fork+0x14/0x28 Solucione este problema configurando también mensaje->completo en NULL cuando se complete la transferencia.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/cio: asegúrese de que el buf copiado tenga terminación NUL. Actualmente, asignamos un búfer del kernel del tamaño de lbuf y copiamos lbuf del espacio de usuario a ese búfer. Más adelante, usamos scanf en este búfer pero no nos aseguramos de que la cadena termine dentro del búfer, esto puede provocar una lectura OOB cuando usamos scanf. Solucione este problema utilizando memdup_user_nul en su lugar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal/debugfs: evita que se produzca use after free después de la eliminación de cdev. Dado que Thermal_debug_cdev_remove() no se ejecuta bajo cdev->lock, puede ejecutarse en paralelo con Thermal_debug_cdev_state_update() y puede liberar el objeto struct Thermal_debugfs utilizado por este último después de haberlo verificado con NULL. Si eso sucede, Thermal_debug_cdev_state_update() accederá a la memoria que ya ha sido liberada, lo que provocará que el kernel falle. Solucione esto usando cdev->lock en Thermal_debug_cdev_remove() alrededor de la verificación del valor de cdev->debugfs (en caso de que el mismo cdev se elimine al mismo tiempo en dos subprocesos diferentes) y se restablezca a NULL. CC :6.8+ # 6.8+

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ice: asegúrese de que el buf copiado tenga terminación NUL. Actualmente, asignamos un búfer del kernel del tamaño de un conteo y copiamos el conteo de bytes del espacio de usuario a ese búfer. Más adelante, usamos sscanf en este búfer pero no nos aseguramos de que la cadena termine dentro del búfer, esto puede provocar una lectura OOB cuando usamos sscanf. Solucione este problema utilizando memdup_user_nul en lugar de memdup_user.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: efi/unaccepted: toque el bloqueo suave durante la aceptación de la memoria. El commit 50e782a86c98 ("efi/unaccepted: solucione los bloqueos suaves causados por la aceptación de la memoria paralela") ha liberado el bloqueo de giro para que otras CPU puedan usar la memoria. aceptación en paralelo y no activa el bloqueo suave en otras CPU. Sin embargo, el bloqueo suave se mostró de forma intermitente si la memoria del TD invitado es grande y el tiempo de espera del bloqueo suave se establece en 1 segundo: RIP: 0010:_raw_spin_unlock_irqrestore Seguimiento de llamadas:? __hrtimer_run_queues ? hrtimer_interrupt? watchdog_timer_fn? __sysvec_apic_timer_interrupt? __pfx_watchdog_timer_fn? sysvec_apic_timer_interrupt ? __hrtimer_run_queues ? hrtimer_interrupt? asm_sysvec_apic_timer_interrupt? _raw_spin_unlock_irqrestore? __sysvec_apic_timer_interrupt? sysvec_apic_timer_interrupt aceptar_memoria try_to_accept_memory do_huge_pmd_anonymous_page get_page_from_freelist __handle_mm_fault __alloc_pages __folio_alloc? __tdx_hypercall handle_mm_fault vma_alloc_folio do_user_addr_fault do_huge_pmd_anonymous_page exc_page_fault? __do_huge_pmd_anonymous_page asm_exc_page_fault __handle_mm_fault Cuando el irq local está habilitado al final de Accept_memory(), el bloqueo suave detecta que el mecanismo de vigilancia en una sola CPU no ha sido alimentado por un tiempo. Es decir, incluso otras CPU no serán bloqueadas por spinlock, la CPU actual podría apestar con el irq local deshabilitado por un tiempo, lo que perjudica no solo al nmi watchdog sino también al softlockup. Chao Gao señaló que la aceptación de la memoria podría llevar mucho tiempo y hubo un informe similar antes. Por lo tanto, para evitar cualquier detección de softlocup durante esta etapa, proporcione al softlockup una bandera para omitir la verificación del tiempo de espera al final de Accept_memory(), invocando touch_softlockup_watchdog().