Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> parisc: No reprogramar la afinidad en el chip ASP<br /> <br /> El chip ASP es una variante muy antigua del chip GSP y se usa, por ejemplo, en estaciones de trabajo HP 730. Al intentar reprogramar la afinidad, se bloqueará con un HPMC ya que los registros relevantes no parecen estar en la ubicación habitual. Evitemos el bloqueo comprobando la sversion. También hay que tener en cuenta que la reprogramación tampoco es necesaria, ya que la HP730 es solo una máquina de una sola CPU.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iommufd/selftest: Verificar desbordamiento en IOMMU_TEST_OP_ADD_RESERVED<br /> <br /> syzkaller encontró que podría desbordar operaciones matemáticas en la infraestructura de prueba y causar un WARN_ON al corromper el árbol de intervalos reservados. Esto solo afecta a los kernels de prueba con CONFIG_IOMMUFD_TEST.<br /> <br /> Validar la longitud de la entrada del usuario en el ioctl de prueba.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm/slub: restablecer la etiqueta KASAN en defer_free() antes de acceder a la memoria liberada<br /> <br /> Cuando CONFIG_SLUB_TINY está habilitado, kfree_nolock() llama a kasan_slab_free() antes de defer_free(). En ARM64 con MTE (Extensión de Etiquetado de Memoria), kasan_slab_free() envenena la memoria y cambia la etiqueta de la original (p. ej., 0xf3) a una etiqueta de envenenamiento (0xfe).<br /> <br /> Cuando defer_free() intenta escribir en el objeto liberado para construir la lista de liberación diferida a través de llist_add(), el puntero todavía tiene la etiqueta antigua, causando una falta de coincidencia de etiquetas y desencadenando un informe KASAN de uso después de liberación:<br /> <br /> ERROR: KASAN: uso después de liberación de slab en defer_free+0x3c/0xbc mm/slub.c:6537<br /> Escritura en la dirección f3f000000854f020 por la tarea kworker/u8:6/983<br /> Etiqueta del puntero: [f3], etiqueta de memoria: [fe]<br /> <br /> Solucionar esto llamando a kasan_reset_tag() antes de acceder a la memoria liberada. Esto es seguro porque defer_free() es parte del propio asignador y se espera que manipule la memoria liberada para fines de contabilidad.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> hwmon: (w83791d) Convertir macros a funciones para evitar TOCTOU<br /> <br /> La macro FAN_FROM_REG evalúa sus argumentos múltiples veces. Cuando se usa en contextos sin bloqueo que involucran datos de controlador compartidos, esto lleva a condiciones de carrera de Tiempo de Verificación a Tiempo de Uso (TOCTOU), potencialmente causando errores de división por cero.<br /> <br /> Convertir la macro a una función estática. Esto garantiza que los argumentos se evalúen solo una vez (paso por valor), previniendo las condiciones de carrera.<br /> <br /> Además, en store_fan_div, mover el cálculo del límite mínimo dentro del bloqueo de actualización. Esto asegura que la secuencia de lectura-modificación-escritura opere con datos consistentes.<br /> <br /> Adherirse al principio de cambios mínimos al convertir solo macros que evalúan argumentos múltiples veces y se usan en contextos sin bloqueo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: hns3: añadir validación de ID de VLAN antes de usar<br /> <br /> Actualmente, el ID de VLAN puede ser usado sin validación cuando se recibe un buzón de configuración de VLAN desde VF. La longitud de vlan_del_fail_bmap es BITS_TO_LONGS(VLAN_N_VID). Puede causar acceso a memoria fuera de límites una vez que el ID de VLAN es mayor o igual que VLAN_N_VID.<br /> <br /> Por lo tanto, el ID de VLAN necesita ser verificado para asegurar que está dentro del rango de VLAN_N_VID.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> crypto: af_alg - inicializar a cero la memoria asignada a través de sock_kmalloc<br /> <br /> Varios contextos y solicitudes de API de usuario de criptografía asignados con sock_kmalloc() quedaron sin inicializar, dependiendo de que los llamadores establecieran los campos explícitamente. Esto resultó en el uso de datos no inicializados en ciertas rutas de error o cuando se añadan nuevos campos en el futuro.<br /> <br /> Los parches ACVP también contienen dos archivos de interfaz de espacio de usuario: algif_kpp.c y algif_akcipher.c. Estos también dependen de la inicialización adecuada de sus estructuras de contexto.<br /> <br /> Se ha observado un problema particular con la variable &amp;#39;inflight&amp;#39; recién añadida introducida en af_alg_ctx por el commit:<br /> <br /> 67b164a871af (&amp;#39;crypto: af_alg - Disallow multiple in-flight AIO requests&amp;#39;)<br /> <br /> Debido a que el contexto no se inicializa a cero con memset después de la asignación, la variable inflight ha contenido valores basura. Como resultado, af_alg_alloc_areq() ha devuelto incorrectamente -EBUSY de forma aleatoria cuando el valor basura fue interpretado como verdadero:<br /> <br /> https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209<br /> <br /> La comprobación prueba directamente ctx-&amp;gt;inflight sin comparar explícitamente con verdadero/falso. Dado que inflight solo se establece como verdadero o falso más tarde, un valor no inicializado ha provocado fallos -EBUSY. La inicialización a cero de la memoria asignada con sock_kmalloc() asegura que inflight y otros campos comiencen en un estado conocido, eliminando problemas aleatorios causados por datos no inicializados.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scs: corrige un parámetro incorrecto en __scs_magic<br /> <br /> __scs_magic() necesita una variable &amp;#39;void *&amp;#39;, pero se le da una &amp;#39;struct task_struct *&amp;#39;. &amp;#39;task_scs(tsk)&amp;#39; es la dirección de inicio de la pila de llamadas en sombra de la tarea, y &amp;#39;__scs_magic(task_scs(tsk))&amp;#39; es la dirección final de la pila de llamadas en sombra de la tarea. Aquí debería ser &amp;#39;__scs_magic(task_scs(tsk))&amp;#39;.<br /> <br /> El efecto visible para el usuario de este error es que cuando CONFIG_DEBUG_STACK_USAGE está habilitado, la función de comprobación de uso de la pila de llamadas en sombra (scs_check_usage) escanearía un rango de memoria incorrecto. Esto podría llevar a<br /> <br /> 1. Informes de uso de pila inexactos: La función calcularía estadísticas de uso incorrectas para la pila de llamadas en sombra, potencialmente mostrando un valor incorrecto en kmsg.<br /> <br /> 2. Posible caída del kernel: Si el valor de __scs_magic(tsk) es mayor que el de __scs_magic(task_scs(tsk)), el bucle for podría acceder a memoria no mapeada, potencialmente causando un pánico del kernel. Sin embargo, este escenario es poco probable porque task_struct se asigna a través del asignador slab (que típicamente devuelve direcciones más bajas), mientras que la pila de llamadas en sombra devuelta por task_scs(tsk) se asigna a través de vmalloc (que típicamente devuelve direcciones más altas).<br /> <br /> Sin embargo, dado que esta es puramente una característica de depuración (CONFIG_DEBUG_STACK_USAGE), los sistemas de producción normales no deberían verse afectados. El error solo afecta a desarrolladores y probadores que están depurando activamente el uso de la pila con esta configuración habilitada.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/msm: adreno: corregir la desreferenciación de ifpc_reglist cuando no está declarada<br /> <br /> En plataformas con una GPU a7xx que no soportan IFPC, la ifpc_reglist aún es desreferenciada en a7xx_patch_pwrup_reglist() lo que causa una caída del kernel:<br /> No se puede manejar la desreferenciación de puntero NULL del kernel en la dirección virtual 0000000000000008<br /> ...<br /> pc : a6xx_hw_init+0x155c/0x1e4c [msm]<br /> lr : a6xx_hw_init+0x9a8/0x1e4c [msm]<br /> ...<br /> Traza de llamada:<br /> a6xx_hw_init+0x155c/0x1e4c [msm] (P)<br /> msm_gpu_hw_init+0x58/0x88 [msm]<br /> adreno_load_gpu+0x94/0x1fc [msm]<br /> msm_open+0xe4/0xf4 [msm]<br /> drm_file_alloc+0x1a0/0x2e4 [drm]<br /> drm_client_init+0x7c/0x104 [drm]<br /> drm_fbdev_client_setup+0x94/0xcf0 [drm_client_lib]<br /> drm_client_setup+0xb4/0xd8 [drm_client_lib]<br /> msm_drm_kms_post_init+0x2c/0x3c [msm]<br /> msm_drm_init+0x1a4/0x228 [msm]<br /> msm_drm_bind+0x30/0x3c [msm]<br /> ...<br /> <br /> Verificar la validez de ifpc_reglist antes de desreferenciar la tabla para configurar los valores del registro.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/688944/

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> f2fs: usar inline_xattr_slab global en lugar de caché de slab por sb<br /> <br /> Como Hong Yun informó en la lista de correo:<br /> <br /> loop7: capacidad detectada cambió de 0 a 131072<br /> ------------[ cortar aquí ]------------<br /> kmem_cache de nombre &amp;#39;f2fs_xattr_entry-7:7&amp;#39; ya existe<br /> Advertencia: CPU: 0 PID: 24426 en mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline]<br /> Advertencia: CPU: 0 PID: 24426 en mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307<br /> CPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 No contaminado 6.17.0-rc4 #1 PREEMPT(full)<br /> Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline]<br /> RIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307<br /> Traza de llamada:<br /> &amp;#xa0;__kmem_cache_create include/linux/slab.h:353 [inline]<br /> &amp;#xa0;f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline]<br /> &amp;#xa0;f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843<br /> &amp;#xa0;f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918<br /> &amp;#xa0;get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692<br /> &amp;#xa0;vfs_get_tree+0x43/0x140 fs/super.c:1815<br /> &amp;#xa0;do_new_mount+0x201/0x550 fs/namespace.c:3808<br /> &amp;#xa0;do_mount fs/namespace.c:4136 [inline]<br /> &amp;#xa0;__do_sys_mount fs/namespace.c:4347 [inline]<br /> &amp;#xa0;__se_sys_mount+0x298/0x2f0 fs/namespace.c:4324<br /> &amp;#xa0;do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> &amp;#xa0;do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94<br /> &amp;#xa0;entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> El error puede ser reproducido con los siguientes scripts:<br /> - mount /dev/vdb /mnt1<br /> - mount /dev/vdc /mnt2<br /> - umount /mnt1<br /> - mounnt /dev/vdb /mnt1<br /> <br /> La razón es si creamos dos cachés de slab, llamadas f2fs_xattr_entry-7:3 y f2fs_xattr_entry-7:7, y tienen el mismo tamaño de slab. En realidad, el sistema de slab solo creará una estructura central de caché de slab que tiene el nombre de slab "f2fs_xattr_entry-7:3", y dos cachés de slab comparten la misma estructura y dirección de caché.<br /> <br /> Entonces, si destruimos la caché f2fs_xattr_entry-7:3 con la dirección de caché, disminuirá el conteo de referencias de la caché de slab, en lugar de liberar la caché de slab por completo, ya que hay un usuario más que ha referenciado la caché.<br /> <br /> Luego, si intentamos crear la caché de slab con el nombre "f2fs_xattr_entry-7:3" nuevamente, el sistema de slab encontrará que existe una caché que tiene el mismo nombre y activará la advertencia.<br /> <br /> Cambiemos para usar inline_xattr_slab global en lugar de caché de slab por sb para la corrección.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fs: PM: Corrige la comprobación inversa en filesystems_freeze_callback()<br /> <br /> La comprobación freeze_all_ptr en filesystems_freeze_callback() introducida por el commit a3f8f8662771 (&amp;#39;power: always freeze efivarfs&amp;#39;) es inversa, lo que de forma bastante confusa provoca que todos los sistemas de archivos se congelen cuando filesystem_freeze_enabled es falso.<br /> <br /> En mis sistemas, provoca que el WARN_ON_ONCE() en __set_task_frozen() se active, muy probablemente debido a un intento de congelar un sistema de archivos que no está listo para ello.<br /> <br /> Añade una negación lógica a la comprobación en cuestión para invertirla según corresponda.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> f2fs: asegurar que las lecturas de páginas de nodo se completen antes de que f2fs_put_super() termine<br /> <br /> Xfstests generic/335, generic/336 a veces fallan con el siguiente mensaje:<br /> <br /> F2FS-fs (dm-0): detect filesystem reference count leak during umount, type: 9, count: 1<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/super.c:1939!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 1 UID: 0 PID: 609351 Comm: umount Tainted: G W 6.17.0-rc5-xfstests-g9dd1835ecda5 #1 PREEMPT(none)<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:f2fs_put_super+0x3b3/0x3c0<br /> Call Trace:<br /> <br /> generic_shutdown_super+0x7e/0x190<br /> kill_block_super+0x1a/0x40<br /> kill_f2fs_super+0x9d/0x190<br /> deactivate_locked_super+0x30/0xb0<br /> cleanup_mnt+0xba/0x150<br /> task_work_run+0x5c/0xa0<br /> exit_to_user_mode_loop+0xb7/0xc0<br /> do_syscall_64+0x1ae/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Parece que a veces es posible que se llame a f2fs_put_super() antes de que se completen todas las lecturas de páginas de nodo.<br /> Añadir una llamada a f2fs_wait_on_all_pages() para F2FS_RD_NODE soluciona el problema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> usb: typec: ucsi: Manejar capacidad incorrecta de num_connectors<br /> <br /> La especificación UCSI establece que el campo num_connectors es de 7 bits, y el octavo bit está reservado y debe establecerse a cero.<br /> Se sabe que algunos FW defectuosos han establecido este bit, y esto puede llevar a que un sistema no arranque.<br /> Indicar que el FW no se está comportando correctamente y corregir automáticamente el valor para que el sistema arranque correctamente.<br /> <br /> Encontrado en Lenovo P1 G8 durante el programa de habilitación de Linux. El FW se corregirá, pero pareció valer la pena abordarlo en caso de que afectara a plataformas que no son oficialmente compatibles con Linux.