Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> libceph: hacer decode_pool() más resistente contra osdmaps corruptos<br /> <br /> Si el osdmap está (maliciosamente) corrupto de tal manera que la longitud codificada del envoltorio ceph_pg_pool es menor de lo que se espera para una versión de codificación particular, pueden producirse lecturas fuera de límites porque la única comprobación de límites que existe se basa en ese valor de longitud.<br /> <br /> Este parche añade comprobaciones de límites explícitas para cada campo que se decodifica o se omite.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> block: Eliminar la congelación de la cola de varias devoluciones de llamada de almacenamiento de sysfs<br /> <br /> Congelar la cola de solicitudes desde dentro de las devoluciones de llamada de almacenamiento de sysfs puede causar un interbloqueo en combinación con el controlador dm-multipath y la opción queue_if_no_path. Además, congelar la cola de solicitudes ralentiza el arranque del sistema en sistemas donde los atributos de sysfs se configuran sincrónicamente.<br /> <br /> Solucione esto eliminando las llamadas blk_mq_freeze_queue() / blk_mq_unfreeze_queue() de las devoluciones de llamada de almacenamiento que no necesitan estrictamente estas devoluciones de llamada. Agregue la anotación __data_racy a request_queue.rq_timeout para suprimir los informes de condición de carrera de datos de KCSAN sobre las lecturas de rq_timeout.<br /> <br /> Este parche puede causar un pequeño retraso al aplicar las nuevas configuraciones.<br /> <br /> Para todos los atributos afectados por este parche, la E/S se completará correctamente ya sea que se utilice el valor antiguo o el nuevo del atributo.<br /> <br /> Este parche afecta a los siguientes atributos de sysfs:<br /> * io_poll_delay<br /> * io_timeout<br /> * nomerges<br /> * read_ahead_kb<br /> * rq_affinity<br /> <br /> Aquí hay un ejemplo de un interbloqueo desencadenado al ejecutar la prueba srp/002 si este parche no se aplica:<br /> <br /> tarea:multipathd<br /> Rastro de Llamada:<br /> <br /> __schedule+0x8c1/0x1bf0<br /> schedule+0xdd/0x270<br /> schedule_preempt_disabled+0x1c/0x30<br /> __mutex_lock+0xb89/0x1650<br /> mutex_lock_nested+0x1f/0x30<br /> dm_table_set_restrictions+0x823/0xdf0<br /> __bind+0x166/0x590<br /> dm_swap_table+0x2a7/0x490<br /> do_resume+0x1b1/0x610<br /> dev_suspend+0x55/0x1a0<br /> ctl_ioctl+0x3a5/0x7e0<br /> dm_ctl_ioctl+0x12/0x20<br /> __x64_sys_ioctl+0x127/0x1a0<br /> x64_sys_call+0xe2b/0x17d0<br /> do_syscall_64+0x96/0x3a0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> tarea:(udev-worker)<br /> Rastro de Llamada:<br /> <br /> __schedule+0x8c1/0x1bf0<br /> schedule+0xdd/0x270<br /> blk_mq_freeze_queue_wait+0xf2/0x140<br /> blk_mq_freeze_queue_nomemsave+0x23/0x30<br /> queue_ra_store+0x14e/0x290<br /> queue_attr_store+0x23e/0x2c0<br /> sysfs_kf_write+0xde/0x140<br /> kernfs_fop_write_iter+0x3b2/0x630<br /> vfs_write+0x4fd/0x1390<br /> ksys_write+0xfd/0x230<br /> __x64_sys_write+0x76/0xc0<br /> x64_sys_call+0x276/0x17d0<br /> do_syscall_64+0x96/0x3a0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br />

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ACPICA: Evitar recorrer el Namespace si start_node es NULL<br /> <br /> Aunque el commit 0c9992315e73 (&amp;#39;ACPICA: Evitar recorrer el ACPI Namespace si no está presente&amp;#39;) arregló la situación cuando tanto start_node como acpi_gbl_root_node son NULL, la línea principal del kernel de Linux ahora todavía fallaba en Honor Magicbook 14 Pro [1].<br /> <br /> Eso ocurre debido al acceso al miembro de parent_node en acpi_ns_get_next_node(). La desreferencia del puntero NULL siempre ocurrirá, sin importar si start_node es igual a ACPI_ROOT_OBJECT o no, así que mueva la comprobación de que start_node es NULL fuera del bloque if.<br /> <br /> Desafortunadamente, todos los intentos de contactar a Honor han fallado, se negaron a proporcionar cualquier soporte técnico para Linux.<br /> <br /> El volcado de la tabla DSDT defectuosa se puede encontrar en GitHub [2].<br /> <br /> DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025<br /> <br /> [ rjw: Ajuste del asunto, ediciones del registro de cambios ]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> powerpc/kexec: Habilitar SMT antes de activar las CPU sin conexión<br /> <br /> Si SMT está deshabilitado o un estado SMT parcial está habilitado, cuando una nueva imagen de kernel se carga para kexec, al reiniciar se observa la siguiente advertencia:<br /> <br /> kexec: Activando cpu 228 sin conexión.<br /> ADVERTENCIA: CPU: 0 PID: 9062 en arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc<br /> [snip]<br /> NIP kexec_prepare_cpus+0x1b0/0x1bc<br /> LR kexec_prepare_cpus+0x1a0/0x1bc<br /> Traza de llamada:<br /> kexec_prepare_cpus+0x1a0/0x1bc (no fiable)<br /> default_machine_kexec+0x160/0x19c<br /> machine_kexec+0x80/0x88<br /> kernel_kexec+0xd0/0x118<br /> __do_sys_reboot+0x210/0x2c4<br /> system_call_exception+0x124/0x320<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> Esto ocurre porque add_cpu() falla debido a que cpu_bootable() devuelve falso para las CPU que fallan la verificación cpu_smt_thread_allowed() o hilos no primarios si SMT está deshabilitado.<br /> <br /> Soluciona el problema habilitando SMT y restableciendo el número de hilos SMT al número de hilos por núcleo, antes de intentar activar todas las CPU presentes.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> SUNRPC: svcauth_gss: evitar desreferenciación de NULL en gss_token de longitud cero en gss_read_proxy_verf<br /> <br /> Un gss_token de longitud cero resulta en pages == 0 y in_token-&amp;gt;pages[0] es NULL. El código evalúa incondicionalmente page_address(in_token-&amp;gt;pages[0]) para el memcpy inicial, lo que puede desreferenciar NULL incluso cuando la longitud de la copia es 0. Proteger el primer memcpy para que solo se ejecute cuando length &amp;gt; 0.

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.