Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs:zoned: corrige el use-after-free debido a la ejecución con el reemplazo de desarrollo. Mientras cargamos la información de una zona durante la creación de un grupo de bloques, podemos ejecutar una operación de reemplazo de dispositivo y luego activar un use-after-free en el dispositivo que acaba de ser reemplazado (dispositivo fuente de la operación de reemplazo). Esto sucede porque en btrfs_load_zone_info() extraemos un dispositivo del mapa de fragmentos en una variable local y luego usamos el dispositivo mientras no está bajo la protección del dispositivo y reemplazamos rwsem. Entonces, si se produce una operación de reemplazo de dispositivo cuando extraemos el dispositivo y ese dispositivo es la fuente de la operación de reemplazo, activaremos un use-after-free si antes de terminar de usar el dispositivo la operación de reemplazo finaliza y libera el dispositivo. Solucione este problema ampliando la sección crítica bajo la protección del dispositivo y reemplace rwsem para que todos los usos del dispositivo se realicen dentro de la sección crítica.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: greybus: corrigió el error de use-after-free en gb_interface_release debido a la condición de ejecución. En gb_interface_create, &intf->mode_switch_completion está vinculado con gb_interface_mode_switch_work. Luego lo iniciará gb_interface_request_mode_switch. Aquí está el código relevante. if (!queue_work(system_long_wq, &intf->mode_switch_work)) { ... } Si llamamos a gb_interface_release para realizar la limpieza, es posible que haya un trabajo sin terminar. Esta función llamará a kfree para liberar el objeto "intf". Sin embargo, si gb_interface_mode_switch_work está programado para ejecutarse después de kfree, puede causar un error de use-after-free ya que gb_interface_mode_switch_work usará el objeto "intf". El posible flujo de ejecución que puede provocar el problema es el siguiente: CPU0 CPU1 | gb_interface_create | gb_interface_request_mode_switch gb_interface_release | kfree(intf) (gratis) | | gb_interface_mode_switch_work | mutex_lock(&intf->mutex) (uso) Solucionarlo cancelando el trabajo antes de kfree.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/shmem-helper: corrige BUG_ON() en mmap(PROT_WRITE, MAP_PRIVATE) La falta de verificación para el mapeo de copia en escritura (COW) en drm_gem_shmem_mmap permite a los usuarios llamar a mmap con Los indicadores PROT_WRITE y MAP_PRIVATE causan un pánico en el kernel debido a BUG_ON en vmf_insert_pfn_prot: BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags)); Devuelva -EINVAL temprano si se detecta el mapeo COW. Este error afecta a todos los controladores drm que utilizan ayudantes shmem predeterminados. Se puede reproducir con este sencillo ejemplo: void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset); ptr[0] = 0;

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vmci: evita fugas especulativas sanitizando el evento en event_deliver(). Coverity detectó que event_msg está controlado por el espacio de usuario, event_msg->event_data.event se pasa a event_deliver() y se usa como un índice sin sanitización. Este cambio garantiza que el índice de eventos esté sanitizado para mitigar cualquier posibilidad de fuga de información especulativa. Este error fue descubierto y resuelto utilizando Coverity Static Analysis Security Testing (SAST) por Synopsys, Inc. Solo se prueba la compilación, no hay acceso al hardware.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sock_map: evita la ejecución entre sock_map_close y sk_psock_put sk_psock_get devolverá NULL si el recuento de psock ha llegado a 0, lo que sucederá cuando se realice la última llamada de sk_psock_put. Sin embargo, es posible que sk_psock_drop aún no haya terminado, por lo que la devolución de llamada de cierre seguirá apuntando a sock_map_close a pesar de que psock sea NULL. Esto se puede reproducir con un hilo eliminando un elemento del mapa del calcetín, mientras que el segundo crea un socket, lo agrega al mapa y lo cierra. Eso activará WARN_ON_ONCE: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 7220 en net/core/sock_map.c :1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Módulos vinculados en: CPU: 1 PID: 7220 Comm: syz-executor380 No contaminado 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701 Código: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02 RSP : 0018:ffffc9000441fda8 EFLAGS: 00010293 RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000 RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0 RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3 R10: dffffc0000000000 R11: ffffbfff25f36c4 R12: ffffffff89731840 R13: 8804b587000 R14: ffff88804b587000 R15 : ffffffff89731870 FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0 Seguimiento de llamadas: unix_release+0x87/0xc0 net /unix/af_unix.c:1048 __sock_release net/socket.c:659 [en línea] sock_close+0xbe/0x240 net/socket.c:1421 __fput+0x42b/0x8a0 fs/file_table.c:422 __do_sys_close fs/open.c: 1556 [en línea] __se_sys_close fs/open.c:1541 [en línea] __x64_sys_close+0x7f/0x110 fs/open.c:1541 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86 /entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb37d618070 Código: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c RSP: 002b:00007ffcd4a525d8 GS: 00000202 ORIG_RAX: 0000000000000003 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070 RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004 RBP: 0000000000000000 R 08: 0000000100000000 R09: 0000000100000000 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 R13: 0000000000000000 0 R14: 0000000000000000 R15: 0000000000000000 Utilice sk_psock, que solo verificará que el puntero no esté configurado en NULL todavía, lo que solo debería suceder después de que se restablezcan las devoluciones de llamada. Si, entonces, aún se puede obtener una referencia, podemos llamar a sk_psock_stop y cancelar psock->work. Como sugirió Paolo Abeni, reordene la condición para que el flujo de control sea menos complicado. Después de ese cambio, el reproductor ya no activa WARN_ON_ONCE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ionic: corrige el use after de netif_napi_del() Cuando se inician las colas, se llama a netif_napi_add() y napi_enable(). Si hay 4 colas y solo se utilizan 3 colas para la configuración actual, solo se deben registrar y habilitar napi de 3 colas. ionic_qcq_enable() comprueba si el puntero .poll no es NULL para habilitar solo el napi de la cola de uso. netif_napi_add() no registrará el napi de las colas no utilizadas, por lo que el puntero .poll indica NULL. Pero no pudo distinguir si el napi no estaba registrado o no porque netif_napi_del() no restablece el puntero .poll a NULL. Entonces, ionic_qcq_enable() llama a napi_enable() para la cola, que netif_napi_del() canceló el registro. Reproductor: ethtool -L rx 1 tx 1 combinado 0 ethtool -L rx 0 tx 0 combinado 1 ethtool -L rx 0 tx 0 combinado 4 Splat se parece a: kernel ERROR en net/ núcleo/dev.c:6666! Vaya: código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1057 Comm: kworker/3:3 No contaminado 6.10.0-rc2+ #16 Cola de trabajo: eventos ionic_lif_deferred_work [ionic] RIP: 0010:napi_enable+0x3b/ 0x40 Código: 48 89 c2 48 83 e2 f6 80 b9 61 09 00 00 00 74 0d 48 83 bf 60 01 00 00 00 74 03 80 ce 01 f0 4f RSP: 0018:ffffb6ed83227d48 EFLAGS: 10246 RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28 RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 00000000001 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: 13ba0a20 FS: 0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS :0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0 PKRU: 5555554 Seguimiento de llamadas: ? morir+0x33/0x90? do_trap+0xd9/0x100? napi_enable+0x3b/0x40? do_error_trap+0x83/0xb0? napi_enable+0x3b/0x40? napi_enable+0x3b/0x40? exc_invalid_op+0x4e/0x70? napi_enable+0x3b/0x40? asm_exc_invalid_op+0x16/0x20? napi_enable+0x3b/0x40 ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224 ff7d10789e3f14643f8] ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8] ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a03543 6e1c4224ff7d10789e3f14643f8] proceso_one_work+0x145/0x360 trabajador_thread+0x2bb/ 0x3d0? __pfx_worker_thread+0x10/0x10 kthread+0xcc/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: ipset: corrige la ejecución entre la limpieza del espacio de nombres y gc en el tipo list:set Lion Ackermann informó que existe una condición de ejecución entre la limpieza del espacio de nombres en ipset y la recolección de basura de la lista : establecer tipo. La limpieza del espacio de nombres puede destruir el tipo list:set de conjuntos mientras el gc del tipo set espera ejecutarse en la limpieza de rcu. Este último utiliza datos del conjunto destruido, lo que lleva a un uso posterior al gratuito. El parche contiene las siguientes partes: - Al destruir todos los conjuntos, primero retire los recolectores de basura, luego espere si es necesario y luego destruya los conjuntos. - Se corrigió el error "esperar y luego eliminar gc" mal ordenado para destruir un solo caso de conjunto. - Corrija el bloqueo de rcu que falta en la lista: establezca el tipo en el caso de prueba del espacio de usuario. - Utilice el manejo adecuado de la lista de RCU en el tipo list:set. El parche depende de c1193d9bbbd3 (netfilter: ipset: Agregar lista vaciada a cancel_gc).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/komeda: verifique el puntero con valor de error komeda_pipeline_get_state() puede devolver un puntero con valor de error, por lo tanto, verifique el puntero en busca de valores negativos o nulos antes de eliminar la referencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: liquidio: ajusta una ruta de manejo de puntero NULL en lio_vf_rep_copy_packet En lio_vf_rep_copy_packet() pg_info->page se compara con un valor NULL, pero luego se pasa incondicionalmente a skb_add_rx_frag() lo cual parece extraño y podría provocar una desreferencia del puntero nulo. El seguimiento de llamadas de lio_vf_rep_copy_packet() se ve así: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...buscar en la lista de despacho... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *rec v_info, ...) En este camino hay No hay ningún código que establezca pg_info->page en NULL. Por lo tanto, esta verificación parece innecesaria y no resuelve el problema potencial. Pero supongo que el autor tenía motivos para agregar un cheque y yo no tengo esa tarjeta y no puedo hacer una prueba real. Además, el código de la función liquidio_push_packet() en liquidio/lio_core.c hace exactamente lo mismo. En base a esto, considero la solución de compromiso más aceptable para ajustar este problema moviendo skb_add_rx_frag() al alcance condicional. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

La configuración predeterminada de XSLTResourceStream.java es vulnerable a la ejecución remota de código mediante inyección XSLT cuando se procesa entrada de una fuente que no es de confianza sin validación. Se recomienda a los usuarios actualizar a las versiones 10.1.0, 9.18.0 u 8.16.0, que solucionan este problema.

El complemento MStore API – Create Native Android & iOS Apps On The Cloud para WordPress es vulnerable a la omisión de autenticación en todas las versiones hasta la 4.14.7 incluida. Esto se debe a una verificación insuficiente del parámetro 'phone' de las funciones 'firebase_sms_login' y 'firebase_sms_login_v2'. Esto hace posible que atacantes no autenticados inicien sesión como cualquier usuario existente en el sitio, como un administrador, si tienen acceso a la dirección de correo electrónico o al número de teléfono. Además, si se proporciona una nueva dirección de correo electrónico, se crea una nueva cuenta de usuario con la función predeterminada, incluso si el registro está deshabilitado.

El complemento Wallet for WooCommerce para WordPress es vulnerable a la inyección SQL a través del parámetro 'search[value]' en todas las versiones hasta la 1.5.4 incluida debido a un escape insuficiente en el parámetro proporcionado por el usuario y a la falta de preparación suficiente en el existente. Consulta SQL. Esto hace posible que los atacantes autenticados, con acceso a nivel de suscriptor y superior, agreguen consultas SQL adicionales a consultas ya existentes que pueden usarse para extraer información confidencial de la base de datos.