Vulnerabilidades

El complemento Accessibility by AllAccessible para WordPress es vulnerable a modificaciones no autorizadas de datos que pueden provocar una escalada de privilegios debido a una falta de verificación de capacidad en la función 'AllAccessible_save_settings' en todas las versiones hasta la 1.3.4 incluida. Esto permite que atacantes autenticados, con acceso de nivel de suscriptor y superior, actualicen opciones arbitrarias en el sitio de WordPress. Esto se puede aprovechar para actualizar el rol predeterminado para el registro como administrador y habilitar el registro de usuarios para que los atacantes obtengan acceso de usuario administrativo a un sitio vulnerable.

La aplicación GriceMobile com.grice.call 4.5.2 para Android permite que cualquier aplicación instalada (sin permisos) realice llamadas telefónicas sin interacción del usuario enviando una intención manipulada a través de com.iui.mobile.presentation.MobileActivity.

La aplicación Mister org.mistergroup.shouldianswer 1.4.264 para Android permite que cualquier aplicación instalada (sin permisos) realice llamadas telefónicas sin interacción del usuario enviando una intención manipulada a través del componente org.mistergroup.shouldianswer.ui.default_dialer.DefaultDialerActivity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: termina el volcado pendiente al cerrar el socket Netlink admite el volcado iterativo de datos. Proporciona a las familias las siguientes operaciones: - start - (opcional) inicia el proceso de volcado - dump - asistente de volcado real, se sigue llamando hasta que devuelve 0 - done - (opcional) se empareja con .start, se puede usar para limpieza Todo el proceso es asincrónico y las llamadas repetidas a .dump en realidad no ocurren en un bucle cerrado, sino que se activan en respuesta a recvmsg() en el socket. Esto le da al usuario control total sobre el volcado, pero también significa que el usuario puede cerrar el socket sin llegar al final del volcado. Para asegurarnos de que .start siempre esté emparejado con .done, verificamos si hay un volcado en curso antes de liberar el socket y, si es así, llamamos a .done. La complicación es que los sockets pueden liberarse de BH y se permite que .done duerma. Entonces, usamos una cola de trabajo para diferir la llamada, cuando sea necesario. Lamentablemente, esto no funciona correctamente. Lo que postergamos no es la limpieza, sino la liberación de una referencia en el socket. No tenemos garantía de que seamos dueños de la última referencia; si alguien más tiene el socket, puede liberarlo en BH y volvemos al punto de partida. Sin embargo, todo el baile parece ser innecesario. Solo el usuario puede interactuar con los volcados, por lo que podemos limpiar cuando se cierra el socket. Y el cierre siempre ocurre en el contexto del proceso. Es posible que algún código asincrónico aún acceda al socket después del cierre, ponga en cola skbs de notificación, etc., pero ningún volcado puede comenzar, finalizar o avanzar de otro modo. Elimine la cola de trabajo y vacíe el estado del volcado directamente desde el controlador de liberación. Tenga en cuenta que es posible realizar una desinfección adicional en -next, por ejemplo, ahora siempre llamamos a .done antes de liberar la referencia del módulo principal, por lo que el volcado no tiene que tomar una referencia propia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: corregir posible UAF en sctp_v6_available() Un informe de lockdep [1] con CONFIG_PROVE_RCU_LIST=y sugiere que sctp_v6_available() está llamando a dev_get_by_index_rcu() e ipv6_chk_addr() sin retener rcu. [1] ============================= ADVERTENCIA: uso sospechoso de RCU 6.12.0-rc5-virtme #1216 Tainted: GW ----------------------------- net/core/dev.c:876 ¡Lista de RCU recorrida en una sección que no es de lectura! Otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 1 bloqueo mantenido por sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, en: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) seguimiento de pila sctp: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Contaminado: GW 6.12.0-rc5-virtme #1216 Contaminado: [W]=WARN Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminador 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminador 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (seguridad/seguridad.c:4581 (discriminador 1)) __sys_bind (red/socket.c:1848 red/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminador 13) ./include/linux/rcupdate.h:98 (discriminador 13) ./include/linux/rcupdate.h:882 (discriminador 13) ./include/linux/mm.h:729 (discriminador 13) arch/x86/mm/fault.c:1340 (discriminador 13)) __x64_sys_bind (net/socket.c:1877 (discriminador 1) net/socket.c:1875 (discriminador 1) net/socket.c:1875 (discriminador 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminador 1) arch/x86/entry/common.c:83 (discriminador 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Código: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 Todo el código ======== 0: 44 00 00 agregar %r8b,(%rax) 3: 48 8b 15 39 8c 0c 00 mov 0xc8c39(%rip),%rdx # 0xc8c43 a: f7 d8 neg %eax c: 64 89 02 mov %eax,%fs:(%rdx) f: b8 ff ff ff ff mov $0xffffffff,%eax 14: eb bd jmp 0xffffffffffffffd3 16: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) 1d: 00 00 00 20: 0f 1f 00 nopl (%rax) 23: b8 31 00 00 00 mov $0x31,%eax 28: 0f 05 syscall 2a:* 48 3d 01 f0 ff ff cmp $0xffffffffffffff001,%rax <-- instrucción de captura 30: 73 01 jae 0x33 32: c3 ret 33: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c43 3a: f7 d8 neg %eax 3c: 64 89 01 mov %eax,%fs:(%rcx) 3f: 48 rex.W Código que comienza con la instrucción que falla =============================================== 0: 48 3d 01 f0 ff ff cmp $0xffffffffffffff001,%rax 6: 73 01 jae 0x9 8: c3 ret 9: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c19 10: f7 d8 neg %eax 12: 64 89 01 mov %eax,%fs:(%rcx) 15: 48 rex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 0000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 00000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/oa: Se corrige la advertencia "Falta protección de PM en tiempo de ejecución externo" Se corrige el siguiente drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Falta protección de PM en tiempo de ejecución externo... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (seleccionado de el commit b107c63d2953907908fd0cafb0e543b3c3167b75)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Controlar el error de asignación de dml para evitar un bloqueo [Por qué] En el caso de que una asignación de dml falle por cualquier motivo, los contextos dml del estado actual ya no serían válidos. Luego, las llamadas posteriores a dc_state_copy_internal realizarían una copia superficial de la memoria no válida y, si se liberara el nuevo estado, se produciría una doble liberación. [Cómo] Restablecer los punteros dml en new_state a NULL y evitar un puntero no válido (seleccionado de el commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pmdomain: imx93-blk-ctrl: ruta de eliminación correcta La condición de comprobación debe ser 'i < bc->onecell_data.num_domains', no 'bc->onecell_data.num_domains', que hará que la búsqueda nunca finalice y provoque un pánico del kernel. También deshabilite el tiempo de ejecución para solucionar "imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: reparar cacheflush con PAN Parece que la llamada al sistema cacheflush se rompió cuando se implementó PAN para LPAE. El acceso de usuario no estaba habilitado en torno a las instrucciones de mantenimiento de caché, lo que provocó que fallaran.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Serie de parches "nilfs2: fix null-ptr-deref bugs on block tracepoints". Esta serie corrige errores de desreferencia de puntero nulo que ocurren al usar nilfs2 y dos puntos de seguimiento relacionados con bloques. Este parche (de 2): Se ha informado que al usar el punto de seguimiento "block:block_touch_buffer", touch_buffer() llamado desde __nilfs_get_folio_block() causa una desreferencia de puntero NULL o un error de protección general cuando KASAN está habilitado. Esto sucede porque, dado que el punto de seguimiento se agregó en touch_buffer(), hace referencia al miembro dev_t bh->b_bdev->bd_dev independientemente de si el cabezal del búfer tiene un puntero a una estructura block_device. En la implementación actual, la estructura block_device se establece después de que la función regresa al llamador. Aquí, touch_buffer() se utiliza para marcar el folio/página que posee el encabezado del búfer como accedido, pero el asistente de búsqueda común para folio/página utilizado por la función de llamada se optimizó para marcar el folio/página como accedido cuando se reimplementó hace mucho tiempo, eliminando la necesidad de llamar a touch_buffer() aquí en primer lugar. Por lo tanto, esto resuelve el problema al eliminar la llamada a touch_buffer() en sí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: VMX: oculta la virtualización de Intel PT (modo invitado/host) detrás de CONFIG_BROKEN Oculta el parámetro del módulo pt_mode de KVM detrás de CONFIG_BROKEN, es decir, deshabilita la compatibilidad con la virtualización de Intel PT a través del modo invitado/host a menos que BROKEN=y. Hay una gran cantidad de errores en la implementación, algunos de los cuales son fatales para el invitado y otros que ponen en riesgo la estabilidad y la salud del host. Para las fatalidades del invitado, el problema más evidente es que KVM no garantiza que el seguimiento esté deshabilitado y *permanece* deshabilitado antes de VM-Enter, lo que es necesario ya que el hardware no permite cargar RTIT_CTL (del invitado) si el seguimiento está habilitado (lo que se aplica a través de una verificación de consistencia de VMX). Según el SDM: si el procesador lógico está funcionando con Intel PT habilitado (si IA32_RTIT_CTL.TraceEn = 1) en el momento de la entrada de la VM, el control de entrada de la VM "cargar IA32_RTIT_CTL" debe ser 0. En el lado del host, KVM no valida la configuración de CPUID del invitado proporcionada por el espacio de usuario y, lo que es peor, utiliza la configuración del invitado para decidir qué MSR guardar/cargar en VM-Enter y VM-Exit. Por ejemplo, configurar la CPUID del invitado para enumerar más rangos de direcciones de los que admite el hardware hará que KVM intente pasar, guardar y cargar MSR inexistentes, lo que genera una variedad de WARN, ERRORES ToPA en el host, un posible bloqueo, etc.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: revert "mm: shmem: fix data-race in shmem_getattr()" Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") como lo sugirió Chuck [1]. Está causando bloqueos al acceder a tmpfs a través de NFS. Como comentó Hugh, "agregado solo para silenciar un splat de sanitizador de syzbot: agregado donde nunca ha habido ningún problema práctico".