Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar tocar datos con puntos de control en get_victim() En el modo de desactivación de CP, hay dos problemas al usar LFS o SSR | Modo AT_SSR para seleccionar a la víctima: 1. LFS está configurado para buscar la sección de origen durante la GC, la víctima no debe tener datos de puntos de control, ya que después de la GC, la sección no se puede liberar para su reutilización. Anteriormente, solo verificábamos los bloques chpt válidos en el segmento actual en lugar de en la sección, lo arreglamos. 2. RSS | AT_SSR está configurado para encontrar un segmento de destino para escrituras que se puede llenar completamente con bloques recién escritos y con puntos de control. Nunca debemos seleccionar dicho segmento; de lo contrario, puede causar pánico o corrupción de datos durante la asignación. El caso potencial se describe a continuación: a) segmento de destino tiene 'n' (n < 512) ckpt bloques válidos b) GC migra 'n' bloques válidos a otro segmento (el segmento todavía está en la lista sucia) c) GC migra '512 - n' bloques al segmento objetivo (el segmento tiene 'n ' cp_vblocks y '512 - n' vblocks) d) Si GC selecciona el segmento de destino mediante el asignador {AT,}SSR, sin embargo, no hay espacio libre en el segmento de destino.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: PCI: endpoint: corrigió la desreferencia del puntero NULL para ->get_features() las operaciones get_features de pci_epc_ops pueden devolver NULL, lo que provoca la desreferencia del puntero NULL en la función pci_epf_test_alloc_space. Agreguemos una verificación del puntero pci_epc_feature en pci_epf_test_bind antes de acceder a él para evitar dicha desreferencia del puntero NULL y devolvamos -ENOTSUPP en caso de que no se encuentre pci_epc_feature. Cuando no se aplica el parche y las funciones de EPC no se implementan en el controlador de la plataforma, vemos el siguiente volcado debido a la desreferencia del puntero NULL del kernel. Rastreo de llamadas: pci_epf_test_bind+0xf4/0x388 pci_epf_bind+0x3c/0x80 pci_epc_epf_link+0xa8/0xcc configfs_symlink+0x1a4/0x48c vfs_symlink+0x104/0x184 do_symlinkat+0x80/0xd4 __arm64_sys _symlinkat+0x1c/0x24 el0_svc_common.constprop.3+0xb8/0x170 el0_svc_handler+0x70 /0x88 el0_svc+0x8/0x640 Código: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) ---[ final de seguimiento a438e3c5a24f9df0 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: 9064/1: hw_breakpoint: no comprobar directamente el gancho overflow_handler del evento. el commit 1879445dfa7b ("perf/core: establecer el valor predeterminado del evento ::overflow_handler()") establece un valor predeterminado event->overflow_handler en perf_event_alloc(), y reemplace check event->overflow_handler con is_default_overflow_handler(), pero falta uno. Actualmente, bp->overflow_handler no puede ser NULL. Como resultado, enable_single_step() no siempre se invoca. Comentarios de Zhen Lei: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige el pánico durante f2fs_resize_fs() f2fs_resize_fs() se bloquea en la pila de llamadas debajo con el caso de prueba: - imagen mkfs de 16 GB y montaje de imagen - dd archivo A de 8 GB - agrega archivo B de 8 GB - sincronización - archivo rm A - sincronización - cambiar el tamaño del sistema de archivos al kernel de 8 GB ¡ERROR en segment.c:2484! Seguimiento de llamadas: allocate_segment_by_default+0x92/0xf0 [f2fs] f2fs_allocate_data_block+0x44b/0x7e0 [f2fs] do_write_page+0x5a/0x110 [f2fs] f2fs_outplace_write_data+0x55/0x100 [f2fs] f2fs_do_write_data_page +0x392/0x850 [f2fs] mover_página_datos+0x233/0x320 [f2fs] ] do_garbage_collect+0x14d9/0x1660 [f2fs] free_segment_range+0x1f7/0x310 [f2fs] f2fs_resize_fs+0x118/0x330 [f2fs] __f2fs_ioctl+0x487/0x3680 [f2fs] __x64_sys_ioct l+0x8e/0xd0 do_syscall_64+0x33/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 La raíz Porque olvidamos verificar si tenemos suficiente espacio en el sistema de archivos redimensionado para almacenar todos los bloques válidos en el sistema de archivos antes de cambiar el tamaño, entonces el asignador se quedará sin espacio durante la migración de bloques en free_segment_range().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: asegúrese de que GHCB esté mapeado antes de actualizar. El acceso al GHCB se encuentra principalmente en la ruta VMGEXIT y se sabe que el GHCB será mapeado. Pero hay dos caminos en los que es posible que el GHCB no esté mapeado. La rutina sev_vcpu_deliver_sipi_vector() actualizará el GHCB para informar a la persona que llama del evento AP Reset Hold NAE que se ha entregado un SIPI. Sin embargo, si se realiza una SIPI sin una retención de reinicio de AP correspondiente, es posible que el GHCB no se asigne (dependiendo del VMEXIT anterior), lo que resultará en una desreferencia del puntero NULL. La rutina svm_complete_emulated_msr() actualizará el GHCB para informar a la persona que llama de una operación RDMSR/WRMSR sobre cualquier error. Si bien es probable que el GHCB se asigne en esta situación, agregue una protección en esta ruta para asegurarse de que no se encuentre una desreferencia de puntero NULL.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: LLAVES: confiable: corrige la pérdida de memoria en el objeto td. Dos rutas de retorno de error no liberan el objeto asignado td, lo que provoca una pérdida de memoria. Solucione este problema regresando a través de la ruta de retorno de error que segura el td. Corrige la advertencia de clang scan-build: seguridad/claves/trusted-keys/trusted_tpm1.c:496:10: advertencia: Posible pérdida de memoria [unix.Malloc]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: solo permite que init netns establezca la cong tcp predeterminada en un algoritmo restringido tcp_set_default_congestion_control() es seguro para netns porque escribe en &net->ipv4.tcp_congestion_control, pero también establece ca->flags |= TCP_CONG_NON_RESTRICTED que no tiene espacio de nombres. Esto tiene el efecto secundario no deseado de cambiar el sistema global net.ipv4.tcp_allowed_congestion_control, a pesar de que es de solo lectura: 97684f0970f6 ("net: Make tcp_allowed_congestion_control readonly in non-init netns") Resuelva esta "fuga" de netns solo permite que las redes de inicio establezcan el algoritmo predeterminado en uno restringido. Esta restricción podría eliminarse si tcp_allowed_congestion_control tuviera un espacio de nombres en el futuro. Este error se descubrió con https://github.com/JonathonReinhart/linux-netns-sysctl-verify

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: memcontrol: slab: fix obtener una referencia a una serie de parches de liberación de memcg "Utilice las API de obj_cgroup para cargar páginas kmem", v5. Desde que se aplicó la serie de Roman "El nuevo controlador de memoria losa de cgroup". Todos los objetos de losa se cargan con las nuevas API de obj_cgroup. Las nuevas API introducen una estructura obj_cgroup para cargar objetos de losa. Evita que los objetos de larga duración fijen el grupo de memoria original en la memoria. Pero todavía hay algunos objetos de esquina (por ejemplo, asignaciones mayores que la página de pedido 1 en SLUB) que no se cargan con las nuevas API. Esos objetos (incluidas las páginas que se asignan directamente desde el asignador de amigos) se cargan como páginas kmem que aún contienen una referencia al grupo de memoria. Por ejemplo, sabemos que la pila del kernel se carga como páginas kmem porque el tamaño de la pila del kernel puede ser mayor que 2 páginas (por ejemplo, 16 KB en x86_64 o arm64). Si creamos un subproceso (supongamos que la pila de subprocesos se carga en el grupo c de memoria A) y luego lo movemos del grupo c de memoria A al grupo c de memoria B. Porque la pila del núcleo del subproceso contiene una referencia al grupo c de memoria A. El hilo puede anclar la memoria cgroup A en la memoria incluso si eliminamos el cgroup A. Si queremos ver este escenario usando el siguiente script. Podemos ver que el sistema ha agregado 500 cgroups moribundos (esto no es un problema del mundo real, solo un script para mostrar que los kmallocs grandes se cargan como páginas kmem que pueden fijar el cgroup de memoria en la memoria). #!/bin/bash cat /proc/cgroups | grep memoria cd /sys/fs/cgroup/memory echo 1 > memoria.move_charge_at_immigrate para i en el rango{1..500} hacer mkdir kmem_test echo $$ > kmem_test/cgroup.procs sleep 3600 & echo $$ > cgroup.procs echo `cat kmem_test/cgroup.procs` > cgroup.procs rmdir kmem_test hecho cat /proc/cgroups | grep memoria Este conjunto de parches tiene como objetivo hacer que esas páginas kmem eliminen la referencia a la memoria cgroup mediante el uso de las API de obj_cgroup. Finalmente, podemos ver que el número de cgroups moribundos no aumentará si ejecutamos el script de prueba anterior. Este parche (de 7): rcu_read_lock/unlock solo puede garantizar que el memcg no se libere, pero no puede garantizar el éxito de css_get (que está en refill_stock cuando se cambia el memcg en caché) a memcg. rcu_read_lock() memcg = obj_cgroup_memcg(old) __memcg_kmem_uncharge(memcg) refill_stock(memcg) if (stock->cached != memcg) // css_get puede cambiar el contador de referencia de 0 a 1. css_get(&memcg->css) rcu_read_unlock( ) Esta solución es muy parecida a el commit: eefbfa7fd678 ("mm: memcg/slab: fix use after free in obj_cgroup_charge") Solucione este problema manteniendo una referencia al memcg que se pasa a __memcg_kmem_uncharge() antes de llamar a __memcg_kmem_uncharge().

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: RDMA/siw: Corrige un use after free en siw_alloc_mr Nuestro analizador de código informó un UAF. En siw_alloc_mr(), llama a siw_mr_add_mem(mr,..). En la implementación de siw_mr_add_mem(), mem se asigna a mr->mem y luego mem se libera mediante kfree(mem) si xa_alloc_ciclic() falla. Aquí, mr->mem todavía apunta a un objeto liberado. Después, la ejecución continúa hasta la rama err_out de siw_alloc_mr, y el mr->mem liberado se usa en siw_mr_drop_mem(mr). Mi parche mueve "mr->mem = mem" detrás de la sección if (xa_alloc_ciclic(..)<0) {}, para evitar el uaf.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:emac/emac-mac: Se corrige un uso after free en emac_mac_tx_buf_send En emac_mac_tx_buf_send, llama a emac_tx_fill_tpd(..,skb,..). Si ocurre algún error en emac_tx_fill_tpd(), el skb se liberará mediante dev_kfree_skb(skb) en la rama de error de emac_tx_fill_tpd(). Pero el skb liberado todavía se usa a través de skb->len por netdev_sent_queue(,skb->len). Como observé que emac_tx_fill_tpd() no ha modificado el valor de skb->len, por lo tanto mi parche asigna skb->len a 'len' antes del posible free y usa 'len' en lugar de skb->len más tarde.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_ct: corrige el acceso salvaje a la memoria al borrar fragmentos mientras se prueba el reensamblaje/refragmentación usando act_ct, es posible observar un bloqueo como el siguiente: KASAN: tal vez acceso a memoria salvaje en el rango [0x0001000000000448-0x000100000000044f] CPU: 50 PID: 0 Comunicaciones: swapper/50 Tainted: GS 5.12.0-rc7+ #424 Nombre de hardware: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01 /17/2017 RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0 Código: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203 RAX: 00 00200000000089 RBX: 000100000000040e RCX: ffffffff989eb960 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e RBP: 0000000000000900 R08: 00000000000000000 R09: ffffed1186289350 R10: 00000000 00000003 R11: ffffed1186289350 R12: dffffc0000000000 R13: 000100000000040e R14: 00000000000000000 R15: ffff888155e02160 FS: 00000000000000000 (0000) GS:ffff888c31440000(0000) knlGS:0000000000000000 CS : 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0 000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 Seguimiento de llamadas: inet_frag_destroy+0xa9/0x150 call_timer_fn +0x2d/0x180 run_timer_softirq+0x4fe/0xe70 __do_softirq+0x197/0x5a0 irq_exit_rcu+0x1de/0x200 sysvec_apic_timer_interrupt+0x6b/0x80 cuando act_ct almacena temporalmente un fragmento de IP, la restauración de skb qdisc cb da como resultado la colocación de datos aleatorios en FR AG_CB() , y esto provoca esos accesos a la memoria "salvajes" más adelante, cuando se purga el rbtree. Nunca sobrescriba el skb cb en caso de que tcf_ct_handle_fragments() devuelva -EINPROGRESS.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bnxt_en: corrige la lógica del índice del consumidor RX en la ruta del error. En bnxt_rx_pkt(), se espera que los buffers RX se completen en orden. Si el índice del consumidor RX indica que el búfer está fuera de servicio, significa que estamos sufriendo un error de hardware y el controlador cancelará todos los paquetes RX restantes y restablecerá el anillo RX. El índice de consumidores RX que pasamos a bnxt_discard_rx() no es correcto. Deberíamos pasar el índice actual (tmp_raw_cons) en lugar del índice anterior (raw_cons). Este error puede hacer que estemos en el índice incorrecto al intentar abortar el siguiente paquete RX. Puede fallar así: #0 [ffff9bbcdf5c39a8] machine_kexec en ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec en ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] pánico en ffffffff9b07d61e #3 [ffff9bbcdf5c3b50 ] oops_end en ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context en ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8 ] __bad_area_nosemaphore en ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore en ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault en ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault en ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault en ffffffff9bc015c5 [excepción RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000000100 0 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018