Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: pvrusb2: corrige el use after free de desconexión de contexto. Al cargar el módulo, se crea un kthread dirigido a la función pvr2_context_thread_func, que puede llamar a pvr2_context_destroy y, por lo tanto, llamar a kfree() en el objeto de contexto. Sin embargo, eso podría suceder antes de que el controlador usb hub_event pueda notificar al controlador. Este parche agrega una verificación de cordura antes de la lectura no válida reportada por syzbot, dentro de la pila de llamadas de desconexión de contexto.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige una condición de ejecución entre btf_put() y map_free() Al ejecutar `./test_progs -j` en mi máquina virtual local con el último kernel, una vez encontré un error kasan como a continuación: [ 1887.184724] ERROR: KASAN: slab-use-after-free en bpf_rb_root_free+0x1f8/0x2b0 [ 1887.185599] Lectura del tamaño 4 en la dirección ffff888106806910 por tarea kworker/u12:2/2830 [ 1887.186498] [ 1887.186712] CPU: 3 PID: 2830 Comm: kworker/u12:2 Contaminado: G OEL 6.7.0-rc3-00699-g90679706d486-dirty #494 [1887.188034] Nombre de hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0 -0-g155821a1990b-prebuilt.qemu.org 01/04/2014 [1887.189618] Cola de trabajo: events_unbound bpf_map_free_deferred [1887.190341] Seguimiento de llamadas: [1887.190666] [1887.190949] dump_stack_lv l+0xac/0xe0 [ 1887.191423] ? nf_tcp_handle_invalid+0x1b0/0x1b0 [1887.192019]? pánico+0x3c0/0x3c0 [ 1887.192449] print_report+0x14f/0x720 [ 1887.192930] ? preempt_count_sub+0x1c/0xd0 [1887.193459]? __virt_addr_valid+0xac/0x120 [1887.194004]? bpf_rb_root_free+0x1f8/0x2b0 [ 1887.194572] kasan_report+0xc3/0x100 [ 1887.195085] ? bpf_rb_root_free+0x1f8/0x2b0 [ 1887.195668] bpf_rb_root_free+0x1f8/0x2b0 [ 1887.196183] ? __bpf_obj_drop_impl+0xb0/0xb0 [1887.196736]? preempt_count_sub+0x1c/0xd0 [1887.197270]? preempt_count_sub+0x1c/0xd0 [1887.197802]? _raw_spin_unlock+0x1f/0x40 [ 1887.198319] bpf_obj_free_fields+0x1d4/0x260 [ 1887.198883] array_map_free+0x1a3/0x260 [ 1887.199380] bpf_map_free_deferred+0x7b/0xe0 [ 18 87.199943] Process_scheduled_works+0x3a2/0x6c0 [1887.200549] trabajador_thread+0x633/0x890 [1887.201047]? __kthread_parkme+0xd7/0xf0 [ 1887.201574] ? kthread+0x102/0x1d0 [ 1887.202020] kthread+0x1ab/0x1d0 [ 1887.202447] ? pr_cont_work+0x270/0x270 [1887.202954]? kthread_blkcg+0x50/0x50 [ 1887.203444] ret_from_fork+0x34/0x50 [ 1887.203914] ? kthread_blkcg+0x50/0x50 [ 1887.204397] ret_from_fork_asm+0x11/0x20 [ 1887.204913] [ 1887.204913] [ 1887.205209] [ 1887.205416] Asignado por tarea 2197: [1887.205881] kasan_set_track+0x3f/0x60 [1887.206366] __kasan_kmalloc +0x6e/0x80 [ 1887.206856] __kmalloc+0xac/0x1a0 [ 1887.207293] btf_parse_fields+0xa15/0x1480 [ 1887.207836] btf_parse_struct_metas+0x566/0x670 [ 1887.208387 ] btf_new_fd+0x294/0x4d0 [ 1887.208851] __sys_bpf+0x4ba/0x600 [ 1887.209292] __x64_sys_bpf+0x41 /0x50 [ 1887.209762] do_syscall_64+0x4c/0xf0 [ 1887.210222] Entry_SYSCALL_64_after_hwframe+0x63/0x6b [ 1887.210868] [ 1887.211074] Liberado por la tarea 36: [ 1887.21146 0] kasan_set_track+0x3f/0x60 [ 1887.211951] kasan_save_free_info+0x28/0x40 [ 1887.212485] ____kasan_slab_free+ 0x101/0x180 [ 1887.213027] __kmem_cache_free+0xe4/0x210 [ 1887.213514] btf_free+0x5b/0x130 [ 1887.213918] rcu_core+0x638/0xcc0 [ 1887.214347] __do_ softirq+0x114/0x37e El error ocurre en bpf_rb_root_free+0x1f8/0x2b0: 00000000000034c0 : ; { 34c0: f3 0f 1e fa endbr64 34c4: e8 00 00 00 00 callq 0x34c9 34c9: 55 pushq %rbp 34ca: 48 89 e5 movq %rsp, %rbp ... ; if (rec && rec->refcount_off >= 0 && 36aa: 4d 85 ed testq %r13, %r13 36ad: 74 a9 je 0x3658 36af: 49 8d 7d 10 leaq 0x10(%r13), %rdi 36b3 : e8 00 00 00 00 callq 0x36b8 <==== función kasan 36b8: 45 8b 7d 10 movl 0x10(%r13), %r15d <==== carga de uso después de liberación 36bc: 45 85 ff testl %r15d, %r15d 36bf: 78 8c js 0x364d Entonces el problema ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: posponer la liberación del mapa interno cuando sea necesario Al actualizar o eliminar un mapa interno en la matriz de mapas o en el htab de mapas, aún se puede acceder al mapa mediante un programa que no se puede dormir o un programa que se puede dormir. . Sin embargo, bpf_map_fd_put_ptr() disminuye el contador de referencias del mapa interno directamente a través de bpf_map_put(), si el contador de referencias es el último (lo cual es cierto en la mayoría de los casos), el mapa interno será liberado por ops->map_free() en un kworker. Pero por ahora, la mayoría de las devoluciones de llamada .map_free() no usan sincronizar_rcu() o sus variantes para esperar a que transcurra el período de gracia de RCU, por lo que después de que se completa la invocación de ops->map_free, el programa bpf que accede al interior El mapa puede sufrir un problema de uso después de su liberación. Corrija la liberación del mapa interno invocando bpf_map_free_deferred() después de un período de gracia de RCU y un período de gracia de seguimiento de tareas de RCU si el mapa interno se eliminó del mapa externo antes. El aplazamiento se logra utilizando call_rcu() o call_rcu_tasks_trace() al liberar el último contador de referencia del mapa bpf. El campo rcu_head recién agregado en bpf_map comparte el mismo espacio de almacenamiento con el campo de trabajo para reducir el tamaño de bpf_map.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: Se corrigió la desreferencia del puntero NULL del kernel en gfs2_rgrp_dump Syzkaller ha informado una desreferencia del puntero NULL al acceder a rgd->rd_rgl en gfs2_rgrp_dump(). Esto puede suceder cuando la creación de rgd->rd_gl falla en read_rindex_entry(). Agregue una verificación de puntero NULL en gfs2_rgrp_dump() para evitarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: corrige la desreferencia del puntero NULL de Gluebi causada por el notificador ftl. Si se cargan tanto ftl.ko como pegamentobi.ko, el notificador de ftl activa la desreferencia del puntero NULL al intentar acceder a 'gluebi-. >desc' en pegamentobi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all pegamentobi_notify nb->notifier_call() pegamentobi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std pegamentobi_read mtd->read() pegamentobi->desc - NULL Información detallada de reproducción disponible en el enlace [1], en el caso normal, obtenga pegamentobi->desc en pegamentobi_get_device() y acceda a pegamentobi->desc en pegamentobi_read(). Sin embargo, pegamentobi_get_device() no se ejecuta de antemano en el proceso ftl_add_mtd(), lo que conduce a la desreferencia del puntero NULL. La solución para el módulo pegamentobi es ejecutar jffs2 en el volumen UBI sin considerar trabajar con ftl o mtdblock [2]. Por lo tanto, este problema se puede evitar evitando que pegamentobi cree el dispositivo mtdblock después de crear la partición mtd del tipo MTD_UBIVOLUME.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf/x86/intel/uncore: solucione el problema de desreferencia del puntero NULL en upi_fill_topology(). Obtenga la identificación del socket lógico en lugar de la identificación física en discover_upi_topology() para evitar el acceso fuera de límites en 'upi = &tipo->topología[nid][idx];' línea que conduce a la desreferencia del puntero NULL en upi_fill_topology()

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/pseries/memhp: corrige el acceso más allá del final de la matriz drmem dlpar_memory_remove_by_index() puede acceder más allá de los límites de la matriz lmb drmem cuando la búsqueda de LMB no coincide con una entrada con el valor dado Índice de la República Democrática del Congo. Cuando la búsqueda falla, el cursor queda apuntando a &drmem_info->lmbs[drmem_info->n_lmbs], que es un elemento después de la última entrada válida en la matriz. El mensaje de depuración al final de la función elimina la referencia a este puntero: pr_debug("Error al eliminar memoria en caliente en %llx\n", lmb->base_addr); Esto se encontró mediante inspección y se confirmó con KASAN: pseries-hotplug-mem: Intentando eliminar LMB en caliente, índice drc 1234 ========================== ========================================== ERROR: KASAN: losa- fuera de límites en dlpar_memory+0x298/0x1658 Lectura de tamaño 8 en la dirección c000000364e97fd0 por tarea bash/949 dump_stack_lvl+0xa4/0xfc (no confiable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/ 0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog +0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Asignado por tarea 1: kasan_save_stack +0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one _initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+ 0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c La dirección con errores pertenece al objeto en c000000364e80000 que pertenece al caché kmalloc-128k de tamaño 131072 La dirección con errores se encuentra 0 bytes a la derecha de la región asignada de 98256 bytes [c000000364e80000, c0 00000364e97fd0) = ==================================================== =============== pseries-hotplug-mem: No se pudo eliminar la memoria en caliente en 0 Registre las búsquedas fallidas con un mensaje separado y elimine la referencia del cursor solo cuando apunte a una entrada válida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige los accesos a las ranuras de la pila uninit. Se supone que los programas privilegiados pueden leer la memoria de la pila no inicializada (desde 6715df8d5) pero, antes de este parche, estos accesos se permitían de forma inconsistente. En particular, se permitían accesos por encima de state->allocated_stack, pero no por debajo de él. En otras palabras, si la pila ya era "lo suficientemente grande", se permitía el acceso, pero en caso contrario se rechazaba el acceso en lugar de permitir "hacer crecer la pila". Este rechazo no deseado ocurría en dos lugares: - en check_stack_slot_within_bounds() - en check_stack_range_initialized() Este parche dispone que estos accesos sean permitidos. Un montón de pruebas que dependían del antiguo rechazo tuvieron que cambiar; todos ellos se cambiaron para agregar que también se ejecutan sin privilegios, en cuyo caso el comportamiento anterior persiste. Una prueba no se pudo actualizar (global_func16) porque no se puede ejecutar sin privilegios por otros motivos. Este parche también corrige el seguimiento del tamaño de la pila para lecturas con desplazamiento variable. Esta segunda solución se incluye en la misma confirmación que la primera porque están interrelacionadas. Antes de este parche, las escrituras en la pila usando registros que contenían un desplazamiento variable (a diferencia de registros con valores fijos y conocidos) no contribuían adecuadamente al tamaño de pila necesario de la función. Como resultado, era posible que un programa verificara, pero luego intentara leer datos fuera de límites en tiempo de ejecución porque se le había asignado una pila demasiado pequeña. Cada función rastrea el tamaño de la pila que necesita en bpf_subprog_info.stack_ Depth, que es mantenido por update_stack_ Depth(). Para accesos regulares a la memoria, check_mem_access() estaba llamando a update_state_ Depth() pero pasaba solo la parte fija del registro de compensación, ignorando la variable compensación. Esto era incorrecto; en su lugar se debe utilizar el valor mínimo posible de ese registro. Este seguimiento ahora se soluciona centralizando el seguimiento del tamaño de la pila en grow_stack_state() y elevando las llamadas a grow_stack_state() a check_stack_access_within_bounds() como lo sugiere Andrii. El código ahora es más simple y rastrea de manera más convincente el tamaño máximo de pila correcto. check_stack_range_initialized() ahora puede confiar en que se haya asignado suficiente pila para el acceso; esto ayuda con la solución del primer problema. Se cambiaron algunas pruebas para verificar también el cálculo de la profundidad de la pila. El que falla sin este parche es verifier_var_off:stack_write_priv_vs_unpriv.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: corrige la corrupción de la pila Cuando los filtros tc se agregan por primera vez a un dispositivo de red, el puerto local correspondiente se vincula a un grupo ACL en el dispositivo. El grupo contiene una lista de ACL. A su vez, cada ACL apunta a una región TCAM diferente donde se almacenan los filtros. Durante el reenvío, las ACL se evalúan secuencialmente hasta que se encuentra una coincidencia. Una razón para colocar filtros en diferentes regiones es cuando se agregan con prioridades decrecientes y en orden alterno, de modo que dos filtros consecutivos nunca puedan caber en la misma región debido a su uso clave. En Spectrum-2 y ASIC más nuevos, el firmware comenzó a informar que la cantidad máxima de ACL en un grupo es superior a 16, pero el diseño del registro que configura los grupos de ACL (PAGT) no se actualizó para tener en cuenta eso. Por lo tanto, es posible sufrir daños en la pila [1] en el raro caso de que se requieran más de 16 ACL en un grupo. Se soluciona limitando el tamaño máximo del grupo de ACL al mínimo entre lo que informa el firmware y las ACL máximas que caben en el registro PAGT. Agregue un caso de prueba para asegurarse de que la máquina no falle cuando se cumpla esta condición. [1] Pánico del kernel - no se sincroniza: stack-protector: La pila del kernel está dañada en: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 pánico+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+ 0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach +0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb _add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb +0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x 40/0xe0 entrada_SYSCALL_64_after_hwframe+0x63/0x6b

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: netdevsim: no intente destruir PHC en VF PHC se inicializa en nsim_init_netdevsim(), que sólo se llama si (nsim_dev_port_is_pf()). Cree una contraparte de nsim_init_netdevsim() y mueva el mock_phc_destroy() allí. Esto soluciona un fallo al intentar destruir netdevsim con VF instanciados, detectado al ejecutar la prueba devlink.sh: ERROR: desreferencia del puntero NULL del núcleo, dirección: 00000000000000b8 RIP: 0010:mock_phc_destroy+0xd/0x30 Seguimiento de llamadas: nsim_destroy+0x4a /0x70 [netdevsim] __nsim_dev_port_del+0x47/0x70 [netdevsim] nsim_dev_reload_destroy+0x105/0x120 [netdevsim] nsim_drv_remove+0x2f/0xb0 [netdevsim] dispositivo_release_driver_internal+0x1a1/0x210 bus_remove_device+0xd5/0x120 dispositivo_del+0x159/0x490 dispositivo_unregister+0x12/0x30 del_device_store +0x11a/0x1a0 [netdevsim] kernfs_fop_write_iter+0x130/0x1d0 vfs_write+0x30b/0x4b0 ksys_write+0x69/0xf0 do_syscall_64+0xcc/0x1e0 Entry_SYSCALL_64_after_hwframe+0x6f/0x77

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: LoongArch: BPF: evita el acceso a la memoria fuera de los límites La prueba test_tag desencadena un error de página no controlada: # ./test_tag [130.640218] CPU 0 No se puede manejar la solicitud de paginación del kernel en virtual dirección ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70 [ 130.640501] Ups[#3]: [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Contaminado: GDO 6.7.0-rc4 -loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [130.640764] Nombre de hardware: QEMU QEMU Máquina virtual, BIOS desconocido 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 13 0.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000 f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 00000000000000000 t1 00000000000007f6 t2 00000000000000000 t3 9000000004091b70 [ 130.641387] t4 00 0000006ba210be t5 0000000000000004 t6 ffffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 00000000000000005 u0 0000000000000dc0 s9 000000000 0000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 00000000000000095 s4 0000000000000000 [ 130.6 41771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988 [ 130.642007] ERA: 9 000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE ) [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EssubCode=0) [ 130.642658] BADV: ffff80001b898004 [ 130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 1 30.642815] Módulos vinculados en: [última descarga : bpf_testmod(O)] [130.642924] Procesar test_tag (pid: 1326, threadinfo=00000000f7f4015f, tarea=000000006499f9fd) [130.643062] Pila: 0000000000000000 900000000338072 4 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [ 130.643378] 0 000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 00000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 00000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 00000000000000 000 [ 130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 0 00007ffffb917790 90000000032acfb0 [ 130.644572] . .. [ 130.644629] Seguimiento de llamadas: [ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec [ 1 30.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [ 130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b838 8>] sys_bpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [ 130.645507] [ 130.645539] Código: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014 cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[ final de seguimiento 0000000000000000 ]--- En mi máquina, que tiene CONFIG_PAGE_SIZE_16KB=y, la prueba falló al cargar un programa BPF con 2039 instrucciones: prog = (struct bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncado---

La implementación de PEAP en wpa_supplicant hasta la versión 2.10 permite omitir la autenticación. Para un ataque exitoso, se debe configurar wpa_supplicant para no verificar el certificado TLS de la red durante la autenticación de la Fase 1, y luego se puede abusar de una vulnerabilidad eap_peap_decrypt para omitir la autenticación de la Fase 2. El vector de ataque envía un paquete de éxito EAP-TLV en lugar de iniciar la Fase 2. Esto permite a un adversario hacerse pasar por redes Wi-Fi empresariales.