Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: sysctl: udp_port: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), p. ej. cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'net' se puede obtener de table->data usando Container_of(). Tenga en cuenta que table->data también se puede usar directamente, pero eso aumentaría el tamaño de esta corrección, mientras que 'sctp.ctl_sock' aún necesita ser recuperado de la estructura 'net'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: sysctl: rto_min/max: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), por ejemplo cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'net' se puede obtener de table->data usando Container_of(). Tenga en cuenta que table->data también se puede usar directamente, ya que este es el único miembro necesario de la estructura 'net', pero eso aumentaría el tamaño de esta corrección, para usar '*data' en todos los lugares donde se usa 'net->sctp.rto_min/max'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: sysctl: auth_enable: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), p. ej. cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'net' se puede obtener de table->data usando Container_of(). Tenga en cuenta que table->data también se puede usar directamente, pero eso aumentaría el tamaño de esta corrección, mientras que 'sctp.ctl_sock' aún necesita ser recuperado de la estructura 'net'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: sysctl: cookie_hmac_alg: evitar usar current->nsproxy Como se mencionó en un commit anterior de esta serie, no se recomienda usar la estructura 'net' a través de 'current' por diferentes razones: - Inconsistencia: obtener información de los netns del lector/escritor vs solo de los netns del abridor. - current->nsproxy puede ser NULL en algunos casos, lo que resulta en un 'Oops' (null-ptr-deref), por ejemplo cuando la tarea actual está saliendo, como lo detectó syzbot [1] usando acct(2). La estructura 'net' se puede obtener de table->data usando Container_of(). Tenga en cuenta que table->data también se puede usar directamente, ya que este es el único miembro necesario de la estructura 'net', pero eso aumentaría el tamaño de esta corrección, para usar '*data' en todos los lugares donde se use 'net->sctp.sctp_hmac_alg'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Asegúrese de que la pila de sombras esté activa antes de "obtener" registros El soporte de la pila de sombras x86 tiene su propio conjunto de registros. Esos registros son administrados por XSAVE, pero son "componentes de estado de supervisor", lo que significa que el espacio de usuario no puede tocarlos con XSAVE/XRSTOR. También significa que no son accesibles desde la ABI de ptrace existente para el estado XSAVE. Por lo tanto, hay una nueva interfaz get/set de ptrace para ello. El código de conjunto de registros que usa ptrace proporciona un controlador ->active() además de los de obtención/configuración. Para la pila de sombras, este controlador ->active() verifica que la pila de sombras esté habilitada a través del bit ARCH_SHSTK_SHSTK en la estructura del hilo. El controlador ->active() se verifica desde algunos sitios de llamada de los controladores get/set de conjuntos de registros, pero no de los de ptrace. Esto no se comprendió cuando se implementó el soporte de la pila de sombras. Como resultado, ambos manejadores set/get pueden ser llamados con XFEATURE_CET_USER en su estado init, lo que haría que get_xsave_addr() devuelva NULL y active un WARN_ON(). El manejador ssp_set() afortunadamente tiene una verificación ssp_active() para evitar sorprender al kernel con el comportamiento de la pila shadow cuando el kernel no está listo para ello (ARCH_SHSTK_SHSTK==0). Esa verificación simplemente sucedió para evitar la advertencia. Pero el lado ->get() no tuvo tanta suerte. Puede ser llamado con las pilas shadow deshabilitadas, lo que activa la advertencia en la práctica, como lo informó Christina Schimpe: ADVERTENCIA: CPU: 5 PID: 1773 en arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0 [...] Seguimiento de llamadas: ? show_regs+0x6e/0x80 ? ssp_get+0x89/0xa0 ? __warn+0x91/0x150 ? ssp_get+0x89/0xa0 ? report_bug+0x19d/0x1b0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x1d/0x80 ? asm_exc_invalid_op+0x1f/0x30 ? __pfx_ssp_get+0x10/0x10 ? ssp_get+0x89/0xa0 ? ssp_get+0x52/0xa0 __regset_get+0xad/0xf0 copy_regset_to_user+0x52/0xc0 ptrace_regset+0x119/0x140 ptrace_request+0x13c/0x850 ? wait_task_inactive+0x142/0x1d0 ? do_syscall_64+0x6d/0x90 arch_ptrace+0x102/0x300 [...] Asegúrese de que las pilas de sombras estén activas en un hilo antes de buscarlas en el búfer XSAVE. Dado que ARCH_SHSTK_SHSTK y user_ssp[SHSTK_EN] se configuran al mismo tiempo, la comprobación activa garantiza que habrá algo que encontrar en el búfer XSAVE. [ dhansen: registro de cambios/asunto ajustes ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cgroup/cpuset: eliminar kernfs active break Se encontró una advertencia: ADVERTENCIA: CPU: 10 PID: 3486953 en fs/kernfs/file.c:828 CPU: 10 PID: 3486953 Comm: rmdir Kdump: cargado Tainted: G RIP: 0010:kernfs_should_drain_open_files+0x1a1/0x1b0 RSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202 RAX: 0000000080000002 RBX: ffff888154738c00 RCX: dffffc0000000000 RDX: 00000000000000007 RSI: 0000000000000004 RDI: ffff888154738c04 RBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180 R10: ffff888154738c07 R11: 0000000000000000 R12: ffff888154738c08 R13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0 FS: 00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: GS:ffff8887ddc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: kernfs_drain+0x15e/0x2f0 __kernfs_remove+0x165/0x300 kernfs_remove_by_name_ns+0x7b/0xc0 cgroup_rm_file+0x154/0x1c0 cgroup_addrm_files+0x1c2/0x1f0 css_clear_dir+0x77/0x110 kill_css+0x4c/0x1b0 cgroup_destroy_locked+0x194/0x380 cgroup_rmdir+0x2a/0x140 Se puede explicar por: rmdir echo 1 > cpuset.cpus kernfs_fop_write_iter // active=0 cgroup_rm_file kernfs_remove_by_name_ns kernfs_get_active // ??activo=1 __kernfs_remove // ??activo=0x80000002 kernfs_drain cpuset_write_resmask wait_event //esperando (activo == 0x80000001) kernfs_break_active_protection // activo = 0x80000001 // continuar kernfs_unbreak_active_protection // activo = 0x80000002 ... kernfs_should_drain_open_files // se produce una advertencia kernfs_put_active Esta advertencia es causada por 'kernfs_break_active_protection' cuando está escribiendo en cpuset.cpus y el cgroup se elimina simultáneamente. El commit 3a5a6d0c2b03 ("cpuset: no anide cgroup_mutex dentro de get_online_cpus()") hizo que cpuset_hotplug_workfn sea asíncrono. Este cambio implica llamar a flush_work(), que puede crear una dependencia de bloqueo circular de múltiples procesos que involucran a cgroup_mutex, lo que puede llevar a un bloqueo. Para evitarlo, el commit 76bb5ab8f6e3 ("cpuset: interrumpa la protección activa de kernfs en cpuset_write_resmask()") agregó 'kernfs_break_active_protection' en cpuset_write_resmask. Esto podría llevar a esta advertencia. Después de el commit 2125c0034c5d ("cgroup/cpuset: haga que el procesamiento de hotplug de cpuset sea sincrónico"), cpuset_write_resmask ya no necesita esperar a que finalice el hotplug, lo que significa que las operaciones de hotplug y cpuset concurrentes ya no son posibles. Por lo tanto, el bloqueo ya no existe y ya no es necesario "interrumpir la protección activa". Para solucionar esta advertencia, simplemente elimine la operación kernfs_break_active_protection en "cpuset_write_resmask".

En kernel de linux, se ha resuelto la siguiente vulnerabilidad: io_uring/sqpoll: cero errores sqd->thread en tctx Syzkeller informa: BUG: KASAN: slab-use-after-free in thread_group_cputime+0x409/0x700 kernel/sched/cputime.c:341 Read of size 8 at addr ffff88803578c510 by task syz.2.3223/27552 Call Trace: ... kasan_report+0x143/0x180 mm/kasan/report.c:602 thread_group_cputime+0x409/0x700 kernel/sched/cputime.c:341 thread_group_cputime_adjusted+0xa6/0x340 kernel/sched/cputime.c:639 getrusage+0x1000/0x1340 kernel/sys.c:1863 io_uring_show_fdinfo+0xdfe/0x1770 io_uring/fdinfo.c:197 seq_show+0x608/0x770 fs/proc/fd.c:68... Esto se debe a que sqd->task no se borra correctamente en los casos en que falla la configuración de tctx de la tarea SQPOLL, lo que esencialmente solo puede ocurrir con errores de inyección de errores en la asignación de insertos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block, bfq: fix waker_bfqq UAF after bfq_split_bfqq() Our syzkaller report a following UAF for v6.6: BUG: KASAN: slab-use-after-free in bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958 Read of size 8 at addr ffff8881b57147d8 by task fsstress/232726 CPU: 2 PID: 232726 Comm: fsstress Not tainted 6.6.0-g3629d1885222 #39 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364 print_report+0x3e/0x70 mm/kasan/report.c:475 kasan_report+0xb8/0xf0 mm/kasan/report.c:588 hlist_add_head include/linux/list.h:1023 [inline] bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958 bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271 bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323 blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660 blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143 __submit_bio+0xa0/0x6b0 block/blk-core.c:639 __submit_bio_noacct_mq block/blk-core.c:718 [inline] submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747 submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847 __ext4_read_bh fs/ext4/super.c:205 [inline] ext4_read_bh+0x15e/0x2e0 fs/ext4/super.c:230 __read_extent_tree_block+0x304/0x6f0 fs/ext4/extents.c:567 ext4_find_extent+0x479/0xd20 fs/ext4/extents.c:947 ext4_ext_map_blocks+0x1a3/0x2680 fs/ext4/extents.c:4182 ext4_map_blocks+0x929/0x15a0 fs/ext4/inode.c:660 ext4_iomap_begin_report+0x298/0x480 fs/ext4/inode.c:3569 iomap_iter+0x3dd/0x1010 fs/iomap/iter.c:91 iomap_fiemap+0x1f4/0x360 fs/iomap/fiemap.c:80 ext4_fiemap+0x181/0x210 fs/ext4/extents.c:5051 ioctl_fiemap.isra.0+0x1b4/0x290 fs/ioctl.c:220 do_vfs_ioctl+0x31c/0x11a0 fs/ioctl.c:811 __do_sys_ioctl fs/ioctl.c:869 [inline] __se_sys_ioctl+0xae/0x190 fs/ioctl.c:857 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Allocated by task 232719: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:768 [inline] slab_alloc_node mm/slub.c:3492 [inline] kmem_cache_alloc_node+0x1b8/0x6f0 mm/slub.c:3537 bfq_get_queue+0x215/0x1f00 block/bfq-iosched.c:5869 bfq_get_bfqq_handle_split+0x167/0x5f0 block/bfq-iosched.c:6776 bfq_init_rq+0x13a4/0x17a0 block/bfq-iosched.c:6938 bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271 bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323 blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660 blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143 __submit_bio+0xa0/0x6b0 block/blk-core.c:639 __submit_bio_noacct_mq block/blk-core.c:718 [inline] submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747 submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847 __ext4_read_bh fs/ext4/super.c:205 [inline] ext4_read_bh_nowait+0x15a/0x240 fs/ext4/super.c:217 ext4_read_bh_lock+0xac/0xd0 fs/ext4/super.c:242 ext4_bread_batch+0x268/0x500 fs/ext4/inode.c:958 __ext4_find_entry+0x448/0x10f0 fs/ext4/namei.c:1671 ext4_lookup_entry fs/ext4/namei.c:1774 [inline] ext4_lookup.part.0+0x359/0x6f0 fs/ext4/namei.c:1842 ext4_lookup+0x72/0x90 fs/ext4/namei.c:1839 __lookup_slow+0x257/0x480 fs/namei.c:1696 lookup_slow fs/namei.c:1713 [inline] walk_component+0x454/0x5c0 fs/namei.c:2004 link_path_walk.part.0+0x773/0xda0 fs/namei.c:2331 link_path_walk fs/namei.c:3826 [inline] path_openat+0x1b9/0x520 fs/namei.c:3826 do_filp_open+0x1b7/0x400 fs/namei.c:3857 do_sys_openat2+0x5dc/0x6e0 fs/open.c:1428 do_sys_open fs/open.c:1443 [inline] __do_sys_openat fs/open.c:1459 [inline] __se_sys_openat fs/open.c:1454 [inline] __x64_sys_openat+0x148/0x200 fs/open.c:1454 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_6 ---truncado---

Se ha detectado una vulnerabilidad clasificada como problemática en Epic Games Launcher hasta la versión 17.2.1. Esta vulnerabilidad afecta a código desconocido en el archivo librería profapi.dll del componente Installer. La manipulación conduce a una ruta de búsqueda no confiable. Es necesario atacar localmente. La complejidad de un ataque es bastante alta. La explotación parece ser difícil.

Se ha encontrado una vulnerabilidad clasificada como crítica en Tenda AC15 15.13.07.13. Afecta a la función formSetDevNetName del archivo /goform/SetDevNetName. La manipulación del argumento mac provoca un desbordamiento del búfer basado en la pila. Es posible iniciar el ataque de forma remota. El exploit se ha hecho público y puede utilizarse.

Se encontró una vulnerabilidad en ZZCMS 2023. Se la ha calificado como crítica. Este problema afecta a algunas funciones desconocidas del archivo /index.php. La manipulación del argumento id conduce a una inyección SQL. El ataque puede ejecutarse de forma remota. El exploit se ha revelado al público y puede utilizarse.

El complemento Import any XML or CSV File to WordPress PRO para WordPress es vulnerable a Cross-Site Scripting Almacenado a través de cargas de archivos SVG en todas las versiones hasta incluida, 4.9.7 debido a un escape de entrada desinfección y de salida insuficiente. Esto hace posible que atacantes autenticados, con acceso de nivel de administrador y superior, inyecten Scripts web arbitraria en páginas que se ejecutarán cada vez que un usuario acceda al archivo SVG.