Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: exec: corrige ToCToU entre la verificación permanente y el uso de set-uid/gid Al abrir un archivo para exec a través de do_filp_open(), la verificación de permisos se realiza con los metadatos del archivo en ese momento, y en caso de éxito, se devuelve un puntero de archivo. Mucho más adelante en la ruta del código execve(), los metadatos del archivo (específicamente modo, uid y gid) se utilizan para determinar si y cómo configurar uid y gid. Sin embargo, es posible que esos valores hayan cambiado desde la verificación de permisos, lo que significa que la ejecución puede obtener privilegios no deseados. Por ejemplo, si un archivo pudiera cambiar los permisos de ejecutable y no de set-id: ---------x 1 root root 16048 7 de agosto 13:16 destino a set-id y no ejecutable: ---S ------ 1 root root 16048 7 de agosto 13:16 target es posible obtener privilegios de root cuando la ejecución no debería haberse permitido. Si bien esta condición de ejecución es poco común en escenarios del mundo real, se ha observado (y se ha demostrado que es explotable) cuando los administradores de paquetes actualizan los bits setuid de los programas instalados. Dichos archivos comienzan siendo ejecutables mundialmente, pero luego se ajustan para que sean ejecutables en grupo con un bit set-uid. Por ejemplo, "chmod ox,u+s target" hace que "target" sea ejecutable sólo mediante uid "root" y gid "cdrom", y al mismo tiempo se convierte en setuid-root: -rwxr-xr-x 1 root cdrom 16048 7 de agosto de 13: 16 objetivo se convierte en: -rwsr-xr-- 1 cdrom raíz 16048 7 de agosto 13:16 objetivo Pero competir con el chmod significa que los usuarios sin membresía del grupo "cdrom" pueden obtener permiso para ejecutar "destino" justo antes del chmod, y cuando el chmod finaliza, el ejecutivo llega a brpm_fill_uid() y realiza el setuid como root, violando la autorización expresa de "sólo los miembros del grupo cdrom pueden setuid como root". Vuelva a verificar que todavía tengamos permisos de ejecución en caso de que los metadatos hayan cambiado. Sería mejor conservar una copia del momento de verificación permanente, pero hasta que podamos hacer esa refactorización, la opción menos mala es hacer una llamada completa a inode_permission() (bajo bloqueo de inodo). Se entiende que esto es seguro contra bloqueos mutuos, pero no es óptimo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/hns: corrige el bloqueo suave bajo carga pesada de CEQE. Actualmente, los CEQE se manejan en el controlador de interrupciones. Esto puede hacer que el núcleo de la CPU permanezca en el contexto de interrupción durante demasiado tiempo y provocar un bloqueo suave bajo una carga pesada. Maneje CEQE en la cola de trabajo de BH y establezca un límite superior para la cantidad de CEQE manejados por una sola llamada de controlador de trabajo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: ccp - Se corrige la desreferencia del puntero nulo en __sev_snp_shutdown_locked Se corrige la desreferencia del puntero nulo inducida por DEBUG_TEST_DRIVER_REMOVE. Regresa desde __sev_snp_shutdown_locked() si las estructuras psp_device o sev_device no están inicializadas. Sin la solución, el controlador producirá el siguiente símbolo: ccp 0000:55:00.5: dispositivo de habilitación (0000 -> 0002) ccp 0000:55:00.5: sev habilitado ccp 0000:55:00.5: psp habilitado ERROR: puntero NULL del kernel desreferencia, dirección: 00000000000000f0 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Ups: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI CPU: 262 PID: 1 Comm: swapper /0 No contaminado 6.9.0-rc1+ #29 RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150 Código: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 <4c> 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83 RSP: b8 EFLAGS: 00010286 RAX: 0000000000000000 RBX : ffff9e4acd2e0a28 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2ea4014b808 RBP: ffffb2ea4014b7e8 R08: 00000106 R09: 000000000003d9c0 R10: 0000000000000001 R11: ffffffffa39ff070 R12: ffff9e49d40590c8 R13: 0000000000000000 R14: ffffb2ea4014b808 R 15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9e58b1e00000 (0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000f0 CR3: 0000000418a3e001 CR4: 70ef0 PKRU: 55555554 Seguimiento de llamadas: ? __die_body+0x6f/0xb0 ? __die+0xcc/0xf0 ? page_fault_oops+0x330/0x3a0? save_trace+0x2a5/0x360? do_user_addr_fault+0x583/0x630? exc_page_fault+0x81/0x120? asm_exc_page_fault+0x2b/0x30? __sev_snp_shutdown_locked+0x2e/0x150 __sev_firmware_shutdown+0x349/0x5b0 ? pm_runtime_barrier+0x66/0xe0 sev_dev_destroy+0x34/0xb0 psp_dev_destroy+0x27/0x60 sp_destroy+0x39/0x90 sp_pci_remove+0x22/0x60 pci_device_remove+0x4e/0x110 Actually_probe+0x271/0x4 e0 __driver_probe_device+0x8f/0x160 driver_probe_device+0x24/0x120 __driver_attach+0xc7/0x280 ? driver_attach+0x30/0x30 bus_for_each_dev+0x10d/0x130 driver_attach+0x22/0x30 bus_add_driver+0x171/0x2b0? unaccepted_memory_init_kdump+0x20/0x20 driver_register+0x67/0x100 __pci_register_driver+0x83/0x90 sp_pci_init+0x22/0x30 sp_mod_init+0x13/0x30 do_one_initcall+0xb8/0x290 ? sched_clock_noinstr+0xd/0x10? local_clock_noinstr+0x3e/0x100? stack_depot_save_flags+0x21e/0x6a0? reloj_local+0x1c/0x60? stack_depot_save_flags+0x21e/0x6a0? sched_clock_noinstr+0xd/0x10? local_clock_noinstr+0x3e/0x100? __lock_acquire+0xd90/0xe30? sched_clock_noinstr+0xd/0x10? local_clock_noinstr+0x3e/0x100? __create_object+0x66/0x100? reloj_local+0x1c/0x60? __create_object+0x66/0x100? parameq+0x1b/0x90 ? parse_one+0x6d/0x1d0? parse_args+0xd7/0x1f0? do_initcall_level+0x180/0x180 do_initcall_level+0xb0/0x180 do_initcalls+0x60/0xa0 ? kernel_init+0x1f/0x1d0 do_basic_setup+0x41/0x50 kernel_init_freeable+0x1ac/0x230 ? rest_init+0x1f0/0x1f0 kernel_init+0x1f/0x1d0? rest_init+0x1f0/0x1f0 ret_from_fork+0x3d/0x50 ? rest_init+0x1f0/0x1f0 ret_from_fork_asm+0x11/0x20 Módulos vinculados en: CR2: 00000000000000f0 ---[ seguimiento final 0000000000000000 ]--- RIP:__sev_snp_shutdown_locked+0x2e/0 x150 Código: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 <4c> 8b a0 f0 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83 RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000 : 0000000 ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf: corrige la fuga de eventos al liberar el archivo y el ejecutable. El trabajo de la tarea pendiente de rendimiento nunca se espera hasta que se libere el evento correspondiente. En el caso de un evento secundario, publicado directamente a través de free_event(), esto puede potencialmente resultar en un evento filtrado, como en el siguiente escenario que ni siquiera requiere una implementación de trabajo IRQ débil para activarse: Schedule() prepare_task_switch() =======> perf_event_overflow() evento->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= perf_event_task_sched_out() event_sched_out() evento-> pendiente_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) task_work_add(&event->pending_task) Finish_lock_switch() =======> perf_pending_irq() //no hacer nada, confiar en el trabajo de la tarea pendiente <======= < /IRQ> comenzar_new_exec() perf_event_exit_task() perf_event_exit_event() // Si es un evento secundario free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // el evento se filtró También pueden ocurrir escenarios similares con perf_event_remove_on_exec () o simplemente contra perf_event_release() concurrente. Solucione este problema sincronizando con el trabajo de tarea pendiente posiblemente restante mientras se libera el evento, tal como se hace con el trabajo de IRQ pendiente restante. Esto significa que la devolución de llamada de la tarea pendiente no necesita ni debe contener una referencia al evento, lo que impide que se libere.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf: corrige la fuga de eventos al salir Cuando se programa una tarea, las entregas de sigtrap pendientes se difieren a la tarea de destino al reanudarse en el espacio de usuario a través de task_work. Sin embargo, se ignoran los fallos al agregar la devolución de llamada de un evento al motor task_work. Y dado que la última llamada para la salida de eventos ocurre después de que finalmente se cierra el trabajo de la tarea, hay una pequeña ventana durante la cual el sigtrap pendiente se puede poner en cola aunque se ignore, lo que filtra la adición del recuento de eventos, como en el siguiente escenario: TAREA A ----- do_exit() salida_task_work(tsk); perf_event_overflow() evento->pending_sigtrap = pendiente_id; irq_work_queue(&event->pending_irq); =========> PREEMPCIÓN: TAREA A -> TAREA B event_sched_out() evento->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) // FALLA: el trabajo de la tarea ha salido task_work_add(&event->pending_task) [...] perf_pending_irq() // retorno temprano: evento->oncpu = -1 [...] =========> TAREA B -> TAREA A perf_event_exit_task(tsk) perf_event_exit_event() free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) / /evento de fuga debido a un recuento inesperado == 2 Como resultado, el evento nunca se libera mientras la tarea finaliza. Solucione este problema con el manejo de errores apropiado de task_work_add().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: devres: corrige la pérdida de memoria causada por la API del controlador devm_free_percpu(). Causará una pérdida de memoria cuando se usa la API del controlador devm_free_percpu() para liberar la memoria asignada por devm_alloc_percpu(), solucionada usando devres_release( ) en lugar de devres_destroy() dentro de devm_free_percpu().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vhost/vsock: inicializar siempre seqpacket_allow Hay dos problemas relacionados con seqpacket_allow: 1. seqpacket_allow no se inicializa cuando se crea el socket. Por lo tanto, si las funciones nunca se configuran, se leerá sin inicializar. 2. Si VIRTIO_VSOCK_F_SEQPACKET está configurado y luego borrado, entonces seqpacket_allow no se borrará apropiadamente (las aplicaciones existentes que conozco generalmente no hacen esto, pero es legal y no hay forma de estar seguro de que nadie confíe en esto). Para solucionarlo: - inicializar seqpacket_allow después de la asignación - configurarlo incondicionalmente en set_features

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: endpoint: limpieza del manejo de errores en vpci_scan_bus() Smatch se queja de una verificación NULL inconsistente en vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c :1024 Error de vpci_scan_bus(): anteriormente asumimos que 'vpci_bus' podría ser nulo (consulte la línea 1021). En lugar de imprimir un mensaje de error y luego fallar, deberíamos devolver un código de error y limpiar. Además, la verificación NULL se invierte, por lo que imprime un error de éxito en lugar de fracaso.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: PCI: rcar: Degradar WARN() a dev_warn_ratelimited() en rcar_pcie_wakeup() Evitar un gran backtrace, basta con avisar al usuario que ha habido un problema de enlace. O el enlace falló y el sistema necesita mantenimiento, o el enlace continúa funcionando y el usuario ha sido informado. El mensaje de la advertencia se puede buscar en las fuentes. Esto hace que un problema de enlace real sea menos detallado. En primer lugar, este controlador tiene una limitación en el sentido de que el controlador del controlador tiene que ayudar al hardware con la transición al estado de enlace L1 escribiendo L1IATN en el registro PMCTRL; el cambio de estado de enlace L1 y L0 no es completamente automático en este controlador. En el caso de un controlador ASMedia ASM1062 PCIe SATA que no admite ASPM, al entrar a suspender o durante la plataforma pm_test, el controlador SATA ingresa al estado D3hot y el enlace ingresa al estado L1. Si el controlador SATA se activa antes de que se llamara a rcar_pcie_wakeup() y regresa a D0, el enlace regresa a L0 antes de que el controlador del controlador comenzara su transición al estado de enlace L1. En este punto, el controlador SATA envió un DLLP PM_ENTER_L1 al controlador PCIe y el controlador PCIe lo recibió, y el controlador PCIe configuró el bit PMSR PMEL1RX. Una vez que se llama a rcar_pcie_wakeup(), si el enlace ya está nuevamente en el estado L0 y el bit PMEL1RX está configurado, el controlador del controlador no tiene forma de determinar si debe realizar la transición del enlace al estado L1 o tratar el enlace como si estuviera en estado L0. Estado L0. Actualmente, el controlador intenta realizar la transición al estado del enlace L1 incondicionalmente, lo que en este caso específico falla con un tiempo de espera de sondeo PMSR L1FAEG; sin embargo, el enlace aún funciona porque ya está nuevamente en el estado L0. Reduzca la verbosidad de esta advertencia. En caso de que el enlace esté realmente roto, rcar_pcie_config_access() fallará; de lo contrario, tendrá éxito y cualquier sistema con este controlador y ASM1062 puede suspenderse sin generar un seguimiento.

Se encontró una vulnerabilidad en Genexis Tilgin Home Gateway 322_AS0500-03_05_13_05. Ha sido calificada como problemática. Este problema afecta un procesamiento desconocido del archivo /vood/cgi-bin/vood_view.cgi?lang=EN&act=user/spec_conf&sessionId=86213915328111654515&user=A&message2user=Account%20updated. La manipulación del argumento Número de teléfono conduce a cross-site scripting. El ataque puede iniciarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

Una vulnerabilidad ha sido encontrada en chillzhuang SpringBlade 4.1.0 y clasificada como crítica. Una función desconocida del archivo /api/blade-system/menu/list?updatexml es afectada por esta vulnerabilidad. La manipulación conduce a la inyección de SQL. Es posible lanzar el ataque de forma remota. El exploit ha sido divulgado al público y puede utilizarse. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5: siempre drena el estado al apagar la devolución de llamada. No tiene sentido la recuperación durante el apagado del dispositivo. si comenzó el trabajo de salud, debe esperar para evitar ejecuciones y acceso al puntero NULL. Por lo tanto, drene el WQ de salud al cerrar la devolución de llamada.