Vulnerabilidades

La vulnerabilidad de exposición de información confidencial a un actor no autorizado en la aplicación de librería móvil de Yordam Information Technology permite recuperar datos confidenciales integrados. Este problema afecta a la aplicación de librería móvil: anterior a 5.0.

Un atacante con acceso a la red donde se encuentra CIRCUTOR Q-SMT en su versión de firmware 1.0.4, podría robar los tokens utilizados en la web, ya que estos no tienen fecha de caducidad para acceder a la aplicación web sin restricciones. El robo de tokens puede tener su origen en diferentes métodos como capturas de red, información web almacenada localmente, etc.

Vulnerabilidad en la versión de firmware 1.3b de CIRCUTOR TCP2RS+, que podría permitir a un atacante modificar cualquier valor de configuración, incluso si el equipo tiene habilitada la opción de autenticación de usuario/contraseña, sin autenticación mediante el envío de paquetes a través del protocolo UDP y el puerto 2000, desconfigurando el equipo y deshabilitando así su uso. Este equipo se encuentra al final de su ciclo de vida útil.

IBM Business Automation Workflow 22.0.2, 23.0.1, 23.0.2 y 24.0.0 podrían permitir que un usuario privilegiado realice actividades no autorizadas debido a una validación incorrecta del lado del cliente.

CIRCUTOR Q-SMT en su versión de firmware 1.0.4, podría verse afectado por un ataque de denegación de servicio (DoS) si un atacante con acceso al servicio web evita los mecanismos de autenticación en la página de login, permitiendo al atacante utilizar todas las funcionalidades implementadas a nivel web que permiten interactuar con el dispositivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: codetag: debug: marcar los codetags de las páginas envenenadas como vacíos Cuando se liberan las páginas PG_hwpoison, se las trata de forma diferente en free_pages_prepare() y, en lugar de liberarse, se las aísla. Los contadores de etiquetas de asignación de páginas se reducen en este punto, ya que se considera que la página no está en uso. Más adelante, cuando unpoison_memory() libere dichas páginas, los contadores de etiquetas de asignación se reducirán nuevamente y se informará la siguiente advertencia: [ 113.930443][ T3282] ------------[ cortar aquí ]------------ [ 113.931105][ T3282] alloc_tag no se configuró [ 113.931576][ T3282] ADVERTENCIA: CPU: 2 PID: 3282 en ./include/linux/alloc_tag.h:130 pgalloc_tag_sub.part.66+0x154/0x164 [ 113.932866][ T3282] Módulos vinculados en: hwpoison_inject fuse ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute ip6table_nat ip6table_man4 [ 113.941638][ T3282] CPU: 2 UID: 0 PID: 3282 Comm: madvise11 Kdump: cargado Contaminado: GW 6.11.0-rc4-dirty #18 [ 113.943003][ T3282] Contaminado: [W]=WARN [ 113.943453][ T3282] Nombre del hardware: Máquina virtual KVM QEMU, BIOS desconocido 2/2/2022 [ 113.944378][ T3282] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 113.945319][ T3282] pc : pgalloc_tag_sub.part.66+0x154/0x164 [ 113.946016][ T3282] lr : pgalloc_tag_sub.part.66+0x154/0x164 [ 113.946706][ T3282] sp : ffff800087093a10 [ 113.947197][ T3282] x29: ffff800087093a10 x28: ffff0000d7a9d400 x27: ffff80008249f0a0 [ 113.948165][ T3282] x26: 0000000000000000 x25: ffff80008249f2b0 x24: 0000000000000000 [ 113.949134][ T3282] x23: 0000000000000001 x22: 0000000000000001 x21: 0000000000000000 [ 113.950597][ T3282] x20: ffff0000c08fcad8 x19: ffff80008251e000 x18: ffffffffffffffffff [ 113.952207][ T3282] x17: 0000000000000000 x16: 0000000000000000 x15: ffff800081746210 [ 113.953161][ T3282] x14: 0000000000000000 x13: 205d323832335420 x12: 5b5d353031313339 [ 113.954120][ T3282] x11: ffff800087093500 x10: 00000000000005d x9: 00000000ffffffd0 [ 113.955078][ T3282] x8: 7f7f7f7f7f7f7f7f x7: ffff80008236ba90 x6 : c0000000ffff7fff [ 113.956036][ T3282] x5 : ffff000b34bf4dc8 x4 : ffff8000820aba90 x3 : 0000000000000001 [ 113.956994][ T3282] x2 : ffff800ab320f000 x1 : 841d1e35ac932e00 x0 : 0000000000000000 [ 113.957962][ T3282] Rastreo de llamadas: [ 113.958350][ T3282] pgalloc_tag_sub.part.66+0x154/0x164 [ 113.959000][ T3282] pgalloc_tag_sub+0x14/0x1c [ 113.959539][ T3282] página libre sin referencia+0xf4/0x4b8 [ 113.960096][ T3282] __folio_put+0xd4/0x120 [ 113.960614][ T3282] folio_put+0x24/0x50 [ 113.961103][ T3282] memoria sin envenenar+0x4f0/0x5b0 [ 113.961678][ T3282] memoria sin envenenar+0x30/0x48 [hwpoison_inject] [ 113.962436][ T3282] escritura_attr_simple_xsigned.isra.34+0xec/0x1cc [ 113.963183][ T3282] escritura_attr_simple+0x38/0x48 [ 113.963750][ T3282] escritura_attr_debugfs+0x54/0x80 [ 113.964330][ T3282] escritura_proxy_completa+0x68/0x98 [ 113.964880][ T3282] escritura_vfs+0xdc/0x4d0 [ 113.965372][ T3282] escritura_ksys+0x78/0x100 [ 113.965875][ T3282] __arm64_sys_write+0x24/0x30 [ 113.966440][ T3282] invocar_llamada_al_sistema+0x7c/0x104 [ 113.966984][ T3282] el0_svc_common.constprop.1+0x88/0x104 [ 113.967652][ T3282] do_el0_svc+0x2c/0x38 [ 113.968893][ T3282] el0_svc+0x3c/0x1b8 [ 113.969379][ T3282] el0t_64_sync_handler+0x98/0xbc [ 113.969980][ T3282] el0t_64_sync+0x19c/0x1a0 [ 113.970511][ T3282] ---[ fin del seguimiento 0000000000000000 ]--- Para solucionar esto, borre la referencia de la etiqueta de página después de que la página haya sido aislada y contabilizada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: misaligned: Restringe el acceso del usuario a la memoria del kernel raw_copy_{to,from}_user() no llama a access_ok(), por lo que este código permitía que el espacio de usuario accediera a cualquier dirección de memoria virtual.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: Placas: Arreglar la desreferenciación del puntero NULL en las placas BYT/CHT de forma más difícil Desde el commit 13f58267cda3 ("ASoC: soc.h: no crear un componente ficticio mediante COMP_DUMMY()"), los códecs ficticios se declaran de esta manera: SND_SOC_DAILINK_DEF(dummy, DAILINK_COMP_ARRAY(COMP_DUMMY())); expandir a: static struct snd_soc_dai_link_component dummy[] = { }; Lo que significa que dummy es una matriz de tamaño cero y, por lo tanto, dais[i].codecs no debería desreferenciarse *en absoluto*, ya que apunta a la dirección de la siguiente variable almacenada en la sección de datos, ya que la variable "ficticia" tiene una dirección pero no un tamaño, por lo que incluso desreferenciar dais[0] ya es una referencia de matriz fuera de límites. Esto significa que la comprobación if (dais[i].codecs->name) añadida en el commit 7d99a70b6595 ("ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards") se basa en que la parte de la siguiente variable a la que se asigna el miembro name resulta ser NULL. Lo que aparentemente hasta ahora suele ser así, excepto cuando no lo es y entonces da como resultado fallos como este: [ 28.795659] ERROR: no se puede gestionar la falla de página para la dirección: 0000000000030011 ... [ 28.795780] Seguimiento de llamadas: [ 28.795787] ... [ 28.795862] ? strcmp+0x18/0x40 [ 28.795872] 0xffffffffc150c605 [ 28.795887] platform_probe+0x40/0xa0 ... [ 28.795979] ? __pfx_init_module+0x10/0x10 [snd_soc_sst_bytcr_wm5102] Esta vez realmente solucione las cosas comprobando que dais.num_codecs != 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: se corrige la doble colocación de @cfile en smb2_set_path_size() Si se llama a smb2_compound_op() con un @cfile válido y se devuelve -EINVAL, debemos llamar a cifs_get_writable_path() antes de volver a intentarlo ya que la referencia de @cfile ya fue descartada por la llamada anterior. Esto corrige el siguiente error de KASAN al ejecutar fstests generic/013 contra Windows Server 2022: CIFS: Intentando montar //w22-fs0/scratch ejecutar fstests generic/013 a las 2024-09-02 19:48:59 ====================================================================== ERROR: KASAN: slab-use-after-free en detach_if_pending+0xab/0x200 Escritura de tamaño 8 en la dirección ffff88811f1a3730 por la tarea kworker/3:2/176 CPU: 3 UID: 0 PID: 176 Comm: kworker/3:2 No contaminado 6.11.0-rc6 #2 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 01/04/2014 Cola de trabajo: cifsoplockd cifs_oplock_break [cifs] Seguimiento de llamadas: dump_stack_lvl+0x5d/0x80 ? detach_if_pending+0xab/0x200 print_report+0x156/0x4d9 ? detach_if_pending+0xab/0x200 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? detach_if_pending+0xab/0x200 kasan_report+0xda/0x110 ? detach_if_pending+0xab/0x200 detach_if_pending+0xab/0x200 timer_delete+0x96/0xe0 ? __pfx_timer_delete+0x10/0x10 ? rcu_is_watching+0x20/0x50 try_to_grab_pending+0x46/0x3b0 __cancel_work+0x89/0x1b0 ? __pfx___cancel_work+0x10/0x10 ? kasan_save_track+0x14/0x30 cifs_close_deferred_file+0x110/0x2c0 [cifs] ? __pfx_cifs_close_deferred_file+0x10/0x10 [cifs] ? __pfx_down_read+0x10/0x10 cifs_oplock_break+0x4c1/0xa50 [cifs] ? __pfx_cifs_oplock_break+0x10/0x10 [cifs] ? tipo_bloqueo_retenido+0x85/0xf0 ? marcar_bloqueos_retenidos+0x1a/0x90 proceso_una_obra+0x4c6/0x9f0 ? encontrar_bloqueo_retenido+0x8a/0xa0 ? __pfx_proceso_una_obra+0x10/0x10 ? bloqueo_adquirido+0x220/0x550 ? __lista_agregar_válido_o_informe+0x37/0x100 subproceso_trabajador+0x2e4/0x570 ? __pfx_kthread+0x10/0x10 ret_de_la_bifurcación+0x31/0x60 ? Asignado por la tarea 1118: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 cifs_new_fileinfo+0xc8/0x9d0 [cifs] cifs_atomic_open+0x467/0x770 [cifs] lookup_open.isra.0+0x665/0x8b0 path_openat+0x4c3/0x1380 do_filp_open+0x167/0x270 do_sys_openat2+0x129/0x160 __x64_sys_creat+0xad/0xe0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Liberado por la tarea 83: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 poison_slab_object+0xe9/0x160 __kasan_slab_free+0x32/0x50 kfree+0xf2/0x300 process_one_work+0x4c6/0x9f0 worker_thread+0x2e4/0x570 kthread+0x17f/0x1c0 ret_from_fork+0x31/0x60 ret_from_fork_asm+0x1a/0x30 Última creación de trabajo potencialmente relacionado: kasan_save_stack+0x30/0x50 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x29/0xe0 __queue_work+0x5ea/0x760 queue_work_on+0x6d/0x90 _cifsFileInfo_put+0x3f6/0x770 [cifs] smb2_compound_op+0x911/0x3940 [cifs] smb2_set_path_size+0x228/0x270 [cifs] cifs_set_file_size+0x197/0x460 [cifs] cifs_setattr+0xd9c/0x14b0 [cifs] notificar_cambio+0x4e3/0x740 hacer_truncar+0xfa/0x180 vfs_truncar+0x195/0x200 __x64_sys_truncar+0x109/0x150 hacer_syscall_64+0xbb/0x1d0 entrada_SYSCALL_64_después_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/qspinlock: Se corrige el bloqueo en la cola MCS Si se produce una interrupción en queued_spin_lock_slowpath() después de que incrementamos qnodesp->count y antes de que se inicialice node->lock, otra CPU podría ver valores de bloqueo obsoletos en get_tail_qnode(). Si el valor de bloqueo obsoleto coincide con el bloqueo en esa CPU, entonces escribimos en el puntero "siguiente" del qnode incorrecto. Esto provoca un bloqueo ya que la CPU anterior, una vez que se convierte en la cabeza de la cola MCS, girará indefinidamente hasta que su puntero "siguiente" sea establecido por su sucesor en la cola. Al ejecutar stress-ng en una LPAR compartida de 16 núcleos (16EC/16VP), se producen bloqueos ocasionales similares a los siguientes: $ stress-ng --all 128 --vm-bytes 80% --aggressive \ --maximize --oomable --verify --syslog \ --metrics --times --timeout 5m watchdog: CPU 15 Hard LOCKUP ...... NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490 LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90 Seguimiento de llamadas: 0xc000002cfffa3bf0 (no confiable) _raw_spin_lock+0x6c/0x90 bloqueo_de_rq_de_spin_sin_formato_anidado.parte.135+0x4c/0xd0 pendiente_programa_de_programación_pendiente+0x60/0x1f0 __vaciado_cola_de_funciones_de_llamada_smp+0x1dc/0x670 smp_ipi_demux_relajado+0xa4/0x100 acción_ipi_muxed_xive+0x20/0x40 __controlador_evento_irq_percpu+0x80/0x240 control_evento_irq_percpu+0x2c/0x80 control_percpu_irq+0x84/0xd0 control_irq_genérico+0x54/0x80 __do_irq+0xac/0x210 __do_IRQ+0x74/0xd0 0x0 do_IRQ+0x8c/0x170 interrupción_de_hardware_virt_común+0x29c/0x2a0 --- interrupción: 500 en ruta_lenta_bloqueo_de_giro_en_cola+0x4b8/0x1490 ...... NIP [c0000000000b6c28] ruta_lenta_bloqueo_de_giro_en_cola+0x4b8/0x1490 LR [c000000001037c5c] _bloqueo_de_giro_en_cola+0x6c/0x90 --- interrupción: 500 0xc0000029c1a41d00 (no confiable) _bloqueo_de_giro_en_cola+0x6c/0x90 futex_wake+0x100/0x260 do_futex+0x21c/0x2a0 sys_futex+0x98/0x270 system_call_exception+0x14c/0x2f0 system_call_vectored_common+0x15c/0x2ec El siguiente flujo de código ilustra cómo se produce el interbloqueo. Para abreviar, supongamos que ambos bloqueos (A y B) están en conflicto y llamamos a la función queued_spin_lock_slowpath(). CPU0 CPU1 ---- ---- spin_lock_irqsave(A) | spin_unlock_irqrestore(A) | spin_lock(B) | | | ? | id = qnodesp->count++; | (Tenga en cuenta que nodes[0].lock == A) | | | ? | Interrupción | (sucede antes de "nodes[0].lock = B") | | | ? | spin_lock_irqsave(A) | | | ? | id = qnodesp->count++ | nodes[1].lock = A | | | ? | Cola de la cola MCS | | spin_lock_irqsave(A) ? | Cabecera de la cola MCS ? | CPU0 es la cola anterior ? | Girar indefinidamente ? (hasta que "nodes[1].next != NULL") prev = get_tail_qnode(A, CPU0) | ? prev == &qnodes[CPU0].nodes[0] (como qnodes ---truncados---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: ti: am65-cpsw: Corregir la desreferencia NULL en XDP_TX Si el número de colas TX se establece en 1, obtenemos una desreferencia de puntero NULL durante XDP_TX. ~# ethtool -L eth0 tx 1 ~# ./xdp-trafficgen udp -A -a eth0 -t 2 Transmitiendo en eth0 (ifindex 2) [ 241.135257] No se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000030 Solucione esto utilizando colas TX reales en lugar de colas TX máximas al seleccionar el canal TX en am65_cpsw_ndo_xdp_xmit().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: libfs: fix get_stashed_dentry() get_stashed_dentry() intenta recuperar de forma optimista un dentry almacenado en caché desde una ubicación proporcionada. Debe asegurarse de mantener el bloqueo de rcu antes de desreferenciar la ubicación almacenada para evitar problemas de UAF. Use rcu_dereference() en lugar de READ_ONCE(), es efectivamente equivalente con algunas funciones adicionales de lockdep y comunica claramente que esto espera protección de rcu.