Vulnerabilidades

En VeridiumID anterior a 3.5.0, la API WebAuthn permite que un atacante interno no autenticado (que puede pasar verificaciones de inscripción y puede registrar una clave FIDO) registre su autenticador FIDO en la cuenta de una víctima y, en consecuencia, se haga cargo de la cuenta.

Si se agregaba un elemento inseguro a una página después de un retraso, Firefox no reemplazaría el ícono seguro con un estado de seguridad de contenido mixto. Esta vulnerabilidad afecta a Firefox para iOS < 124.

Arrastrar las URL de Javascript a la barra de direcciones podría provocar que se carguen, evitando restricciones y protecciones de seguridad. Esta vulnerabilidad afecta a Firefox para iOS < 124.

*** Pendiente de traducción *** Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/i915/dsc: corrige la macro que calcula la dirección de registro DSCC_/DSCA_ PPS Commit bd077259d0a9 ("drm/i915/vdsc: Agregar función para leer cualquier registro PPS") define un Nueva macro para calcular las direcciones de registro DSC PPS con el número PPS como entrada. Esta macro calcula correctamente las direcciones hasta PPS 11 ya que las direcciones se incrementan en 4. Entonces, en ese caso, la siguiente macro funciona correctamente para proporcionar la dirección de registro correcta: _MMIO(_DSCA_PPS_0 + (pps) * 4) Sin embargo, después de PPS 11, la dirección de registro para PPS 12 se incrementa en 12 debido a la asignación de memoria del búfer RC en el medio. Debido a esta discontinuidad en el espacio de direcciones, la macro calcula direcciones incorrectas para PPS 12 - 16, lo que genera lecturas/escrituras incorrectas del valor del parámetro PPS de DSC, lo que provoca corrupción de DSC. Esto se soluciona corrigiendo esta macro para agregar el desplazamiento de 12 para PPS >=12. v3: agregue paréntesis correcto para el argumento pps (Jani Nikula) (seleccionado del commit 6074be620c31dc2ae11af96a1a5ea95580976fb5)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: rt5645: corrige el punto muerto en rt5645_jack_detect_work() Hay una ruta en rt5645_jack_detect_work(), donde rt5645->jd_mutex queda bloqueado para siempre. Eso puede provocar un punto muerto cuando se llama a rt5645_jack_detect_work() por segunda vez. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lan966x: se solucionó el bloqueo al agregar una interfaz con un retraso. Se produce un bloqueo al agregar una de las interfaces lan966x con un retraso. El problema se puede reproducir así: enlace ip agregar nombre bond0 tipo bond miimon modo 100 balance-xor enlace ip establecer dev eth0 master bond0 La razón es que al agregar una interfaz bajo el retraso pasaría por todos los puertos e intentaría calcular determine qué otros puertos están bajo esa interfaz de retraso. Y el problema es que lan966x puede tener puertos que sean punteros NULL ya que no están sondeados. Entonces, al iterar sobre estos puertos, simplemente fallaría porque son punteros NULL. La solución consiste en comprobar si hay punteros NULL antes de acceder a algo desde los puertos. Como hacemos en otros lugares.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5: DPLL, corrige el posible uso después de la activación del temporizador de trabajo retrasado después de la liberación. Logré alcanzar el siguiente uso después de la advertencia de la liberación gratuita recientemente: [2169.711665] ======== ==================================================== ======== [2169.714009] ERROR: KASAN: slab-use-after-free en __run_timers.part.0+0x179/0x4c0 [2169.716293] Escritura de tamaño 8 en la dirección ffff88812b326a70 mediante task swapper/4/0 [ 2169.719022] CPU: 4 PID: 0 Comm: swapper/4 No contaminado 6.8.0-rc2jiri+ #2 [2169.720974] Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02- prebuilt.qemu.org 01/04/2014 [2169.722457] Seguimiento de llamadas: [2169.722756] [2169.723024] dump_stack_lvl+0x58/0xb0 [2169.723417] print_report+0xc5/0x630 [2169.72 3807] ? __virt_addr_valid+0x126/0x2b0 [ 2169.724268] kasan_report+0xbe/0xf0 [ 2169.724667] ? __run_timers.part.0+0x179/0x4c0 [2169.725116]? __run_timers.part.0+0x179/0x4c0 [2169.725570] __run_timers.part.0+0x179/0x4c0 [2169.726003]? call_timer_fn+0x320/0x320 [2169.726404]? lock_downgrade+0x3a0/0x3a0 [2169.726820]? kvm_clock_get_cycles+0x14/0x20 [2169.727257]? ktime_get+0x92/0x150 [2169.727630]? lapic_next_deadline+0x35/0x60 [ 2169.728069] run_timer_softirq+0x40/0x80 [ 2169.728475] __do_softirq+0x1a1/0x509 [ 2169.728866] irq_exit_rcu+0x95/0xc0 [ 2169.7 29241] sysvec_apic_timer_interrupt+0x6b/0x80 [ 2169.729718] [ 2169.729993] [ 2169.730259] asm_sysvec_apic_timer_interrupt+0x16/0x20 [ 2169.730755] RIP: 0010:default_idle+0x13/0x20 [ 2169.731190] Código: c0 08 00 00 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 72 ff ff ff cc cc cc cc 8b 05 9a 7f 1f 02 85 c0 7e 07 0f 00 2d cf 69 43 00 fb f4 c3 66 66 2e 0f 1f 84 00 00 00 00 00 65 48 8b 04 25 c0 93 04 00 [ 2169.732759 ] RSP: 0018:ffff888100dbfe10 EFLAGS : 00000242 [ 2169.733264] RAX: 00000000000000001 RBX: ffff888100d9c200 RCX: ffffffff8241bd62 [ 2169.733925] RDX: ffffed109a848b15 RSI: 000000000 0000004 RDI: ffffffff8127ac55 [ 2169.734566] RBP: 0000000000000004 R08: 0000000000000000 R09: ffffed109a848b14 [ 2169.735200] R10: ffff8884d4245 8a3 R11: 000000000000ba7e R12: ffffffff83d7d3a0 [2169.735835] R13: 1ffff110201b7fc6 R14: 0000000000000000 R15: ffff888100d9c200 [2169.736478] ? ct_kernel_exit.constprop.0+0xa2/0xc0 [2169.736954]? do_idle+0x285/0x290 [ 2169.737323] default_idle_call+0x63/0x90 [ 2169.737730] do_idle+0x285/0x290 [ 2169.738089] ? arch_cpu_idle_exit+0x30/0x30 [2169.738511]? mark_held_locks+0x1a/0x80 [2169.738917]? lockdep_hardirqs_on_prepare+0x12e/0x200 [ 2169.739417] cpu_startup_entry+0x30/0x40 [ 2169.739825] start_secondary+0x19a/0x1c0 [ 2169.740229] ? set_cpu_sibling_map+0xbd0/0xbd0 [ 2169.740673] second_startup_64_no_verify+0x15d/0x16b [ 2169.741179] [ 2169.741686] Asignado por la tarea 1098: [ 2169.742058] kasan_save_s tachuela+0x1c/0x40 [ 2169.742456] kasan_save_track+0x10/0x30 [ 2169.742852] __kasan_kmalloc+0x83 /0x90 [ 2169.743246] mlx5_dpll_probe+0xf5/0x3c0 [mlx5_dpll] [ 2169.743730] sonda_bus_auxiliar+0x62/0xb0 [ 2169.744148] sonda_real+0x127/0x590 [ 2169.744534] __driver_probe_device+0xd2/0x200 [ 2169.744973] dispositivo_driver_attach+0x6b/0xf0 [ 2169.745402] bind_store+ 0x90/0xe0 [ 2169.745761] kernfs_fop_write_iter+0x1df/0x2a0 [ 2169.746210] vfs_write+0x41f/0x790 [ 2169.746579] ksys_write+0xc7/0x160 [ 2169.746947 ] do_syscall_64+0x6f/0x140 [ 2169.747333] Entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 2169.748049] Liberado por la tarea 1220 : [ 2169.748393] kasan_save_stack+0x1c/0x40 [ 2169.748789] kasan_save_track+0x10/0x30 [ 2169.749188] kasan_save_free_info+0x3b/0x50 [ 2169.749621] veneno_slab_object+0x106 /0x180 [ 2169.750044] __kasan_slab_free+0x14/0x50 [ 2169.750451] kfree+0x118/0x330 [ 2169.750792] mlx5_dpll_remove+0xf5/0x110 [mlx5_dpll] [ 2169.751271] auxiliar_bus_remove+0x2e/0x40 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dpll: soluciona un posible punto muerto durante la operación de volcado de netlink Recientemente, he estado recibiendo la siguiente advertencia de punto muerto durante el volcado de pin de dpll: [52804.637962] =========== =========================================== [52804.638536] ADVERTENCIA: posible circular dependencia de bloqueo detectada [52804.639111] 6.8.0-rc2jiri+ #1 No contaminado [52804.639529] -------------------------------- ---------------------- [52804.640104] python3/2984 está intentando adquirir el bloqueo: [52804.640581] ffff88810e642678 (nlk_cb_mutex-GENERIC){+.+.}- {3:3}, en: netlink_dump+0xb3/0x780 [52804.641417] pero la tarea ya mantiene el bloqueo: [52804.642010] ffffffff83bde4c8 (dpll_lock){+.+.}-{3:3}, en: dpll_lock_dumpit+0x13/0x20 [52804.642747] qué bloqueo ya depende del nuevo bloqueo. [52804.643551] la cadena de dependencia existente (en orden inverso) es: [52804.644259] -> #1 (dpll_lock){+.+.}-{3:3}: [52804.644836] lock_acquire+0x174/0x3e0 [52804.645271] __mutex_lock+ 0x119/0x1150 [52804.645723] dpll_lock_dumpit+0x13/0x20 [52804.646169] genl_start+0x266/0x320 [52804.646578] __netlink_dump_start+0x321/0x450 [52804.647056 ] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.647575] genl_rcv_msg+0x1ed/0x3b0 [52804.648001] netlink_rcv_skb+0xdc/ 0x210 [52804.648440] genl_rcv+0x24/0x40 [52804.648831] netlink_unicast+0x2f1/0x490 [52804.649290] netlink_sendmsg+0x36d/0x660 [52804.649742] __sock_sendmsg +0x73/0xc0 [52804.650165] __sys_sendto+0x184/0x210 [52804.650597] __x64_sys_sendto+0x72/0x80 [ 52804.651045] do_syscall_64+0x6f/0x140 [52804.651474] Entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.652001] -> #0 (nlk_cb_mutex-GENERIC){+.+.}-{3:3}: [52804.6 52650] check_prev_add+0x1ae/0x1280 [52804.653107 ] __lock_acquire+0x1ed3/0x29a0 [52804.653559] lock_acquire+0x174/0x3e0 [52804.653984] __mutex_lock+0x119/0x1150 [52804.654423] netlink_dump+0xb3/0x780 [52804.654 845] __netlink_dump_start+0x389/0x450 [52804.655321] genl_family_rcv_msg_dumpit+0x155/0x1e0 [52804.655842] genl_rcv_msg +0x1ed/0x3b0 [52804.656272] netlink_rcv_skb+0xdc/0x210 [52804.656721] genl_rcv+0x24/0x40 [52804.657119] netlink_unicast+0x2f1/0x490 [52804.657570] netlink_sendm sg+0x36d/0x660 [52804.658022] __sock_sendmsg+0x73/0xc0 [52804.658450] __sys_sendto+0x184 /0x210 [52804.658877] __x64_sys_sendto+0x72/0x80 [52804.659322] do_syscall_64+0x6f/0x140 [52804.659752] Entry_SYSCALL_64_after_hwframe+0x46/0x4e [52804.66 0281] otra información que podría ayudarnos a depurar esto: [52804.661077] Posible escenario de bloqueo inseguro: [52804.661671] CPU0 CPU1 [52804.662129] ---- ---- [52804.662577] bloqueo(dpll_lock); [52804.662924] bloqueo (nlk_cb_mutex-GENERIC); [52804.663538] bloqueo(dpll_lock); [52804.664073] bloqueo (nlk_cb_mutex-GENERIC); [52804.664490] El problema es el siguiente: __netlink_dump_start() llama a control->start(cb) con nlk->cb_mutex retenido. En control->start(cb) se toma dpll_lock. Luego, nlk->cb_mutex se libera y se toma nuevamente en netlink_dump(), mientras dpll_lock aún se mantiene. Eso lleva a un punto muerto de ABBA cuando otra CPU corre con la misma operación. Solucione este problema moviendo dpll_lock a la devolución de llamada dumpit(), lo que garantiza el orden correcto de toma de bloqueo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: no elimine extend_map para el inodo de espacio libre en el error de escritura Mientras ejecutaba el CI para un cambio no relacionado, encontré el siguiente pánico con generic/648 en btrfs_holes_spacecache. error de aserción: block_start != EXTENT_MAP_HOLE, en fs/btrfs/extent_io.c:1385 ------------[ cortar aquí ]------------ ERROR del kernel en fs /btrfs/extent_io.c:1385! código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: cargado Contaminado: GW 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Seguimiento de llamadas: < TAREA> extensión_write_cache_pages+0x2ac/0x8f0 extensión_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_ca che+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813 /0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 Esto sucede porque no logramos escribir el espacio libre en caché en una instancia, volvemos e intentamos escribirlo nuevamente. Sin embargo, en el segundo paso, llamamos a btrfs_get_extent() en el inodo para obtener el mapeo de extensión. Debido a que este es un nuevo grupo de bloques, y con el inodo de espacio libre siempre buscamos la raíz de confirmación para evitar un punto muerto con el árbol, no encontramos nada y devolvemos un EXTENT_MAP_HOLE para el rango solicitado. Esto sucede porque la primera vez que intentamos escribir el caché de espacio, encontramos un error y, en caso de error, descartamos la asignación de extensión. Esto es normal para archivos normales, pero el inodo de caché de espacio libre es especial. Siempre esperamos que el mapa de extensión sea correcto. Por lo tanto, la segunda vez terminamos con un mapa de extensión falso. Dado que estamos desaprobando esta función, la forma más sencilla de solucionarlo es simplemente omitir la eliminación del rango del mapa de extensión para este rango fallido. Acorté la prueba usando inyección de error para enfatizar el área y facilitar su reproducción. Con este parche implementado, ya no entraremos en pánico con mi prueba de inyección de errores.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: no haga ASSERT() si el subvolumen recién creado ya se leyó [ERROR] Hay un bloqueo del syzbot, provocado por ASSERT() durante la creación del subvolumen: la aserción falló: ! anon_dev, en fs/btrfs/disk-io.c:1319 ------------[ cortar aquí ]------------ ERROR del kernel en fs/btrfs/disk -io.c:1319! código de operación no válido: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 btrfs_get_new_fs_root+0xd3/0xf0 create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __ btrfs_ioctl_snap_create+0x2f9/0x4f0 btrfs_ioctl_snap_create+0x16b /0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210 do_syscall_64+0x3f/0xe0 Entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]--- [CA USO] Durante create_subvol(), después de insertar el elemento raíz para el subvolumen recién creado , activaríamos btrfs_get_new_fs_root() para obtener el btrfs_root de ese subvolumen. La idea aquí es que hemos preasignado un número de dispositivo anónimo para el subvolumen, por lo que podemos asignarlo al nuevo subvolumen. Pero realmente no hay nada que impida que cosas como backref caminen para leer el nuevo subvolumen. Si eso sucede antes de que llamemos a btrfs_get_new_fs_root(), se leerá el subvolumen y ya se habrá asignado un nuevo número de dispositivo anónimo. En ese caso, activaríamos ASSERT(), ya que realmente esperamos que nadie lea ese subvolumen (al que aún no se puede acceder desde fs). Pero aún es posible realizar cosas como el recorrido de referencia atrás para activar la lectura en el subvolumen. Por lo tanto, nuestra suposición sobre ASSERT() no es correcta en primer lugar. [FIX] Arréglelo eliminando ASSERT() y simplemente libere @anon_dev, restablezcalo a 0 y continúe. Si otra cosa lee el árbol de subvolumen, ya debería tener asignado un nuevo anon_dev, por lo que solo necesitamos liberar el preasignado.

Se descubrió que Puwell Cloud Tech Co, Ltd 360Eyes Pro v3.9.5.16(3090516) transmite información confidencial en texto sin cifrar. Esta vulnerabilidad permite a los atacantes interceptar y acceder a información confidencial, incluidas las credenciales de los usuarios y las solicitudes de cambio de contraseña.