Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: corrige el formato de compresión por archivo inconsistente EROFS puede seleccionar algoritmos de compresión por archivo, y cada algoritmo de compresión por archivo debe marcarse en el superbloque del disco para la inicialización. Sin embargo, syzkaller puede generar imágenes manipuladas inconsistentes que usan un tipo de algoritmo no compatible para inodos específicos, por ejemplo, usa el tipo de algoritmo MicroLZMA incluso si no está configurado en `sbi->available_compr_algs`. Esto puede provocar un "ERROR: desreferencia del puntero NULL del kernel" inesperado si el descompresor correspondiente no está integrado. Solucione este problema comprobando con `sbi->available_compr_algs` para cada solicitud de m_algorithmformat. El mapa de bits preestablecido !erofs_sb_has_compr_cfgs incorrecto ahora se corrige porque antes era inofensivo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: Se corrigió la rama de re-adjunción en bpf_tracing_prog_attach El siguiente caso puede causar un bloqueo debido a la falta de adjunto_btf: 1) cargar el programa rawtp 2) cargar el programa fentry con rawtp como target_fd 3) crear enlace de seguimiento para el programa fentry con target_fd = 0 4) repetir 3 Al final tenemos: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (porque no proporcionamos target_fd para link_create) - prog->aux ->attach_btf == NULL (el programa se cargó con adjunto_prog_fd=X) - el programa se cargó para tgt_prog pero no tenemos forma de averiguar cuál ERROR: desreferencia del puntero NULL del núcleo, dirección: 0000000000000058 Seguimiento de llamadas: ? __morir+0x20/0x70 ? page_fault_oops+0x15b/0x430? fixup_exception+0x22/0x330? exc_page_fault+0x6f/0x170? asm_exc_page_fault+0x22/0x30? bpf_tracing_prog_attach+0x279/0x560? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 Entry_SYSCALL_64_after_hwframe+0x6e/ 0x76 Devuelve -EINVAL en esta situación.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ksmbd: soluciona problema de UAF en ksmbd_tcp_new_connection() La ejecución es entre el manejo de una nueva conexión TCP y su desconexión. Conduce a UAF en `struct tcp_transport` en la función ksmbd_tcp_new_connection().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: apparmor: evita fallas cuando el nombre del perfil analizado está vacío Al procesar un perfil empaquetado en unpack_profile() descrito como "perfil :ns::samba-dcerpcd /usr/lib*/samba/ {,samba/}samba-dcerpcd {...}" una cadena ":samba-dcerpcd" se descomprime como un nombre completo y luego se pasa a aa_splitn_fqname(). aa_splitn_fqname() trata ":samba-dcerpcd" como si solo contuviera un espacio de nombres. Por lo tanto, devuelve NULL para tmpname, mientras que tmpns no es NULL. Más tarde, aa_alloc_profile() falla porque el nuevo nombre del perfil ahora es NULL. falla de protección general, probablemente para dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en rango [0x00000000000000000-0x0000000000000007] CPU: 6 PID: 1657 Comm: apparmor_parser No contaminado 6.7.0- rc2-dirty #16 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 01/04/2014 RIP: 0010:strlen+0x1e/0xa0 Llamada Seguimiento: ? strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960 aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 Policy_update+0x261/0x370 perfil_replace+ 0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 ---[ end trace 0000000000000000 ]--- RIP: 0010:strlen+0x1e/0xa0 Parece que tal comportamiento de aa_splitn_fqname() se espera y se verifica en otros lugares donde se llama (por ejemplo, aa_remove_profiles). Bueno, hay un comentario explícito "se permite un nombre ns sin un perfil de seguimiento" dentro. AFAICS, nada puede evitar que el "nombre" descomprimido tenga un formato como ":samba-dcerpcd": se pasa desde el espacio de usuario. En tal caso, rechace el reemplazo completo del conjunto de perfiles e informe al usuario con EPROTO y un mensaje explicativo. Encontrado por el Centro de verificación de Linux (linuxtesting.org).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar corrupción directa Como informó Al en link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); demás f2fs_put_page(old_dir_page, 0); Quiere el número correcto en el enlace ".." Y el cambio de nombre entre directorios mueve la fuente al nuevo padre, incluso si le hubieran pedido que dejara un espacio en blanco en el lugar anterior. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ Con el siguiente caso de prueba, puede causar corrupción directa, debido a que no llamó a f2fs_set_link() para actualizar el enlace ".." al nuevo directorio . - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Número de inodo incorrecto [0x4] para '..', el ino padre padre es [0x3] [FSCK] otro corrupto errores [falla]

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.