Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: fprobe events: Fix possible UAF on modules. La confirmación ac91052f0ae5 ("tracing: tprobe-events: Fix leakage of module refcount") trasladó try_module_get() de __find_tracepoint_module_cb() al llamador de find_tracepoint(), pero esto introdujo un posible UAF porque el módulo puede descargarse antes que try_module_get(). En este caso, el objeto del módulo también debería liberarse. Por lo tanto, try_module_get() no solo falla, sino que puede acceder al objeto liberado. Para evitarlo, vuelva a intentar try_module_get() en __find_tracepoint_module_cb().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: evitar la desreferencia de puntero nulo en la llamada a dbg. cifs_server_dbg() implica que el servidor no es nulo, por lo que se mueve la llamada bajo condición para evitar la desreferencia de puntero nulo. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: pciehp: Evitar comprobaciones innecesarias de reemplazo de dispositivo. La desconexión en caliente de puertos PCI hotplug anidados sufre una condición de ejecución persistente que puede provocar un bloqueo: un puerto hotplug principal adquiere pci_lock_rescan_remove() y espera a que pciehp se desvincule de un puerto hotplug secundario. Mientras tanto, ese puerto hotplug secundario también intenta adquirir pci_lock_rescan_remove() para eliminar sus propios secundarios. El bloqueo solo ocurre si el principal adquiere pci_lock_rescan_remove() primero, no si el secundario lo adquiere primero. A lo largo de los años se han propuesto y descartado varias soluciones alternativas para evitar el problema, por ejemplo: https://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb.1529173804.git.lukas@wunner.de/ Se está trabajando en una solución adecuada, pero requiere más tiempo, ya que no es trivial y es necesariamente intrusiva. La reciente confirmación 9d573d19547b ("PCI: pciehp: Detectar reemplazo de dispositivo durante la suspensión del sistema") provoca una mayor frecuencia del bloqueo al eliminar más de un dispositivo Thunderbolt durante la suspensión del sistema. Esta confirmación buscaba detectar el reemplazo del dispositivo, pero también se activó al eliminarlo. Es imposible diferenciar con precisión entre reemplazo y eliminación, ya que pci_get_dsn() devuelve 0 tanto si el dispositivo se eliminó como si se reemplazó por uno sin número de serie del dispositivo. Evite la ocurrencia más frecuente del interbloqueo comprobando si el puerto hotplug se eliminó en caliente. De ser así, no tiene sentido comprobar si su dispositivo secundario se reemplazó. Esto funciona porque la llamada de retorno ->resume_noirq() se invoca de arriba a abajo para toda la jerarquía: un puerto hotplug principal que detecta el reemplazo (o la eliminación) de un dispositivo marca todos los secundarios como eliminados mediante pci_dev_set_disconnected() y un puerto hotplug secundario puede entonces detectar con fiabilidad su eliminación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pwm: mediatek: Evitar la división por cero en pwm_mediatek_config(). Con CONFIG_COMPILE_TEST y !CONFIG_HAVE_CLK, pwm_mediatek_config() presenta una división por cero en la siguiente línea: do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm])); debido a que la versión !CONFIG_HAVE_CLK de clk_get_rate() devuelve cero. Se supone que se trata de un problema teórico: COMPILE_TEST anula la dependencia de RALINK, que seleccionaría COMMON_CLK. En cualquier caso, es recomendable comprobar el error explícitamente para evitar la división por cero. Corrige la siguiente advertencia: drivers/pwm/pwm-mediatek.o: advertencia: objtool: .text: final inesperado de sección [ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: Desactivación de vGIC al crear una vCPU fallida. Si kvm_arch_vcpu_create() no comparte la página de vCPU con el hipervisor, propagamos el error a ioctl, pero dejamos los datos de vCPU de vGIC inicializados. Cabe destacar que esto solo filtra la memoria correspondiente cuando se destruye la vCPU, sino que también puede provocar un uso después de la liberación si el dispositivo redistribuidor intenta acceder a la vCPU. Agregue la limpieza faltante a kvm_arch_vcpu_create() para garantizar que las estructuras de vCPU de vGIC se destruyan en caso de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: accel/ivpu: Se corrigen los interbloqueos relacionados con el mantenimiento preventivo en las IOCTL de MS. Se impide la reanudación/suspensión en tiempo de ejecución mientras las IOCTL de MS están en curso. Una suspensión fallida llamará a ivpu_ms_cleanup(), que intentará adquirir file_priv->ms_lock, que ya está en poder de las IOCTL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: accel/ivpu: Se corrige el bloqueo en ivpu_ms_cleanup(). Se corrige el bloqueo en ivpu_ms_cleanup() impidiendo la reanudación en tiempo de ejecución tras adquirir file_priv->ms_lock. Durante un fallo en la reanudación en tiempo de ejecución, se ejecuta un arranque en frío que llama a ivpu_ms_cleanup_all(). Esta función llama a ivpu_ms_cleanup(), que adquiere file_priv->ms_lock y provoca el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: mops: No desreferenciar el registro src para una operación set. El registro fuente no se utiliza para SET* y leerlo puede resultar en un error de acceso a la matriz UBSAN fuera de los límites, específicamente cuando la excepción MOPS se toma de una secuencia SET* con XZR (reg 31) como origen. Arquitectónicamente, este es el único caso donde un campo src/dst/size en el ESR puede reportarse como 31. Antes de 2de451a329cf662b, el código en do_el0_mops() era benigno ya que el uso de pt_regs_read_reg() impedía el acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: Corregir el desequilibrio en el recuento de referencias de netns que causa fugas y uso después de la liberación. La confirmación ef7134c7fc48 ("smb: cliente: Corregir el uso después de la liberación del espacio de nombres de red") intentó corregir un problema de uso después de la liberación de netns ajustando manualmente los recuentos de referencias mediante sk->sk_net_refcnt y sock_inuse_add(). Sin embargo, una confirmación posterior e9f2517a3e18 ("smb: cliente: Corregir el bloqueo de los temporizadores TCP después de rmmod") indicó que la configuración manual de sk->sk_net_refcnt en la primera confirmación era técnicamente incorrecta, ya que sk->sk_net_refcnt solo debe configurarse para sockets de usuario. Esto provocó problemas como que los temporizadores TCP no se borraran correctamente al cerrar. La segunda confirmación se adaptó a un modelo que simplemente almacena una referencia netns adicional para server->ssocket mediante get_net() y la elimina al desmantelar el servidor. Sin embargo, persisten algunas deficiencias en el equilibrio entre get_net() y put_net(), añadidas por estas confirmaciones. El manejo incompleto de las referencias en estas correcciones genera dos problemas: 1. Fugas de recuento de referencias de netns[1]. El proceso del problema es el siguiente: ``` mount.cifs cifsd cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* Primero, obtener net. */ ip_connect generic_ip_connect /* Intentar el puerto 445 */ get_net() ->connect() /* Error */ put_net() generic_ip_connect /* Intentar el puerto 139 */ get_net() /* Falta put_net() coincidente para este get_net().*/ cifs_get_smb_ses cifs_negotiate_protocol smb2_negotiate SMB2_negotiate cifs_send_recv wait_for_response cifs_demultiplex_thread cifs_read_from_socket cifs_readv_from_socket cifs_reconnect cifs_abort_connection sock_release(); server->ssocket = NULL; /* Falta put_net() aquí. */ generic_ip_connect get_net() ->connect() /* Error */ put_net() sock_release(); server->ssocket = NULL; free_rsp_buf ... clean_demultiplex_info /* Solo se llama una vez aquí. */ put_net() ``` Cuando se activa cifs_reconnect(), el servidor->ssocket se libera sin un put_net() correspondiente para la referencia obtenida previamente en generic_ip_connect(). Termina llamando a generic_ip_connect() de nuevo para reintentar get_net(). Después, el servidor->ssocket se establece en NULL en la ruta de error de generic_ip_connect(), y el recuento neto no se puede liberar en la función clean_demultiplex_info() final. 2. Posible uso después de la liberación. El esquema actual de recuento de referencias puede generar un posible problema de uso después de la liberación en el siguiente escenario: ``` cifs_do_mount cifs_mount cifs_mount_get_session cifs_get_tcp_session get_net() /* First get net */ ip_connect generic_ip_connect get_net() bind_socket kernel_bind /* failed */ put_net() /* after out_err_crypto_release label */ put_net() /* after out_err label */ put_net() ``` En el proceso de gestión de excepciones donde falla la vinculación del socket, las llamadas get_net() y put_net() están desequilibradas, lo que puede provocar que el recuento de referencias server->net baje a cero y se libere prematuramente. Para solucionar ambos problemas, este parche vincula el recuento de referencias netns ---truncated---

El complemento IMITHEMES Listing es vulnerable a la escalada de privilegios mediante la apropiación de cuentas en todas las versiones hasta la 3.3 incluida. Esto se debe a que el complemento no valida correctamente el valor del código de verificación antes de actualizar la contraseña mediante la función imic_reset_password_init(). Esto permite que atacantes no autenticados cambien la contraseña de cualquier usuario, incluyendo la de administradores, si se conoce su correo electrónico.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: rawnand: brcmnand: fix PM resume WARNING Advertencia fija en la reanudación de PM como se muestra a continuación causada por una estructura nand_operation no inicializada que verifica el campo de selección de chip: WARN_ON(op->cs >= nanddev_ntargets(&chip->base) [ 14.588522] ------------[ cortar aquí ]------------ [ 14.588529] ADVERTENCIA: CPU: 0 PID: 1392 en drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8 [ 14.588553] Módulos vinculados en: bdc udc_core [ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: GW 6.14.0-rc4-g5394eea10651 #16 [ 14.588590] Contaminado: [W]=WARN [ 14.588593] Nombre del hardware: Broadcom STB (árbol de dispositivos aplanado) [ 14.588598] Rastreo de llamadas: [ 14.588604] dump_backtrace de show_stack+0x18/0x1c [ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c [ 14.588625] show_stack de dump_stack_lvl+0x70/0x7c [ 14.588639] dump_stack_lvl de dump_stack+0x18/0x1c [14.588653] r5:c08d40b0 r4:c1003cb0 [14.588656] dump_stack de __warn+0x84/0xe4 [14.588668] __warn de warn_slowpath_fmt+0x18c/0x194 [14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000 [14.588681] warn_slowpath_fmt de nand_reset_op+0x1e0/0x1f8 [14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048 [ 14.588697] nand_reset_op de brcmnand_resume+0x13c/0x150 [ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040 [ 14.588717] brcmnand_resume de platform_pm_resume+0x34/0x54 [ 14.588735] r5:00000010 r4:c0840a50 [ 14.588738] reanudación_pm_plataforma desde dpm_run_callback+0x5c/0x14c [ 14.588757] reanudación_pm_plataforma desde dispositivo_reanudación+0xc0/0x324 [ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010 [ 14.588779] reanudación_dispositivo desde dpm_resume+0x130/0x160 [ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0 [ 14.588802] dpm_resume de dpm_resume_end+0x14/0x20 [ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414 [ 14.588826] r4:00000010 [ 14.588828] dpm_resume_end de suspender_dispositivos_e_entrar+0x274/0x6f8 [ 14.588848] r5:c228a414 r4:00000000 [ 14.588851] suspender_dispositivos_e_entrar desde pm_suspend+0x228/0x2bc [ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000 [ 14.588871] r4:00000003 [ 14.588874] pm_suspend desde state_store+0x74/0xd0 [ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003 [ 14.588892] almacén de estado de kobj_attr_store+0x1c/0x28 [ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250 [ 14.588916] kobj_attr_store de sysfs_kf_write+0x40/0x4c [ 14.588936] r5:c3502900 r4:c0d92a48 [ 14.588939] sysfs_kf_write de kernfs_fop_write_iter+0x104/0x1f0 [14.588956] r5:c3502900 r4:c3501f40 [14.588960] kernfs_fop_write_iter de vfs_write+0x250/0x420 [14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00 [14.588983] r4:c042a88c [14.588987] vfs_write de ksys_write+0x74/0xe4 [ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00 [ 14.589008] r4:c34f7f00 [ 14.589011] escritura del sistema desde escritura del sistema+0x10/0x14 [ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004 [ 14.589032] escritura del sistema desde llamada al sistema ret_fast+0x0/0x5c [ 14.589044] Pila de excepciones (0xf09f9fa8 a 0xf09f9ff0) [ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001 [ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78 [ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8 [ 14.589065] ---[ fin de traza 0000000000000000 ]--- La corrección utiliza el nivel superior nand_reset(chip, chipnr); donde chipnr = 0, al realizar la operación de reanudación de PM, de acuerdo con la compatibilidad del controlador con chips NAND de una sola matriz. Cambio de nand_reset_op() a nan ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: Se corrige una fuga de referencia en pci_register_host_bridge(). Si device_register() falla, se llama a put_device() para ceder la referencia y evitar una fuga de memoria, según el comentario en device_register(). Encontrado mediante revisión de código. [bhelgaas: squash la corrección doblemente gratuita de Dan Carpenter desde https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]