Vulnerabilidades

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.

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 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: 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: PCI/MSI: corrige UAF en msi_capability_init KFENCE informa el siguiente UAF: ERROR: KFENCE: lectura de uso después de liberación en __pci_enable_msi_range+0x2c0/0x488 Lectura de uso después de liberación en 0x0000000024629571 (en kfence-#12): __pci_enable_msi_range+0x2c0/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 kfence-#12: 0x0000000008614900-0x00000000e06c22 8d, tamaño=104, caché=kmalloc-128 asignado por la tarea 81 en la CPU 7 en 10.808142 s: __kmem_cache_alloc_node+0x1f0/0x2bc kmalloc_trace+0x44/0x138 msi_alloc_desc+0x3c/0x9c msi_domain_insert_msi_desc+0x30/0x78 msi_setup_msi_desc+0x13c/0x184 __pci_enable_msi_range+0 x258/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 liberado por la tarea 81 en la CPU 7 en 10.811436s: msi_domain_free_descs+0xd4/0x10c msi_domain_free_locked.part.0+0xc0/0x1d8 msi_domain_alloc_irqs_all_locked+0xb4/0xbc pci_msi_setup_msi_irqs+0x30/0x4c __pci_enable_msi_range+ 0x2a8/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 Asignación de descriptores realizada en: __pci_enable_msi_range msi_capability_init msi_setup_msi_desc msi_insert_msi_desc msi_domain_insert_msi_desc msi_alloc_desc ... Liberado en caso de fallo en __msi_domain_alloc_locked() __pci_enable_msi_range msi_capability_init pci_msi_setup_msi_irqs msi_domain_alloc_irqs_all_locked msi_domain_alloc_locked __msi_ domain_alloc_locked => falla msi_domain_free_locked... Ese error se propaga nuevamente a pci_msi_setup_msi_irqs() en msi_capability_init() que accede al descriptor para desenmascarar en la salida de error camino. Soréguelo copiando el descriptor y usando la copia para la operación de desenmascarar la ruta de salida del error. [tglx: registro de cambios masajeado]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: corrija netfs_page_mkwrite() para verificar que folio->mapping sea válido. Corrija netfs_page_mkwrite() para verificar que folio->mapping sea válido una vez que haya tomado el bloqueo de folio (como filemap_page_mkwrite( ) hace). Sin esto, generic/247 ocasionalmente falla con algo como lo siguiente: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente RIP: 0010:trace_event_raw_event_netfs_folio +0x61/0xc0... Seguimiento de llamadas: ? __die_body+0x1a/0x60 ? page_fault_oops+0x6e/0xa0? exc_page_fault+0xc2/0xe0? asm_exc_page_fault+0x22/0x30? trace_event_raw_event_netfs_folio+0x61/0xc0 trace_netfs_folio+0x39/0x40 netfs_page_mkwrite+0x14c/0x1d0 do_page_mkwrite+0x50/0x90 do_pte_missing+0x184/0x200 __handle_mm_fault+0x42d/0x500 _fault+0x121/0x1f0 do_user_addr_fault+0x23e/0x3c0 exc_page_fault+0xc2/0xe0 asm_exc_page_fault+0x22/0x30 Esto se debe a que invalidate_inode_pages2_range() emitido al final de la escritura DIO interfiere con las escrituras mmap.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cxl/region: evitar la desreferencia del puntero nulo en la búsqueda de regiones cxl_dpa_to_region() busca una región basada en memdev y DPA. Se supone erróneamente que un endpoint encontrado mapeando el DPA también pertenece a una región completamente ensamblada. Cuando no es cierto, se produce una desreferencia del puntero nulo al buscar el nombre de la región. Esto aparece durante la prueba de la búsqueda de regiones después de un error al ensamblar una región definida por el BIOS o si la búsqueda coincidió con el ensamblaje de la región definida por el BIOS. No limpiar las regiones definidas por el BIOS que fallan en el ensamblaje es un problema en sí mismo y una solución a ese problema aliviará parte del impacto. Esto no aliviará las condiciones de carrera, así que endurezcamos este camino. El cambio de comportamiento es que el kernel oops debido a una desreferencia de puntero nulo se reemplaza con un mensaje dev_dbg() que indica que se asignó un endpoint. Se agregan comentarios adicionales para que los futuros usuarios de esta función puedan comprender más claramente lo que proporciona.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cxl/mem: no se corrige cxl_nvd durante el autoensamblaje de la región pmem. Cuando el subsistema CXL ensambla automáticamente una región pmem durante el sondeo del puerto del endpoint cxl, presione siempre debajo de calltrace. ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000078 #PF: acceso de lectura del supervisor en modo kernel #PF: código_error(0x0000) - página no presente RIP: 0010:cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem] Seguimiento de llamadas: ? __morir+0x24/0x70 ? page_fault_oops+0x82/0x160? do_user_addr_fault+0x65/0x6b0? exc_page_fault+0x7d/0x170? asm_exc_page_fault+0x26/0x30? cxl_pmem_region_probe+0x22e/0x360 [cxl_pmem] ? cxl_pmem_region_probe+0x1ac/0x360 [cxl_pmem] cxl_bus_probe+0x1b/0x60 [cxl_core] really_probe+0x173/0x410? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x80/0x170 driver_probe_device+0x1e/0x90 __device_attach_driver+0x90/0x120 bus_for_each_drv+0x84/0xe0 __device_attach+0xbc/0x1f0 be_device+0x90/0xa0 device_add+0x51c/0x710 devm_cxl_add_pmem_region+0x1b5/0x380 [cxl_core] cxl_bus_probe+ 0x1b/0x60 [cxl_core] El cxl_nvd de memdev debe estar disponible durante el sondeo de la región pmem. Actualmente, cxl_nvd está registrado después de la sonda del puerto del endpoint. La sonda de endpoint, en el caso de autoensamblaje de regiones, puede provocar una sonda de región pmem que requiera el cxl_nvd aún no disponible. Ajuste la secuencia para que se cumpla esta dependencia. Esto requiere agregar un parámetro de puerto a cxl_find_nvdimm_bridge() que se puede usar para consultar el puerto raíz ancestro. El puerto del endpoint aún no está disponible, pero compartirá un ancestro común con su padre, así que inicie la consulta desde allí.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: can: j1939: manejo de errores mejorado para mensajes RTS recibidos estrechamente en xtp_rx_rts_session_new Este parche mejora el manejo de errores en escenarios con mensajes RTS (Solicitud de envío) que llegan cerca. Reemplaza los rastreos WARN_ON_ONCE menos informativos con un nuevo método de manejo de errores. Esto proporciona mensajes de error más claros y permite la finalización anticipada de sesiones problemáticas. Anteriormente, las sesiones sólo se publicaban al final de j1939_xtp_rx_rts(). Potencialmente, esto podría reproducirse con algo como: testj1939 -r vcan0:0x80 & while true; hacer # enviar primero RTS cansend vcan0 18EC8090#1014000303002301; # enviar segundo RTS cansend vcan0 18EC8090#1014000303002301; # enviar cancelar cansend vcan0 18EC8090#ff00000000002301; hecho

Magento-lts es una alternativa de soporte a largo plazo a Magento Community Edition (CE). Esta vulnerabilidad de XSS afecta las configuraciones del sistema design/header/welcome, design/header/logo_src, design/header/logo_src_small y design/header/logo_alt. Su objetivo es permitir a los administradores establecer un texto en los dos casos y definir una URL de imagen para los otros dos casos. Pero debido a que anteriormente faltaba el escape, se permitía ingresar HTML arbitrario y, como consecuencia, también JavaScript arbitrario. El problema se solucionó con la versión 20.10.1 o superior.

tgstation-server es una herramienta a escala de producción para la gestión de servidores BYOND. Antes de 6.8.0, los usuarios con permisos bajos que usaban el privilegio "Set .dme Path" podían configurar archivos .dme maliciosos existentes en la máquina host para compilarlos y ejecutarlos. Estos archivos .dme se pueden cargar a través del servidor tgstation (que requiere un privilegio aislado e independiente) o por algún otro medio. Un servidor configurado para ejecutarse en el nivel de seguridad confiable de BYOND (que requiere un tercer privilegio separado y aislado O que lo establezca otro usuario) podría llevar a que esto se convierta en una ejecución remota de código a través del proceso shell() de BYOND. La capacidad de ejecutar este tipo de ataque es un efecto secundario conocido de tener usuarios privilegiados de TGS, pero normalmente requiere múltiples privilegios con debilidades conocidas. Este vector no es intencional ya que no requiere control sobre el origen del código de implementación y _puede_ no requerir acceso de escritura remota al directorio "Configuration" de una instancia. Este problema se solucionó en las versiones 6.8.0 y superiores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: archivos de caché: establece el objeto para que se cierre si ondemand_id < 0 en copen. Si se llama maliciosamente a copen en el modo de usuario, puede eliminar la solicitud correspondiente a la identificación aleatoria. Y es posible que la solicitud aún no se haya leído. Tenga en cuenta que cuando el objeto está configurado para reabrirse, la solicitud de apertura se realizará con el estado aún reabierto en el caso anterior. Como resultado, la solicitud correspondiente a este objeto siempre se omite en la función select_req, por lo que la solicitud de lectura nunca se completa y bloquea otros procesos. Solucione este problema simplemente configurando el objeto para que se cierre si su id <0 en copen.