Vulnerabilidades

Zohocorp ManageEngine OpManager, OpManager Plus, OpManager MSP y RMM versiones 128317 e inferiores son vulnerables a la inyección de SQL autenticado en la supervisión de URL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftruncate: pasa un desplazamiento firmado La antigua llamada al sistema ftruncate(), que utiliza off_t de 32 bits, pierde una extensión de signo cuando se llama en modo de compatibilidad en arquitecturas de 64 bits. Como resultado, pasar una longitud negativa accidentalmente logra truncar el tamaño del archivo entre 2GiB y 4GiB. Cambiar el tipo de llamada al sistema compat a compat_off_t firmado cambia el comportamiento, por lo que en su lugar devuelve -EINVAL. El punto de entrada nativo, la llamada al sistema truncate() y las variantes correspondientes basadas en loff_t ya son correctas y no sufren este error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: core: elimina el bloqueo del modo otg durante la suspensión/reanudación del dispositivo para evitar un punto muerto Cuando se selecciona config CONFIG_USB_DWC3_DUAL_ROLE y activa el sistema para que entre en estado de suspensión con el siguiente comando: echo mem > /sys/power/state Se producirá un problema de interbloqueo. Ruta de invocación detallada como se muestra a continuación: dwc3_suspend_common() spin_lock_irqsave(&dwc->lock, flags); <-- 1er dwc3_gadget_suspend(dwc); dwc3_gadget_soft_disconnect(dwc); spin_lock_irqsave(&dwc->bloquear, banderas); <-- 2.º Este problema se expone mediante la confirmación c7ebd8149ee5 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend") que elimina el código para verificar si dwc->gadget_driver es NULL o no. Hace que se ejecute el siguiente código y se produzca un punto muerto al intentar obtener el bloqueo de giro. De hecho, la causa principal es la confirmación 5265397f9442("usb: dwc3: Eliminar el bloqueo de DWC3 durante la suspensión/reanudación del dispositivo") que olvidó eliminar el bloqueo del modo otg. Por lo tanto, elimine el bloqueo redundante del modo otg durante la suspensión/reanudación del dispositivo.

En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: iio:chemical:bme680: Corregir desbordamientos en funciones de compensación(). Hay casos en las funciones de compensación del controlador en los que se pueden producir desbordamientos de variables por operaciones de cambio de bits. Estas implicaciones se discutieron inicialmente aquí [1] y se mencionaron en el mensaje de registro del compromiso 1b3bd8592780 ("iio: químico: agregar soporte para el sensor Bosch BME680"). [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panel: ilitek-ili9881c: Advertencia de corrección con controladores GPIO en suspensión El ilitek-ili9881c controla el GPIO restablecido usando la función gpiod_set_value() que no está en suspensión. Esto se queja ruidosamente cuando el controlador GPIO necesita dormir. Como la persona que llama puede dormir, use gpiod_set_value_cansleep() para solucionar el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: fsl-asoc-card: establezca priv->pdev antes de usarlo. El puntero priv->pdev se configuró después de usarse en fsl_asoc_card_audmux_init(). Mueva esta asignación al inicio de la función de sonda, para que las subfunciones puedan usar correctamente pdev a través de priv. fsl_asoc_card_audmux_init() elimina la referencia a priv->pdev para obtener acceso a la estructura dev, utilizada con las macros dev_err. Como priv está inicializado en cero, habría una desreferencia del puntero NULL. Tenga en cuenta que si se elimina la referencia a priv->dev antes de la asignación pero nunca se usa, por ejemplo, si no hay ningún error que imprimir, el controlador nofallará probablemente debido a las optimizaciones del compilador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinctrl: soluciona el punto muerto en create_pinctrl() al manejar -EPROBE_DEFER En create_pinctrl(), pinctrl_maps_mutex se adquiere antes de llamar a add_setting(). Si add_setting() devuelve -EPROBE_DEFER, create_pinctrl() llama a pinctrl_free(). Sin embargo, pinctrl_free() intenta adquirir pinctrl_maps_mutex, que ya está en manos de create_pinctrl(), lo que lleva a un posible punto muerto. Este parche resuelve el problema liberando pinctrl_maps_mutex antes de llamar a pinctrl_free(), evitando el punto muerto. Este error fue descubierto y resuelto utilizando Coverity Static Analysis Security Testing (SAST) por Synopsys, Inc.

Vulnerabilidad de desbordamiento de búfer en Tenda AC10 v4 US_AC10V4.0si_V16.03.10.20_cn permite a un atacante remoto ejecutar código arbitrario a través de la función Virtual_Data_Check en el componente bin/httpd.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/xe_devcoredump: marque NULL antes de las asignaciones. Asigne 'xe_devcoredump_snapshot *' y 'xe_device *' solo si 'coredump' no es NULL. v2: corrige los mensajes de confirmación. v3: definir variables antes del código. (Ashutosh/Jose) v4: eliminar la verificación de retorno para coredump_to_xe. (José/Rodrigo) v5 - Modificar mensaje de confirmación engañoso. (Matt)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ionic: corrige el pánico del kernel debido al manejo de múltiples búfer Actualmente, ionic_run_xdp() no maneja correctamente los paquetes de múltiples búfer para XDP_TX y XDP_REDIRECT. Cuando se recibe una trama gigante, ionic_run_xdp() primero crea una trama xdp con todas las páginas necesarias en el descriptor rx. Y si la acción es XDP_TX o XDP_REDIRECT, debería desasignar dma-mapping y restablecer el puntero de página a NULL para todas las páginas, no solo la primera. Pero no es así para las páginas SG. Por lo tanto, las páginas SG se reutilizarán inesperadamente. Eventualmente causa pánico en el kernel. Vaya: fallo de protección general, probablemente para la dirección no canónica 0x504f4e4dbebc64ff: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.10.0-rc3+ #25 RIP: 0010:xdp_return_frame+0x42/ 0x90 Código: 01 75 12 5b 4c 89 e6 5d 31 c9 41 5c 31 d2 41 5d e9 73 fd ff ff 44 8b 6b 20 0f b7 43 0a 49 81 ed 68 01 00 00 49 29 c5 49 01 fd 41> 80 7d0 RSP: 0018:ffff99d00122ce08 EFLAGS: 00010202 RAX: 0000000000005453 RBX: ffff8d325f904000 RCX: 00000000000000001 RDX: 00000000670e1000 RSI 000 000011f90d000 RDI: 504f4e4d4c4b4a49 RBP: ffff99d003907740 R08: 0000000000000000 R09: 00000000000000000 R10: 000000011f90d000 R11: 00000000000 R12: ffff8d325f904010 R13: 504f4e4dbebc64fd R14: ffff8d3242b070c8 R15: ffff99d0039077c0 FS: 0000000000000000(0000) GS:ffff8d399f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 050033 CR2: 00007f41f6c85e38 CR3: 000000037ac30000 CR4: 00000000007506f0 PKRU: 55555554 Seguimiento de llamadas: ? die_addr+0x33/0x90? exc_general_protection+0x251/0x2f0? asm_exc_general_protection+0x22/0x30? xdp_return_frame+0x42/0x90 ionic_tx_clean+0x211/0x280 [ionic 15881354510e6a9c655c59c54812b319ed2cd015] ionic_tx_cq_service+0xd3/0x210 [ionic 15881354510e6a9c65 5c59c54812b319ed2cd015] ionic_txrx_napi+0x41/0x1b0 [ionic 15881354510e6a9c655c59c54812b319ed2cd015] __napi_poll.constprop.0+0x29/0x1b0 net_rx_action+0x2c4/0x 350 handle_softirqs+0xf4/ 0x320 irq_exit_rcu+0x78/0xa0 interrupción_común+0x77/0x90

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: inicialice nfsd_info.mutex anticipadamente. svc_pool_stats_start() puede eliminar la referencia a nfsd_info.mutex inmediatamente después de crear la nueva red. Actualmente, esto puede provocar un error. Mueva la inicialización antes antes de que se pueda desreferenciarla.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige la falla de DIO debido a créditos de transacción insuficientes. El código en ocfs2_dio_end_io_write() estima el número de créditos de transacción necesarios usando ocfs2_calc_extend_credits(). Sin embargo, esto no tiene en cuenta que el IO podría ser arbitrariamente grande y contener un número arbitrario de extensiones. Las manipulaciones del árbol de extensión a menudo extienden la transacción actual, pero no en todos los casos. Por ejemplo, si solo tenemos extensiones de un solo bloque en el árbol, ocfs2_mark_extent_write() terminará llamando a ocfs2_replace_extent_rec() todo el tiempo y nunca extenderemos la transacción actual y eventualmente agotaremos todos los créditos de la transacción si el IO contiene muchas extensiones de un solo bloque. Una vez que eso sucede, se activa un WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) en jbd2_journal_dirty_metadata() y posteriormente OCFS2 cancela en respuesta a este error. En realidad, esto fue provocado por uno de nuestros clientes en un sistema de archivos OCFS2 muy fragmentado. Para solucionar el problema, asegúrese de que la transacción siempre tenga suficientes créditos para una inserción de extensión antes de cada llamada de ocfs2_mark_extent_writing(). Heming Zhao dijo: ------ PÁNICO: "Pánico del kernel - no se sincroniza: OCFS2: (dispositivo dm-1): pánico forzado después del error" PID: xxx TAREA: xxxx CPU: 5 COMANDO: "SubmitThread-CA" # 0 machine_kexec en ffffffff8c069932 #1 __crash_kexec en ffffffff8c1338fa #2 pánico en ffffffff8c1d69b9 #3 ocfs2_handle_error en ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort en ffffffffc0c88387 #5 ocfs2_journal_dirty en ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent en ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag en ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_writing en ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write en ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io en ffffffffc0c2c0f5 [ocfs2] #11 completo en ffffffff8c2b9fa7 #12 do_blockdev_direct_IO en ffffffff8c2bc09f #13 ocfs2_direct_IO en ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write en ffffffff8c1dcf14 #15 __generic_file_write_iter en ffffffff8c1dd07b #16 ocfs2_file_write_iter en ffffffffc0c49f1f [ocfs2] #17 aio_write en ffffffff8c2cc72e #18 kmem_cache_alloc en ffffffff8c248dde #19 _enviar en ffffffff8c2ccada #20 do_syscall_64 en ffffffff8c004984 #21 Entry_SYSCALL_64_after_hwframe en ffffffff8c8000ba