Vulnerabilidades

El complemento Elementor Templates & Widgets for WooCommerce de Envo para WordPress es vulnerable a modificaciones no autorizadas de datos debido a una falta de verificación de capacidad en la función templates_ajax_request en todas las versiones hasta la 1.4.4 incluida. Esto hace posible que los suscriptores y superiores creen plantillas.

El complemento Elementor Templates & Widgets for WooCommerce de Envo para WordPress es vulnerable a la Cross-Site Request Forgery en versiones hasta la 1.4.4 incluida. Esto se debe a una validación nonce faltante o incorrecta en la función ajax_plugin_activation. Esto hace posible que atacantes no autenticados activen complementos instalados arbitrariamente a través de una solicitud falsificada, siempre que puedan engañar al administrador del sitio para que realice una acción como hacer clic en un enlace.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet-tcp: corrige el bloqueo incorrecto en la devolución de llamada de state_change sk No estamos cambiando nada en el estado de la conexión TCP, por lo que no debemos tomar un bloqueo de escritura sino un bloqueo de lectura. Esto causó un punto muerto al ejecutar nvmet-tcp y nvme-tcp en el mismo sistema, donde las devoluciones de llamada state_change en el host y en el lado del controlador tienen una relación causal y generaron un informe de lockdep sobre esto con blktests: ========= ======================= ADVERTENCIA: estado de bloqueo inconsistente 5.12.0-rc3 #1 Contaminado: GI ------------ -------------------- uso inconsistente de {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R}. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] toma: ffff888363151000 (reloj-AF_INET){++-?}-{2:2}, en: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] { IN-SOFTIRQ-W} el estado se registró en: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue +0xf94/0x1f20 tcp_rcv_establecido+0x6ba/0x1f00 tcp_v4_do_rcv +0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive _skb_one_core+0x162/0x1b0 proceso_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+ 0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0 x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+ 0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nv me_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xae Sello de evento irq: 10687 hardirqs habilitado por última vez en (10687): [] _raw_spin_unlock _irqrestore+0x2d/0x40 hardirqs se deshabilitó por última vez en (10686) : [] _raw_spin_lock_irqsave+0x68/0x90 softirqs habilitado por última vez en (10684): [] __do_softirq+0x608/0x940 softirqs deshabilitado por última vez en (10649): [] do_softirq+0xa1 /0xd0 otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(clock-AF_INET); bloqueo(reloj-AF_INET); *** DEADLOCK *** 5 bloqueos retenidos por nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, en: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of ->mutex){+.+.}-{3:3}, en: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, en : kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, en: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF _INET){+ .+.}-{0:0}, en: inet_shutdown+0x59/0x300 seguimiento de pila: CPU: 26 PID: 1324 Comunicaciones: nvme Contaminado: GI 5.12.0-rc3 #1 Nombre de hardware: Dell Inc. PowerEdge R640/06NR82 , BIOS 2.10.0 12/11/2020 Seguimiento de llamadas: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3? verificar_lock_unused+0x390/0x390? stack_trace_consume_entry+0x160/0x160? lock_downgrade+0x100/0x100? save_trace+0x88/0x5e0? _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40? tcp_mtu_probe+0x1ae0/0x1ae0? kmalloc_reserve+0xa0/0xa0? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: datos locales gratuitos después de su uso. Corrige la siguiente pérdida de memoria en dc_link_construct(): objeto sin referencia 0xffffa03e81471400 (tamaño 1024): comm "amd_module_load", pid 2486, jiffies 4294946026 (edad 10,544 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso: [<000000000bdf5c4a>] kmem_cache_alloc_trace+0x30a/0x4a0 [<00000000e7c59f0e>] link_create+0xce/0xac0 [amdgpu] [<000000002fb6c072>] dc_create+0x370/0x720 [amdgpu] [<000000000094d1f3>] amdgpu_dm_init+0x18e/0x17a0 [amdgpu] [<00000000bec048fd>] dm_hw_in es+0x12/0x20 [amdgpu] [<00000000a2bb7cf6>] amdgpu_device_init+0x1463 /0x1e60 [amdgpu] [<0000000032d3bb13>] amdgpu_driver_load_kms+0x5b/0x330 [amdgpu] [<00000000a27834f9>] amdgpu_pci_probe+0x192/0x280 [amdgpu] [<00000000fec7d29 1>] local_pci_probe+0x47/0xa0 [<0000000055dbbfa7>] pci_device_probe+0xe3/ 0x180 [<00000000815da970>] very_probe+0x1c4/0x4e0 [<00000000b4b6974b>] driver_probe_device+0x62/0x150 [<000000000f9ecc61>] device_driver_attach+0x58/0x60 [<0000000 00f65c843>] __driver_attach+0xd6/0x150 [<000000002f5e3683>] bus_for_each_dev+0x6a/ 0xc0 [<00000000a1cfc897>] controlador_attach+0x1e/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: core: corrige algunas fugas de recursos en la ruta de error de 'venus_probe()' Si se produce un error después de una llamada exitosa a 'of_icc_get()', se debe deshacer . Utilice 'devm_of_icc_get()' en lugar de 'of_icc_get()' para evitar la fuga. Actualice la función de eliminación en consecuencia y elimine las llamadas 'icc_put()' ahora innecesarias.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched/fair: corrigió el desplazamiento fuera de los límites en load_balance() Syzbot informó sobre varios casos en los que sd->nr_balance_failed puede crecer a valores mucho más altos de lo que uno esperaría. . Un load_balance() exitoso lo restablece a 0; uno fallido lo incrementa. Una vez que llegue a sd->cache_nice_tries + 3, esto *debería* activar un saldo activo, que lo establecerá en sd->cache_nice_tries+1 o lo restablecerá a 0. Sin embargo, en caso de que el saldo esté activo La tarea no puede ejecutarse en env->dst_cpu, entonces el incremento se realiza sin ninguna modificación adicional. Esto podría repetirse hasta la saciedad y explicaría los valores absurdamente altos informados por syzbot (86, 149). VincentG señaló que es valioso dejar que sd->cache_nice_tries crezca, por lo que el cambio en sí debería corregirse. Eso significa evitar: """ Si el valor del operando derecho es negativo o es mayor o igual que el ancho del operando izquierdo promocionado, el comportamiento no está definido. """ Por lo tanto, debemos limitar el exponente de desplazamiento a BITS_PER_TYPE( typeof(lefthand)) - 1. Eché un vistazo a otros casos similares a través de coccinelle: @expr@ position pos; expresión E1; expresión E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depende de expr@ posición pos; expresión expr.E1; cst constante; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depende de !cst@ pos << expr.pos; exp << expr.E2; @@ # Truco sucio para ignorar constexpr if exp.upper() != exp: coccilib.report.print_report(pos[0], "Posible cambio de UB aquí") La única otra coincidencia en kernel/sched es rq_clock_thermal() que emplea sched_thermal_decay_shift, y ese exponente ya está limitado a 10, por lo que ese está bien.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: corrige la desreferencia del puntero nulo en lpfc_prep_els_iocb() Es posible llamar a lpfc_issue_els_plogi() pasando un did para el cual no se encuentra ningún ndlp coincidente. Luego se realiza una llamada a lpfc_prep_els_iocb() con un puntero nulo a una estructura lpfc_nodelist, lo que da como resultado una desreferencia del puntero nulo. Corrija devolviendo un estado de error si no se encuentra ningún ndlp válido. Corrija los comentarios sobre el recuento de referencias de ndlp.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrección por uno en hdmi_14_process_transaction() La matriz hdcp_i2c_offsets[] no tenía una entrada para HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE, por lo que provocó un desbordamiento de lectura desactivado por uno. Agregué una entrada y copié el valor 0x0 para el desplazamiento de un código similar en drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. También declaré que varias de estas matrices tenían entradas HDCP_MESSAGE_ID_MAX. Esto no cambia el código, pero es solo un enfoque de cinturón y tirantes para probar el código a prueba de futuro.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: spi-zynqmp-gqspi: devuelve -ENOMEM si falla dma_map_single El controlador spi admite espacio de direcciones de 44 bits en AXI en modo DMA, por lo tanto, configure el ancho de dma_addr_t en 44 bits para Evite el uso de un mapeo swiotlb. Además, si dma_map_single falla, debería regresar inmediatamente en lugar de continuar realizando la operación DMA que se basa en una dirección no válida. Esto corrige el siguiente fallo que se produce al leer un bloque grande desde flash: [123.633577] zynqmp-qspi ff0f0000.spi: el búfer swiotlb está lleno (tamaño: 4194304 bytes), total 32768 (ranuras), usado 0 (ranuras) [123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memoria no asignada [123.784625] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 00000000003fffc0 [123.792536] Información de cancelación de memoria: [123.795313] ESR = 0x96000145 [1 23.798351] EC = 0x25: DABT (actual EL), IL = 32 bits [ 123.803655] SET = 0, FnV = 0 [ 123.806693] EA = 0, S1PTW = 0 [ 123.809818] Información de cancelación de datos: [ 123.812683] ISV = 0, ISS = 0x00000145 [ 123.816503] CM = 1 , WnR = 1 [ 123.819455] tabla de páginas de usuario: 4k páginas, VA de 48 bits, pgdp=0000000805047000 [ 123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=000000080 3b45003, pud=0000000000000000 [123.834586] Error interno: Ups: 96000145 [#1 ] ADVERTENCIA SMP

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: spi-zynqmp-gqspi: corrige use-after-free en zynqmp_qspi_exec_op Al manejar op->addr, se utiliza el buffer "tmpbuf" que ha sido liberado. Esto activará una advertencia de KASAN de use-after-free. Usemos variables temporales para almacenar op->addr.val y op->cmd.opcode para solucionar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Controladores: hv: vmbus: Usar después de liberar en __vmbus_open() La variable "open_info" se agrega a &vmbus_connection.chn_msg_list, pero el manejo de errores libera "open_info" sin eliminarlo de la lista. Esto resultará en un uso posterior gratuito. Primero elimínelo de la lista y luego libérelo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memoria: renesas-rpc-if: corrige posible desreferencia del puntero NULL del recurso Platform_get_resource_byname() puede devolver NULL, que sería inmediatamente desreferenciado por Resource_size(). En su lugar, elimine la referencia después de validar el recurso. Direcciones-Cobertura: Desreferencia valor de retorno nulo