Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4: evitar un potencial gadget spectre v1 en fib_metrics_match() if (!type) continue; if (type > RTAX_MAX) return false; ... fi_val = fi->fib_metrics->metrics[type - 1]; @type se utiliza como un índice de matriz, debemos evitar la especulación de la CPU o corremos el riesgo de filtrar el contenido de la memoria del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4: evitar un potencial gadget spectre v1 en ip_metrics_convert() if (!type) continue; if (type > RTAX_MAX) return -EINVAL; ... metrics[type - 1] = val; @type se utiliza como un índice de matriz, debemos evitar la especulación de la CPU o el riesgo de filtrar el contenido de la memoria del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fec: Usar page_pool_put_full_page al liberar búferes rx Se usó page_pool_release_page al liberar búferes rx, y esta función solo desasigna la página (si está asignada) y no la recicla. Entonces, después de cientos de subidas y bajadas de eth0, el sistema se quedará sin memoria. Para obtener más detalles, consulte los siguientes pasos de reproducción y los registros de errores. Para resolver este problema y consultar la documentación del grupo de páginas, se debe usar page_pool_put_full_page para reemplazar page_pool_release_page. Porque esta API intentará reciclar la página si la referencia de la página es igual a 1. Después de probar 20000 veces, el problema ya no se puede reproducir (aproximadamente 391 veces que se probó el problema en i.MX8MN-EVK antes). Pasos de reproducción: Cree el script de prueba y ejecútelo. El contenido del script es el siguiente: LOOPS=20000 i=1 while [ $i -le $LOOPS ] do echo "TINFO:ENET $curface up and down test $i times" org_macaddr=$(cat /sys/class/net/eth0/address) ifconfig eth0 down ifconfig eth0 hw ether $org_macaddr up i=$(expr $i + 1) done sleep 5 if cat /sys/class/net/eth0/operstate | grep 'up';then echo "TEST PASS" else echo "TEST FAIL" fi Registros de detalles de errores: TINFO: prueba de ENET activada y desactivada 391 veces [850.471205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: controlador PHY conectado (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [853.535318] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: el enlace está listo [853.541694] fec 30be0000.ethernet eth0: el enlace está activo - 1 Gbps/completo - control de flujo rx/tx [870.590531] page_pool_release_retry() apagado del grupo estancado 199 durante el vuelo 60 s [931.006557] page_pool_release_retry() apagado del grupo detenido 199 durante el vuelo 120 s TINFO:ENET prueba de subida y bajada 392 veces [991.426544] page_pool_release_retry() apagado del grupo detenido 192 durante el vuelo 181 s [1051.838531] page_pool_release_retry() apagado del grupo detenido 170 durante el vuelo 241 s [1093.751217] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: controlador PHY conectado (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [1096.446520] page_pool_release_retry() apagado de grupo estancado 308 en vuelo 60 seg [ 1096.831245] fec 30be0000.ethernet eth0: Enlace activo - 1 Gbps/completo - control de flujo rx/tx [ 1096.839092] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: enlace listo [ 1112.254526] page_pool_release_retry() apagado de grupo estancado 103 en vuelo 302 seg [ 1156.862533] page_pool_release_retry() apagado de grupo estancado 308 en vuelo 120 seg [ 1172.674516] page_pool_release_retry() apagado de grupo estancado 103 en vuelo 362 seg [ 1217.278532] page_pool_release_retry() detuvo el apagado del grupo 308 durante el vuelo 181 s TINFO:ENET prueba de subida y bajada 393 veces [ 1233.086535] page_pool_release_retry() detuvo el apagado del grupo 103 durante el vuelo 422 s [ 1277.698513] page_pool_release_retry() detuvo el apagado del grupo 308 durante el vuelo 241 s [ 1293.502525] page_pool_release_retry() detuvo el apagado del grupo 86 durante el vuelo 483 s [ 1338.110518] page_pool_release_retry() detuvo el apagado del grupo 308 durante el vuelo 302 s [ 1353.918540] page_pool_release_retry() detuvo el apagado del grupo 32 durante el vuelo 543 seg [1361.179205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: controlador PHY conectado (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL) [1364.255298] fec 30be0000.ethernet eth0: el enlace está activo - 1 Gbps/completo - control de flujo rx/tx [1364.263189] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: el enlace está listo [1371.998532] page_pool_release_retry() apagado del grupo detenido 310 en vuelo 60 seg [1398.530542] page_pool_release_retry() apagado del grupo detenido 308 en vuelo 362 seg [1414.334539] page_pool_release_retry() apagado del grupo detenido 16 en vuelo 604 seg [1432.414520] page_pool_release_retry() apagado del grupo ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: evitar posibles gadgets de Spectre v1 La mayoría de los atributos de netlink se analizan y validan desde __nla_validate_parse() o validate_nla() u16 type = nla_type(nla); if (type == 0 || type > maxtype) { /* error or continue */ } @type se usa entonces como un índice de matriz y puede usarse como un gadget de Spectre v1. array_index_nospec() puede usarse para evitar la filtración de contenido de la memoria del kernel a usuarios maliciosos. Esto debería solucionar la gran mayoría de los usos de netlink, pero se necesita una auditoría para encargarse de otros donde la validación aún no está centralizada en las funciones principales de netlink.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/drm_vma_manager: Añadir drm_vma_node_allow_once(). Actualmente, no existe una forma sencilla para que un controlador drm verifique y permita de forma segura drm_vma_offset_node para un archivo drm solo una vez. Se debe permitir que los controladores drm invoquen una versión sin referencia de drm_vma_node_allow() para que el controlador no tenga que registrar cada drm_vma_node_allow() para invocar drm_vma_node_revoke() subsiguiente y así evitar fugas de memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: corrige UaF en la ruta de error de registro de operaciones de netns Si net_assign_generic() falla, la ruta de error actual en ops_init() intenta borrar la ranura del puntero gen. De todas formas, en dicha ruta de error, el puntero gen en sí no se ha modificado aún, y el existente y al que se ha accedido es más pequeño que el índice accedido, lo que provoca un error fuera de los límites: BUG: KASAN: slab-out-of-bounds en ops_init+0x2de/0x320 Escritura de tamaño 8 en la dirección ffff888109124978 por la tarea modprobe/1018 CPU: 2 PID: 1018 Comm: modprobe No contaminado 6.2.0-rc2.mptcp_ae5ac65fbed5+ #1641 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014 Rastreo de llamadas: dump_stack_lvl+0x6a/0x9f print_address_description.constprop.0+0x86/0x2b5 print_report+0x11b/0x1fb kasan_report+0x87/0xc0 ops_init+0x2de/0x320 register_pernet_operations+0x2e4/0x750 register_pernet_subsys+0x24/0x40 tcf_register_action+0x9f/0x560 do_one_initcall+0xf9/0x570 do_init_module+0x190/0x650 load_module+0x1fa5/0x23c0 __do_sys_finit_module+0x10d/0x1b0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f42518f778d Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d cb 56 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007fff96869688 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 00005568ef7f7c90 RCX: 00007f42518f778d RDX: 0000000000000000 RSI: 00005568ef41d796 RDI: 0000000000000003 RBP: 00005568ef41d796 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000 R13: 00005568ef7f7d30 R14: 0000000000040000 R15: 0000000000000000 Este cambio soluciona el problema omitiendo la desreferencia del puntero gen en la ruta de error mencionada. Se detectó mediante inspección de código y se verificó con inyección de error explícita en un kernel con kasan habilitado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: acpi: Fix suspend with Xen PV Commit f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest") omitió una ruta de código que accedía a real_mode_header, lo que provocó la desreferenciación de NULL al suspender el sistema bajo Xen: [348.284004] PM: entrada de suspensión (profunda) [348.289532] Sincronización de sistemas de archivos: 0,005 segundos [348.291545] Congelación de procesos de espacio de usuario... (transcurridos 0,000 segundos) hecho. [348.292457] OOM killer deshabilitado. [348.292462] Congelación de tareas congelables restantes... (transcurridos 0,104 segundos) hecho. [ 348.396612] printk: Suspendiendo consola(s) (use no_console_suspend para depurar) [ 348.749228] PM: suspender dispositivos tomó 0.352 segundos [ 348.769713] ACPI: EC: interrupción bloqueada [ 348.816077] ERROR: desreferencia de puntero NULL del kernel, dirección: 000000000000001c [ 348.816080] #PF: acceso de lectura del supervisor en modo kernel [ 348.816081] #PF: error_code(0x0000) - página no presente [ 348.816083] PGD 0 P4D 0 [ 348.816086] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep No contaminado 6.1.3-1.fc32.qubes.x86_64 #1 [ 348.816092] Nombre del hardware: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022 [ 348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20 Corrija esto agregando una devolución de llamada acpi opcional que permita omitir la configuración de la dirección de activación, ya que en el caso de Xen PV esto lo manejará el hipervisor de todos modos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda/via: Evitar una posible matriz fuera de los límites en add_secret_dac_path(). snd_hda_get_connections() puede devolver un código de error negativo. Esto puede provocar el acceso a la matriz 'conn' con un índice negativo. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firewire: corrección de fuga de memoria para el payload de la subacción de solicitud a la región FCP IEC 61883-1. Este parche es una corrección para el kernel de Linux v2.6.33 o posterior. Para la subacción de solicitud a la región FCP IEC 61883-1, el subsistema FireWire de Linux ha tenido un problema de use-after-free. El subsistema permite que varios oyentes del espacio de usuario accedan a la región, mientras que los datos de el payload probablemente se liberaron antes de que los oyentes ejecutaran read(2) para acceder a ellos para copiarlos al espacio de usuario. El problema se solucionó mediante un commit 281e20323ab7 ("firewire: core: corrección de la regresión de use-after-free en el controlador FCP"). El objeto de el payload se duplica en el espacio del kernel para cada oyente. Cuando el oyente ejecuta ioctl(2) con la solicitud FW_CDEV_IOC_SEND_RESPONSE, el objeto se liberará. Sin embargo, esto causa una fuga de memoria, ya que el commit depende de la llamada a release_request() en drivers/firewire/core-cdev.c. Contrariamente a lo esperado, la función nunca se llama debido al diseño de release_client_resource(). La función delega la tarea de liberación al llamador cuando se llama con un cuarto argumento distinto de NULL. La implementación de ioctl_send_response() es la correcta. Debería liberar el objeto explícitamente. Esta confirmación corrige el error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390: workaround para advertencia de lectura fuera de los límites de gcc-11 no válida GCC 11.1.0 y 11.2.0 generan una advertencia errónea al compilar el kernel, por ejemplo, con allmodconfig: arch/s390/kernel/setup.c: En la función 'setup_lowcore_dat_on': ./include/linux/fortify-string.h:57:33: error: '__builtin_memcpy' leyendo 128 bytes de una región de tamaño 0 [-Werror=stringop-overread] ... arch/s390/kernel/setup.c:526:9: nota: en la expansión de la macro 'memcpy' 526 | memcpy(abs_lc->cregs_save_area, S390_lowcore.cregs_save_area, | ^~~~~~ Esto se podría solucionar usando absolute_pointer() con la macro S390_lowcore, pero no es una buena idea ya que genera un código peor para las rutas críticas de rendimiento. Por lo tanto, simplemente use un bucle for para copiar la matriz en cuestión y deshacerse de la advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Omitir tarea con pid=1 en send_signal_common() El siguiente pánico del kernel se puede activar cuando una tarea con pid=1 adjunta un programa que intenta enviarse una señal de eliminación a sí mismo, consulte también [1] para obtener más detalles: Pánico del kernel - no sincroniza: ¡Intento de eliminar init! exitcode=0x0000000b CPU: 3 PID: 1 Comm: systemd No contaminado 6.1.0-09652-g59fe41b5255f #148 Rastreo de llamadas: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106 panic+0x2c4/0x60f kernel/panic.c:275 do_exit.cold+0x63/0xe4 kernel/exit.c:789 do_group_exit+0xd4/0x2a0 kernel/exit.c:950 get_signal+0x2460/0x2600 kernel/signal.c:2858 arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296 do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd So skip task with pid=1 in bpf_send_signal_common() para evitar el pánico. [1] https://lore.kernel.org/bpf/20221222043507.33037-1-sunhao.th@gmail.com

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/i8259: Marcar interrupciones PIC heredadas con IRQ_LEVEL. Baoquan informó que, tras desencadenar un fallo, el kernel posterior al fallo no arranca aproximadamente la mitad de las veces. Esto desencadena una desreferencia de puntero NULL en el código de tick periódico. Esto sucede porque la interrupción del temporizador heredada (IRQ0) se reenvía por software, lo que ocurre en el contexto de una interrupción suave (tasklet). En este contexto, get_irq_regs() devuelve NULL, lo que provoca la desreferencia de puntero NULL. El motivo del reenvío es una interrupción APIC espuria en el vector IRQ0, que se captura y provoca un reenvío cuando se habilita la interrupción del temporizador heredada. Esto es incorrecto porque las interrupciones PIC heredadas se activan por nivel y, por lo tanto, nunca deberían reenviarse por software; sin embargo, nada activa el indicador IRQ_LEVEL en esas interrupciones, por lo que el código principal desconoce su tipo de activación. Asegúrese de que IRQ_LEVEL esté activado al configurar las interrupciones PCI heredadas.