Vulnerabilidades

Twisted es un framework basado en eventos para aplicaciones de Internet, compatible con Python 3.6+. La función `twisted.web.util.redirectTo` contiene una vulnerabilidad de inyección de HTML. Si el código de la aplicación permite a un atacante controlar la URL de redireccionamiento, esta vulnerabilidad puede provocar Cross Site Scripting reflejado (XSS) en el cuerpo HTML de la respuesta de redireccionamiento. Esta vulnerabilidad se soluciona en 24.7.0rc1.

ImageMagick es un paquete de software gratuito y de código abierto que se utiliza para editar y manipular imágenes digitales. La versión `AppImage` `ImageMagick` puede usar una ruta vacía al configurar las variables de entorno `MAGICK_CONFIGURE_PATH` y `LD_LIBRARY_PATH` durante la ejecución, lo que podría llevar a la ejecución de código arbitrario al cargar archivos de configuración maliciosos o librerías compartidas en el directorio de trabajo actual mientras se ejecuta ` ImagenMagick`. La vulnerabilidad se solucionó en 7.11-36.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bcachefs: corrigió la validación de sb_field_downgrade - bch2_sb_downgrade_validate() no buscaba una entrada de degradación que se extendiera más allá del final de la sección de superbloque - for_each_downgrade_entry() se usa en to_text() y necesita trabajar con entradas mal formadas; También faltaba una marca para un campo que se extendía más allá del final de la sección.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/fbdev-dma: solo configurar smem_start está habilitado por opción de módulo. Solo exporte la estructura fb_info.fix.smem_start si así lo requiere el usuario y la memoria no proviene de vmalloc( ). La configuración de struct fb_info.fix.smem_start interrumpe los sistemas donde la memoria DMA está respaldada por el espacio de direcciones vmalloc. A continuación se muestra un error de ejemplo. [3.536043] ------------[ cortar aquí ]------------ [ 3.540716] virt_to_phys usado para direcciones no lineales: 000000007fc4f540 (0xffff800086001000) [ 3.552628] ADVERTENCIA : CPU: 4 PID: 61 en arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98 [ 3.565455] Módulos vinculados en: [ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 No contaminado 6.6 .23-06226-g4986cc3e1b75-dirty #250 [ 3.577310] Nombre de hardware: placa NXP i.MX95 19X19 (DT) [ 3.582452] Cola de trabajo: events_unbound deferred_probe_work_func [ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT- SSBS BTYPE=--) [ 3.595233] pc : __virt_to_phys+0x68/0x98 [ 3.599246] lr : __virt_to_phys+0x68/0x98 [ 3.603276] sp : ffff800083603990 [ 3.677939] Rastreo de llamadas: [ 3.68039 3] __virt_to_phys+0x68/0x98 [ 3.684067] drm_fbdev_dma_helper_fb_probe +0x138/0x238 [ 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0 [ 3.695385] drm_fb_helper_initial_config+0x4c/0x68 [ 3.700264] xe0 [ 3.705161] drm_client_register+0x60/0xb0 [ 3.709269] drm_fbdev_dma_setup+0x94/0x148 Además, se supone memoria DMA a por contiguo en el espacio de direcciones físicas, lo cual no está garantizado por vmalloc(). Resuelva esto verificando el indicador del módulo drm_leak_fbdev_smem cuando DRM asignó la instancia de la estructura fb_info. Luego, Fbdev-dma solo configura smem_start solo si es necesario (a través de FBINFO_HIDE_SMEM_START). También garantice que el framebuffer no esté ubicado en el espacio de direcciones vmalloc.

El control de acceso incorrecto en el altavoz inteligente nano Himalaya Xiaoya rom_version 1.6.96 permite que un atacante remoto tenga un impacto no especificado.

Vulnerabilidad de desbordamiento de búfer en host-host NEUQ_board v.1.0 permite que un atacante remoto provoque una denegación de servicio a través del componente password.h.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-core: corrige double free en caso de error Si, por ejemplo, la llamada ata_port_alloc() en ata_host_alloc() falla, saltaremos a la etiqueta err_out, que llamará a devres_release_group() . devres_release_group() activará una llamada a ata_host_release(). ata_host_release() llama a kfree(host), por lo que ejecutar kfree(host) en ata_host_alloc() provocará un doble error de kernel free: en mm/slub.c:553. Ups: código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) No contaminado 6.10.0-rc5 #47 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 01/04/2014 RIP: 0010:kfree+0x2cf/0x2f0 Código: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP : 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c 9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e : ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15 : 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050 033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Seguimiento de llamadas: ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90? kfree+0x2cf/0x2f0 ? exc_invalid_op+0x50/0x70? kfree+0x2cf/0x2f0 ? asm_exc_invalid_op+0x1a/0x20? ata_host_alloc+0xf5/0x120 [libata]? ata_host_alloc+0xf5/0x120 [libata]? kfree+0x2cf/0x2f0 ata_host_alloc+0xf5/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci] Asegúrese de que no llamaremos a kfree(host) dos veces, realizando kfree() solo si La llamada a devres_open_group() falló.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: mcp251xfd: corrige el bucle infinito cuando falla xmit Cuando falla la función mcp251xfd_start_xmit(), el controlador deja de procesar mensajes y la rutina de interrupción no regresa, ejecutándose indefinidamente incluso después de finalizar el aplicación en ejecución. Mensajes de error: [441.298819] mcp251xfd spi2.0 can0: ERROR en mcp251xfd_start_xmit: -16 [441.306498] mcp251xfd spi2.0 can0: El búfer FIFO de evento de transmisión no está vacío. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... y repetir para siempre. El problema puede desencadenarse cuando varios dispositivos comparten la misma interfaz SPI. Y hay acceso simultáneo al autobús. El problema ocurre porque tx_ring->head incrementa incluso si falla mcp251xfd_start_xmit(). En consecuencia, el controlador omite un paquete TX mientras espera una respuesta en mcp251xfd_handle_tefif_one(). Resuelva el problema iniciando una cola de trabajo para escribir el obj tx sincrónicamente si err = -EBUSY. En caso de otro error, disminuya tx_ring->head, elimine skb de la pila de eco y elimine el mensaje. [mkl: utilice una redacción más imperativa en la descripción del parche]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau/dispnv04: corrige la desreferencia del puntero nulo en nv17_tv_get_hd_modes En nv17_tv_get_hd_modes(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a una posible desreferencia del puntero NULL en caso de falla de drm_mode_duplicate(). Lo mismo se aplica a drm_cvt_mode(). Agregue una marca para evitar la desreferencia del puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/gt: corrige un posible UAF mediante la revocación de los registros de valla. CI ha estado informando esporádicamente el siguiente problema provocado por igt@i915_selftest@live@hangcheck en ADL-P y máquinas similares. : <6> [414.049203] I915: ejecutando Intel_hangcheck_live_SelfTests/IGT_RESET_EVICT_FENCE ... <6> [414.068804] I915 0000: 00: 02.0: [DRM] GT0: GUC: CUBLICIDAD : [drm] GT0: GUC: SLPC habilitado <3> [414.070354] No se puede fijar la cerca con mosaicos en Y; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cortar aquí ]- ----------- <2>[ 609.603995] ¡ERROR del kernel en drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Contaminado: GUW 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4 >[ 609.604008] Nombre del hardware: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 20/01/2023 <4>[ 609.604010] Cola de trabajo: i915 __i915_gem_free_work [i915] <4 >[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Seguimiento de llamadas: <4>[ 609.604273] ... <4>[ 609.604716] ct+0x2e9/ 0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440 process_scheduled_works+0x351/0x690... En el pasado, hubo fallas similares informado por CI de otras pruebas de IGT, observado en otras plataformas. Antes de confirmar 63baf4f3d587 ("drm/i915/gt: solo espere la actividad de la GPU antes de desvincular una valla GGTT"), i915_vma_revoke_fence() estaba esperando la inactividad de vma->active a través de fence_update(). Ese compromiso introdujo vma->fence->active para que fence_update() pudiera esperar selectivamente en ese en lugar de vma->active, ya que solo se necesitaba la inactividad de los registros de cerca. Pero luego, otra confirmación 0d86ee35097a ("drm/i915/gt: Hacer que la revocación de la valla sea inequívoca") reemplazó la llamada a fence_update() en i915_vma_revoke_fence() con solo fence_write(), y también agregó que GEM_BUG_ON(!i915_active_is_idle(&fence->active )) Al frente. No se proporcionó ninguna justificación sobre por qué podríamos esperar que vma->fence->active esté inactivo sin esperarlo primero. El problema puede deberse potencialmente a una carrera entre la revocación de registros de valla por un lado y la ejecución secuencial de devoluciones de llamadas de señales invocadas al completar una solicitud que las estaba usando por el otro, aún procesadas en paralelo a la revocación de esos registros de valla. Solucionelo esperando a que vma->fence->active esté inactivo en i915_vma_revoke_fence(). (cereza escogida del compromiso 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: evite usar el objeto nulo del framebuffer. En lugar de usar state->fb->obj[0] directamente, obtenga el objeto del framebuffer llamando a drm_gem_fb_get_obj() y devuelva el código de error. cuando el objeto es nulo para evitar el uso de un objeto nulo de framebuffer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau/dispnv04: corrige la desreferencia del puntero null en nv17_tv_get_ld_modes En nv17_tv_get_ld_modes(), el valor de retorno de drm_mode_duplicate() se asigna al modo, lo que conducirá a una posible desreferencia del puntero NULL en caso de falla de drm_mode_duplicate(). Agregue una marca para evitar npd.