Vulnerabilidades

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.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> MIPS: ftrace: Corrige la corrupción de memoria cuando el kernel está ubicado más allá de los 32 bits<br /> <br /> Desde el commit e424054000878 (&amp;#39;MIPS: Tracing: Reduce the overhead of dynamic Function Tracer&amp;#39;), se ha utilizado la macro UASM_i_LA_mostly, y esta macro puede generar más de 2 instrucciones. Al mismo tiempo, el código en ftrace asume que no se pueden generar más de 2 instrucciones, razón por la cual las almacena en un array int[2]. Sin embargo, como se señaló anteriormente, la macro UASM_i_LA_mostly (y ahora UASM_i_LA) causa un desbordamiento de búfer cuando _mcount está más allá de los 32 bits. Esto lleva a la corrupción de las variables ubicadas en la sección __read_mostly.<br /> <br /> Esta corrupción se observó porque la variable __cpu_primary_thread_mask fue corrompida, causando un cuelgue muy temprano durante el arranque.<br /> <br /> Esta corrección previene la corrupción evitando la generación de instrucciones si estas pudieran exceder las 2 instrucciones de longitud. Afortunadamente, insn_la_mcount solo se usa si el código instrumentado está ubicado fuera de la sección de código del kernel, por lo que ftrace dinámico aún puede usarse, aunque con un alcance más limitado. Esto sigue siendo preferible a corromper la memoria y/o colapsar el kernel.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer<br /> <br /> When advancing the target expiration for the guest&amp;#39;s APIC timer in periodic<br /> mode, set the expiration to "now" if the target expiration is in the past<br /> (similar to what is done in update_target_expiration()). Blindly adding<br /> the period to the previous target expiration can result in KVM generating<br /> a practically unbounded number of hrtimer IRQs due to programming an<br /> expired timer over and over. In extreme scenarios, e.g. if userspace<br /> pauses/suspends a VM for an extended duration, this can even cause hard<br /> lockups in the host.<br /> <br /> Currently, the bug only affects Intel CPUs when using the hypervisor timer<br /> (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,<br /> a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the<br /> HV timer only runs while the guest is active. As a result, if the vCPU<br /> does not run for an extended duration, there will be a huge gap between<br /> the target expiration and the current time the vCPU resumes running.<br /> Because the target expiration is incremented by only one period on each<br /> timer expiration, this leads to a series of timer expirations occurring<br /> rapidly after the vCPU/VM resumes.<br /> <br /> More critically, when the vCPU first triggers a periodic HV timer<br /> expiration after resuming, advancing the expiration by only one period<br /> will result in a target expiration in the past. As a result, the delta<br /> may be calculated as a negative value. When the delta is converted into<br /> an absolute value (tscdeadline is an unsigned u64), the resulting value<br /> can overflow what the HV timer is capable of programming. I.e. the large<br /> value will exceed the VMX Preemption Timer&amp;#39;s maximum bit width of<br /> cpu_preemption_timer_multi + 32, and thus cause KVM to switch from the<br /> HV timer to the software timer (hrtimers).<br /> <br /> After switching to the software timer, periodic timer expiration callbacks<br /> may be executed consecutively within a single clock interrupt handler,<br /> because hrtimers honors KVM&amp;#39;s request for an expiration in the past and<br /> immediately re-invokes KVM&amp;#39;s callback after reprogramming. And because<br /> the interrupt handler runs with IRQs disabled, restarting KVM&amp;#39;s hrtimer<br /> over and over until the target expiration is advanced to "now" can result<br /> in a hard lockup.<br /> <br /> E.g. the following hard lockup was triggered in the host when running a<br /> Windows VM (only relevant because it used the APIC timer in periodic mode)<br /> after resuming the VM from a long suspend (in the host).<br /> <br /> NMI watchdog: Watchdog detected hard LOCKUP on cpu 45<br /> ...<br /> RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm]<br /> ...<br /> RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046<br /> RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc<br /> RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500<br /> RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0<br /> R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0<br /> R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8<br /> FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> apic_timer_fn+0x31/0x50 [kvm]<br /> __hrtimer_run_queues+0x100/0x280<br /> hrtimer_interrupt+0x100/0x210<br /> ? ttwu_do_wakeup+0x19/0x160<br /> smp_apic_timer_interrupt+0x6a/0x130<br /> apic_timer_interrupt+0xf/0x20<br /> <br /> <br /> Moreover, if the suspend duration of the virtual machine is not long enough<br /> to trigger a hard lockup in this scenario, since commit 98c25ead5eda<br /> ("KVM: VMX: Move preemption timer hrtimer dance to common x86"), KVM<br /> will continue using the software timer until the guest reprograms the APIC<br /> timer in some way. Since the periodic timer does not require frequent APIC<br /> timer register programming, the guest may continue to use the software<br /> timer in <br /> ---truncated---