Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: ufs: core: Establecer SDEV_OFFLINE cuando se apaga UFS. Hay un historial de interbloqueo si se realiza el reinicio al comienzo del arranque. SDEV_QUIESCE se estableció para todos los scsi_devices de LU por el apagado de UFS, y en ese momento el controlador de audio estaba esperando a blk_mq_submit_bio() sosteniendo un mutex_lock mientras leía el binario fw. Después de eso, ocurrió un problema de interbloqueo mientras el apagado del controlador de audio estaba esperando mutex_unlock de blk_mq_submit_bio(). Para resolver esto, establezca SDEV_OFFLINE para todas las LU excepto WLUN, de modo que cualquier E/S que se caiga después de un apagado de UFS devuelva un error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [apagado_dispositivo] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Rastreo de llamadas: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: intercambiador/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: intercambiador/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: intercambiador/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: intercambiador/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: intercambiador/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: intercambiador/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: intercambiador/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: intercambiador/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: intercambiador/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: intercambiador/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: intercambiador/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: intercambiador/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: intercambiador/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: intercambiador/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: intercambiador/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: intercambiador/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Rastreo de llamadas: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: intercambiador/0: 0] __submit_bio+0xb8/0x19c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: sondas: Eliminar el soporte roto de uprobe LDR (literal). Las funciones simulation_ldr_literal() y simulation_ldrsw_literal() no son seguras para usar con uprobes. Ambas funciones se escribieron originalmente para usar con kprobes y acceder a la memoria con accesos C simples. Cuando se agregó uprobes, se reutilizaron sin modificar a pesar de que no pueden acceder de manera segura a la memoria del usuario. Hay tres problemas clave: 1) Los accesos C simples no tienen entradas extable correspondientes y, por lo tanto, si encuentran un fallo, el kernel los tratará como accesos no intencionales a la memoria del usuario, lo que resultará en un BUG() que matará el hilo del kernel y probablemente conducirá a más problemas (por ejemplo, bloqueo o panic()). 2) Los accesos C simples están sujetos a HW PAN y SW PAN, y por lo tanto, cuando cualquiera de ellos está en uso, cualquier intento de simular un acceso a la memoria del usuario fallará. Por lo tanto, ni simulation_ldr_literal() ni simulation_ldrsw_literal() pueden hacer nada útil al simular una instrucción de usuario en cualquier sistema con HW PAN o SW PAN. 3) Los accesos C simples son privilegiados, ya que se ejecutan en el contexto del núcleo y, en la práctica, pueden acceder a un pequeño rango de direcciones virtuales del núcleo. Las instrucciones que simulan tienen un rango de +/-1 MiB y, dado que las instrucciones simuladas deben ser instrucciones de usuario en el rango de direcciones TTBR0, estas pueden direccionar el último MiB del rango de direcciones de TTBR1 envolviendo hacia abajo desde una dirección en el primer MiB del rango de direcciones TTBR0. En los núcleos contemporáneos, los últimos 8 MiB del rango de direcciones TTBR1 están reservados y los accesos a estos siempre fallarán, lo que significa que esto no es peor que (1). Históricamente, era teóricamente posible que el mapa lineal o vmemmap se derramara en los últimos 8 MiB del rango de direcciones TTBR1, pero en la práctica esto es extremadamente improbable que ocurra ya que esto requeriría: * Tener suficiente memoria física para llenar todo el mapa lineal hasta el último 1 MiB del rango de direcciones TTBR1. * Tener mala suerte con la aleatorización KASLR del mapa lineal de modo que la región poblada se superponga con el último 1 MiB del rango de direcciones TTBR. ... y en cualquier caso, si nos desbordáramos en la página final, habría problemas más grandes ya que la página final tendría alias con punteros de error. Prácticamente hablando, (1) y (2) son los grandes problemas. Dado que no ha habido informes de problemas desde que se introdujo el código roto, parece que nadie confía en sondear estas instrucciones con uprobes. Evite estos problemas al no permitir uprobes en LDR (literal) y LDRSW (literal), y al limitar el uso de simulation_ldr_literal() y simulation_ldrsw_literal() a kprobes. Los intentos de colocar uprobes en LDR (literal) y LDRSW (literal) serán rechazados ya que arm_probe_decode_insn() devolverá INSN_REJECTED. En el futuro, podemos considerar la introducción de compatibilidad con uprobes funcionales para estas instrucciones, pero esto requerirá un trabajo más significativo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Se corrige pci_for_each_dma_alias() incorrecto para dispositivos que no sean PCI Anteriormente, la función domain_context_clear() llamaba incorrectamente a pci_for_each_dma_alias() para configurar entradas de contexto para dispositivos que no sean PCI. Esto podría provocar bloqueos del kernel u otro comportamiento inesperado. Agregue una verificación para llamar solo a pci_for_each_dma_alias() para dispositivos PCI. Para dispositivos que no sean PCI, se llama a domain_context_clear_one() directamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: qcom: Se ha corregido la desreferencia NULL en asoc_qcom_lpass_cpu_platform_probe(). Una devm_kzalloc() en asoc_qcom_lpass_cpu_platform_probe() podría devolver un puntero NULL. La desreferencia de puntero NULL se puede activar sin una comprobación adicional. Agregue una comprobación NULL para el puntero devuelto.

Se descubrió una vulnerabilidad potencial en ciertos dispositivos de videoconferencia de Poly. El fallo del firmware no desinfecta adecuadamente la entrada del usuario. La explotación de esta vulnerabilidad depende de un ataque en capas y no puede explotarse por sí sola.

Una vulnerabilidad de entidad externa XML (XXE) en HAPI FHIR anterior a v6.4.0 permite a los atacantes acceder a información confidencial o ejecutar código arbitrario mediante el suministro de una solicitud manipulada que contiene entidades XML maliciosas.

LSC Smart Connect Indoor IP Camera V7.6.32 es vulnerable a un problema de divulgación de información que permite acceder a las imágenes en vivo de la cámara a través del protocolo RTSP en el puerto 8554 sin necesidad de autenticación. Esto permite que usuarios no autorizados con acceso a la red vean la señal de la cámara, lo que podría comprometer la privacidad y la seguridad del usuario. No se requieren credenciales ni permisos especiales, y se puede acceder de forma remota a través de la red.

Las versiones 10.0.1 y anteriores de Substance3D - Painter se ven afectadas por una vulnerabilidad de escritura fuera de los límites que podría provocar la ejecución de código arbitrario en el contexto del usuario actual. Para explotar este problema es necesaria la interacción del usuario, ya que la víctima debe abrir un archivo malicioso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: unicode: No aplicar mayúsculas y minúsculas especiales a los puntos de código que se puedan ignorar. No necesitamos manejarlos por separado. En su lugar, simplemente dejamos que se descompongan o se conviertan en mayúsculas y minúsculas por sí mismos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/oa: Corregir desbordamiento en el búfer por lotes de oa. De manera predeterminada, xe_bb_create_job() agrega un MI_BATCH_BUFFER_END al buffer por lotes, esto no es un problema si el buffer por lotes solo se usa una vez, pero oa reutiliza el búfer por lotes para la misma métrica y en cada llamada agrega un MI_BATCH_BUFFER_END, imprimiendo la advertencia a continuación y luego desbordándose. [ 381.072016] ------------[ cortar aquí ]------------ [ 381.072019] xe 0000:00:02.0: [drm] ¡La afirmación `bb->len * 4 + bb_prefetch(q->gt) <= size` falló! Plataforma: LUNARLAKE Subplataforma: 1 Gráficos: Xe2_LPG / Xe2_HPG 20.04 Paso B0 Medios: Xe2_LPM / Xe2_HPM 20.00 Paso B0 Mosaico: 0 VRAM 0 B GT: 0 Tipo 1 Aquí se verifica si el buffer de lote ya tiene MI_BATCH_BUFFER_END si no, se agrega. v2: - simplemente se arregla, sugerencia de Ashutosh (seleccionada del commit 9ba0e0f30ca42a98af3689460063edfb6315718a)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm vdo: no hacer referencia a dedupe_context después de liberarlo. Borre el puntero dedupe_context en un data_vio siempre que se pierda la propiedad del contexto, de modo que vdo no pueda examinarlo accidentalmente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: netconsole: fix wrong Warning Se activa una advertencia cuando no hay suficiente espacio en el búfer para los datos del usuario. Sin embargo, esto no es un problema ya que los datos del usuario se enviarán en la siguiente iteración. Mensaje de advertencia actual: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 El código emite incorrectamente una advertencia cuando this_chunk es cero, lo cual es un escenario válido. La advertencia solo debería activarse cuando this_chunk es negativo.