Vulnerabilidades

Se encontró una vulnerabilidad en el Sistema de Gestión de Seguridad de Operación y Mantenimiento de Sangfor hasta la versión 3.0.12. Esto afecta la función portValidate del archivo /fort/ip_and_port/port_validate del componente Manejador de Solicitudes POST HTTP. Realizar una manipulación del argumento port resulta en inyección de comandos. El ataque puede iniciarse de forma remota. El exploit se ha hecho público y podría ser utilizado.

Se ha encontrado un fallo en Beetel 777VR1 hasta 01.00.09/01.00.09_55. El elemento afectado es una función desconocida del componente Interfaz UART. Esta manipulación provoca controles de acceso inadecuados. Es factible realizar el ataque en el dispositivo físico. La complejidad de un ataque es bastante alta. La explotabilidad se describe como difícil. El exploit se ha publicado y puede usarse. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió de ninguna manera.

Una vulnerabilidad se ha encontrado en el Sistema de Gestión de Seguridad de Operación y Mantenimiento de Sangfor hasta la versión 3.0.12. El elemento afectado es una función desconocida del archivo /fort/audit/get_clip_img del componente Manejador de Solicitudes HTTP POST. Dicha manipulación del argumento frame/dirno conduce a inyección de comandos. Es posible lanzar el ataque remotamente. El exploit ha sido divulgado al público y puede ser utilizado.

Una vulnerabilidad fue detectada en Beetel 777VR1 hasta 01.00.09/01.00.09_55. Afectada es una función desconocida del componente Interfaz UART. La manipulación resulta en falta de autenticación. Un ataque en el dispositivo físico es factible. Este ataque se caracteriza por alta complejidad. La explotabilidad se considera difícil. El exploit es ahora público y puede ser usado. El proveedor fue contactado tempranamente sobre esta divulgación pero no respondió de ninguna manera.

Una vulnerabilidad de seguridad ha sido detectada en Beetel 777VR1 hasta 01.00.09/01.00.09_55. Este problema afecta a algún procesamiento desconocido del componente Interfaz UART. La manipulación lleva a una restricción inadecuada de intentos de autenticación excesivos. Es posible lanzar el ataque en el dispositivo físico. La complejidad del ataque se califica como alta. La explotabilidad se evalúa como difícil. El exploit ha sido divulgado públicamente y puede ser usado. El proveedor fue contactado tempranamente sobre esta divulgación pero no respondió de ninguna manera.

Se ha identificado una debilidad en Beetel 777VR1 hasta la versión 01.00.09/01.00.09_55. Esta vulnerabilidad afecta a código desconocido del componente Interfaz UART. La ejecución de una manipulación puede llevar a requisitos de contraseña débiles. El dispositivo físico puede ser el objetivo del ataque. El ataque requiere un alto nivel de complejidad. Se afirma que la explotabilidad es difícil. El exploit se ha puesto a disposición del público y podría ser utilizado para ataques. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió de ninguna manera.

Una falla de seguridad ha sido descubierta en Beetel 777VR1 hasta 01.00.09/01.00.09_55. Esto afecta una parte desconocida del componente Interfaz UART. Realizar una manipulación resulta en revelación de información. El ataque puede ser llevado a cabo en el dispositivo físico. Se considera que el ataque tiene alta complejidad. Se indica que la explotabilidad es difícil. El exploit ha sido publicado al público y puede ser usado para ataques. El proveedor fue contactado tempranamente sobre esta revelación pero no respondió de ninguna manera.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm/damon/core: eliminar call_control en contextos inactivos<br /> <br /> Si damon_call() se ejecuta contra un contexto DAMON que no está en ejecución, la función devuelve un error mientras mantiene el objeto damon_call_control vinculado a la lista call_controls del contexto. Supongamos que el objeto es desasignado después de damon_call(), y se ejecuta otro damon_call() contra el mismo contexto. La función intenta añadir el nuevo objeto damon_call_control a la lista call_controls, que todavía tiene el puntero al objeto damon_call_control anterior, que está desasignado. Como resultado, ocurre un uso después de liberación.<br /> <br /> Esto puede ser realmente activado usando la interfaz sysfs de DAMON. Sin embargo, no es fácilmente explotable ya que requiere el permiso de escritura de sysfs y realizar escrituras de archivo definitivamente extrañas. Por favor, consulte el informe para más detalles sobre los pasos de reproducción del problema.<br /> <br /> Solucione el problema realizando dos cambios. En primer lugar, mueva la kdamond_call() final para cancelar todas las solicitudes damon_call() existentes del contexto DAMON que termina, para que se realice antes del reinicio de ctx-&amp;gt;kdamond. Esto hace que cualquier código que vea NULL en ctx-&amp;gt;kdamond pueda asumir con seguridad que el contexto ya no puede acceder a las solicitudes damon_call(). En segundo lugar, permita que damon_call() limpie los objetos damon_call_control que fueron añadidos al contexto DAMON ya terminado, antes de devolver el error.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: octeon_ep_vf: corregir la falta de coincidencia de dev_id de free_irq en la reversión de IRQ<br /> <br /> octep_vf_request_irqs() solicita IRQs de cola MSI-X con dev_id establecido en ioq_vector. Si request_irq() falla a mitad de camino, el bucle de reversión llama a free_irq() con dev_id establecido en &amp;#39;oct&amp;#39;, lo que no coincide con el dev_id original y puede dejar la irqaction registrada.<br /> <br /> Esto puede mantener los manejadores de IRQ activos mientras ioq_vector es liberado posteriormente durante el desenrollado/desmontaje, lo que lleva a un uso después de liberación o un fallo cuando se dispara una interrupción.<br /> <br /> Corregir la ruta de error para liberar IRQs con el mismo dev_id de ioq_vector utilizado durante request_irq().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> lib/buildid: usar __kernel_read() para contexto &amp;#39;sleepable&amp;#39;<br /> <br /> Prevenir un &amp;#39;BUG: unable to handle kernel NULL pointer dereference in filemap_read_folio&amp;#39;.<br /> <br /> Para el contexto &amp;#39;sleepable&amp;#39;, convertir freader para usar __kernel_read() en lugar del acceso directo a la caché de páginas a través de read_cache_folio(). Esto simplifica la ruta de código &amp;#39;faultable&amp;#39; al usar la interfaz estándar de lectura de archivos del kernel que maneja toda la complejidad de la lectura de datos de archivos.<br /> <br /> Por el momento no estamos cambiando el código para el contexto &amp;#39;non-sleepable&amp;#39; que usa filemap_get_folio() y solo tiene éxito si los folios objetivo ya están en memoria y actualizados. La razón es mantener el parche simple y más fácil de &amp;#39;backportear&amp;#39; a kernels estables.<br /> <br /> La reproducción de Syzbot ya no bloquea el kernel y las pruebas automáticas se ejecutan con éxito.<br /> <br /> En el seguimiento haremos que __kernel_read() con IOCB_NOWAIT funcione para contextos &amp;#39;non-sleepable&amp;#39;. Además, me gustaría reemplazar la verificación de secretmem con un enfoque más genérico y añadiré fstest para el código buildid.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()<br /> <br /> syzbot was able to crash the kernel in rt6_uncached_list_flush_dev()<br /> in an interesting way [1]<br /> <br /> Crash happens in list_del_init()/INIT_LIST_HEAD() while writing<br /> list-&gt;prev, while the prior write on list-&gt;next went well.<br /> <br /> static inline void INIT_LIST_HEAD(struct list_head *list)<br /> {<br /> WRITE_ONCE(list-&gt;next, list); // This went well<br /> WRITE_ONCE(list-&gt;prev, list); // Crash, @list has been freed.<br /> }<br /> <br /> Issue here is that rt6_uncached_list_del() did not attempt to lock<br /> ul-&gt;lock, as list_empty(&amp;rt-&gt;dst.rt_uncached) returned<br /> true because the WRITE_ONCE(list-&gt;next, list) happened on the other CPU.<br /> <br /> We might use list_del_init_careful() and list_empty_careful(),<br /> or make sure rt6_uncached_list_del() always grabs the spinlock<br /> whenever rt-&gt;dst.rt_uncached_list has been set.<br /> <br /> A similar fix is neeed for IPv4.<br /> <br /> [1]<br /> <br /> BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline]<br /> BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline]<br /> BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]<br /> BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020<br /> Write of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450<br /> <br /> CPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}<br /> Tainted: [L]=SOFTLOCKUP<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025<br /> Workqueue: netns cleanup_net<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xca/0x240 mm/kasan/report.c:482<br /> kasan_report+0x118/0x150 mm/kasan/report.c:595<br /> INIT_LIST_HEAD include/linux/list.h:46 [inline]<br /> list_del_init include/linux/list.h:296 [inline]<br /> rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]<br /> rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020<br /> addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853<br /> addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1<br /> notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85<br /> call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2282 [inline]<br /> netif_close_many+0x29c/0x410 net/core/dev.c:1785<br /> unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353<br /> ops_exit_rtnl_list net/core/net_namespace.c:187 [inline]<br /> ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248<br /> cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696<br /> process_one_work kernel/workqueue.c:3257 [inline]<br /> process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> <br /> Allocated by task 803:<br /> kasan_save_stack mm/kasan/common.c:57 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78<br /> unpoison_slab_object mm/kasan/common.c:340 [inline]<br /> __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366<br /> kasan_slab_alloc include/linux/kasan.h:253 [inline]<br /> slab_post_alloc_hook mm/slub.c:4953 [inline]<br /> slab_alloc_node mm/slub.c:5263 [inline]<br /> kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270<br /> dst_alloc+0x105/0x170 net/core/dst.c:89<br /> ip6_dst_alloc net/ipv6/route.c:342 [inline]<br /> icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333<br /> mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844<br /> mld_send_cr net/ipv6/mcast.c:2154 [inline]<br /> mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693<br /> process_one_work kernel/workqueue.c:3257 [inline]<br /> process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340<br /> worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421<br /> kthread+0x711/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr<br /> ---truncated---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ASoC: tlv320adcx140: corrección de puntero nulo<br /> <br /> El &amp;#39;snd_soc_component&amp;#39; en &amp;#39;adcx140_priv&amp;#39; solo se usó una vez pero nunca se configuró. Solo se usó para alcanzar &amp;#39;dev&amp;#39;, que ya está presente en &amp;#39;adcx140_priv&amp;#39;.