Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vma: añadir la opción give_up_on_oom en modificar/fusionar, usar en la versión uffd Actualmente, si una fusión de VMA falla debido a una condición OOM que surge en la fusión de confirmación o un fallo al duplicar anon_vma, informamos de ello para que el llamador pueda gestionarlo. Sin embargo, hay casos en los que el llamador solo está intentando una fusión ostensiblemente y no le importa si falla debido a esta condición. Dado que no queremos introducir una suposición implícita de que solo modificamos realmente los VMA después de que puedan surgir condiciones OOM, agregue una opción 'renunciar a oom' y haga un contrato explícito de que, si se establece este indicador, no modificaremos en absoluto ningún VMA si surge OOM y simplemente nos retiraremos. Dado que sería muy inusual que un usuario intentara usar vma_modify() con este indicador activado, pero especificando un rango dentro de un VMA que termina dividiéndose (lo cual puede fallar debido a problemas con rlimit, no solo por OOM), añadimos una advertencia de depuración para esta condición. El motivo es la versión de uffd: syzkaller (y el astuto análisis de Pedro Falcato) encontró una forma en la que un fallo inyectado en la asignación, que desencadena una condición OOM al fusionar las confirmaciones, provocaba que el código de uffd se confundiera y tratara un valor de error como si fuera un puntero a un VMA. Para evitar esto, utilizamos este nuevo indicador VMG para asegurarnos de que esto nunca ocurra, aprovechando que, si borramos VMAs completas, no queremos que se nos informe de un evento OOM. Muchas gracias a Pedro Falcato por su excelente análisis y a Jann Horn por su perspicaz e inteligente análisis de la situación, ambos fundamentales en esta solución.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: corrige un cambio fuera de los límites al invalidar TLB Cuando el tamaño del rango invalidado es mayor que rounddown_pow_of_two(ULONG_MAX), la macro de función roundup_pow_of_two(length) alcanzará un cambio fuera de los límites [1]. Use una invalidación de TLB completa para tales casos. v2: - Use una definición para el límite de tamaño de rango sobre el cual usamos una invalidación de TLB completa. (Lucas) - Use un mejor cálculo del límite. [1]: [ 39.202421] ------------[ cortar aquí ]------------ [ 39.202657] UBSAN: desplazamiento fuera de los límites en ./include/linux/log2.h:57:13 [ 39.202673] el exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'long unsigned int' [ 39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: GU 6.14.0+ #10 [ 39.202690] Tainted: [U]=USER [ 39.202690] Nombre del hardware: Nombre del producto del sistema ASUS/PRIME B560M-A AC, BIOS 2001 02/01/2023 [ 39.202691] Llamada Rastreo: [ 39.202692] [ 39.202695] dump_stack_lvl+0x6e/0xa0 [ 39.202699] ubsan_epilogue+0x5/0x30 [ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6 [ 39.202705] xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe] [ 39.202800] ? find_held_lock+0x2b/0x80 [ 39.202803] ? mark_held_locks+0x40/0x70 [ 39.202806] xe_svm_invalidate+0x459/0x700 [xe] [ 39.202897] drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm] [ 39.202900] __mmu_notifier_release+0x1f5/0x270 [ 39.202905] exit_mmap+0x40e/0x450 [ 39.202912] __mmput+0x45/0x110 [ 39.202914] exit_mm+0xc5/0x130 [ 39.202916] do_exit+0x21c/0x500 [ 39.202918] ? lockdep_hardirqs_on_prepare+0xdb/0x190 [ 39.202920] do_group_exit+0x36/0xa0 [ 39.202922] get_signal+0x8f8/0x900 [ 39.202926] arch_do_signal_or_restart+0x35/0x100 [ 39.202930] syscall_exit_to_user_mode+0x1fc/0x290 [ 39.202932] do_syscall_64+0xa1/0x180 [ 39.202934] ? do_user_addr_fault+0x59f/0x8a0 [ 39.202937] ? lock_release+0xd2/0x2a0 [ 39.202939] ? do_user_addr_fault+0x5a9/0x8a0 [ 39.202942] ? trace_hardirqs_off+0x4b/0xc0 [ 39.202944] ? clear_bhb_loop+0x25/0x80 [ 39.202946] ? clear_bhb_loop+0x25/0x80 [ 39.202947] ? clear_bhb_loop+0x25/0x80 [ 39.202950] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 39.202952] RIP: 0033:0x7fa945e543e1 [ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7. [ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293 [ 39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3 [ 39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff [ 39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0 [ 39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 [ 39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000 [ 39.202970] [ 39.202970] ---[ fin del seguimiento ]--- (seleccionado de la confirmación b88f48f86500bc0b44b4f73ac66d500a40d320ad)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/virtio: Se corrige la falta de fijación de dmabuf en la ruta de error de prepare_fb(). Se corrige el manejo de errores en prepare_fb() para corregir la pérdida de recursos cuando ocurre un error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/imagination: toma de referencia de trabajo emparejado. Para trabajos emparejados, el trabajo de fragmento toma una referencia en el trabajo de geometría, de modo que este no pueda liberarse hasta que el trabajo de fragmento haya terminado con él. Se accede a la estructura del trabajo de geometría cuando el programador de GPU prepara el trabajo de fragmento. Tomar la referencia impide que el trabajo de geometría se libere hasta que el trabajo de fragmento ya no la necesite. Corrige un error de use-after-free detectado por KASAN: [124.256386] ERROR: KASAN: slab-use-after-free en pvr_queue_prepare_job+0x108/0x868 [powervr] [124.264893] Lectura de tamaño 1 en la dirección ffff0000084cb960 por la tarea kworker/u16:4/63

NVIDIA GPU Display Driver para Linux contiene una vulnerabilidad que podría permitir a un atacante sin privilegios escalar permisos. Una explotación exitosa de esta vulnerabilidad podría provocar ejecución de código, denegación de servicio, escalada de privilegios, divulgación de información y manipulación de datos.

El software NVIDIA vGPU para Windows y Linux contiene una vulnerabilidad en el Administrador de GPU Virtual (complemento vGPU), que permite a un invitado acceder a recursos globales. Una explotación exitosa de esta vulnerabilidad podría provocar una denegación de servicio.

NVIDIA TensorRT-LLM para cualquier plataforma contiene una vulnerabilidad en el ejecutor de Python que permite a un atacante causar un problema de validación de datos mediante el acceso local al servidor TRTLLM. Una explotación exitosa de esta vulnerabilidad puede provocar la ejecución de código, la divulgación de información y la manipulación de datos.

La carga de archivos sin restricciones en Kibana permite que un atacante autenticado comprometa la integridad del software al cargar un archivo malicioso manipulado debido a una validación insuficiente del lado del servidor.

Los registros del servidor APM podrían contener partes del cuerpo del documento de una solicitud de indexación masiva parcialmente fallida. Dependiendo de la naturaleza del documento, esto podría revelar información confidencial en los registros de errores del servidor APM.

La inclusión de funcionalidad de una esfera de control no confiable en el subproceso de Elastic Agent, osqueryd, permite a atacantes locales ejecutar código arbitrario mediante la inyección de parámetros. Un atacante requiere acceso local y la capacidad de modificar las configuraciones de osqueryd.

El consumo descontrolado de recursos en Elasticsearch al evaluar plantillas de búsqueda específicamente manipuladas con funciones Mustache puede provocar una denegación de servicio al provocar que el nodo Elasticsearch se bloquee.