Instituto Nacional de ciberseguridad. Sección Incibe

017 - Ir a la línea de ayuda en Ciberseguridad    Ir a Agenda     Ir a Sala de prensa     Ir a suscripción de boletines

Ir al buscador

Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.



Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

  • Vulnerabilidad en libarchive (CVE-2022-36227)
    Severidad: CRÍTICA
    Fecha de publicación: 22/11/2022
    Fecha de última actualización: 03/11/2025
    En libarchive anterior a 3.6.2, el software no busca un error después de llamar a la función calloc que puede regresar con un puntero NULL si la función falla, lo que conduce a una desreferencia del puntero NULL resultante. NOTA: el descubridor cita este comentario CWE-476, pero terceros cuestionan el impacto de la ejecución del código: "En raras circunstancias, cuando NULL es equivalente a la dirección de memoria 0x0 y el código privilegiado puede acceder a ella, entonces es posible escribir o leer la memoria, lo cual puede llevar a la ejecución del código."
  • Vulnerabilidad en la función copy_string en libarchive (CVE-2021-36976)
    Severidad: MEDIA
    Fecha de publicación: 20/07/2021
    Fecha de última actualización: 03/11/2025
    libarchive versiones 3.4.1 hasta 3.5.1, presenta un uso de memoria previamente liberada en la función copy_string (llamado desde do_uncompress_block y process_block)
  • Vulnerabilidad en OpenSSL (CVE-2023-5363)
    Severidad: ALTA
    Fecha de publicación: 25/10/2023
    Fecha de última actualización: 03/11/2025
    Resumen del problema: se ha identificado un error en el procesamiento de longitudes de clave y vector de inicialización (IV). Esto puede provocar posibles truncamientos o desbordamientos durante la inicialización de algunos cifrados simétricos. Resumen de impacto: un truncamiento en el IV puede dar como resultado una falta de unicidad, lo que podría resultar en la pérdida de confidencialidad para algunos modos de cifrado. Al llamar a EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() or EVP_CipherInit_ex2(), la matriz OSSL_PARAM proporcionada se procesa después de que se hayan establecido la clave y el IV. Cualquier modificación en la longitud de la clave, a través del parámetro "keylen" o la longitud del IV, a través del parámetro "ivlen", dentro de la matriz OSSL_PARAM no tendrá efecto según lo previsto, lo que podría provocar el truncamiento o la sobrelectura de estos valores. Los siguientes cifrados y modos de cifrado se ven afectados: RC2, RC4, RC5, CCM, GCM y OCB. Para los modos de cifrado CCM, GCM y OCB, el truncamiento del IV puede provocar una pérdida de confidencialidad. Por ejemplo, al seguir la guía de la sección 8.2.1 SP 800-38D del NIST para construir un IV determinista para AES en modo GCM, el truncamiento de la parte del contador podría llevar a la reutilización del IV. Tanto los truncamientos como los desbordamientos de la clave y del IV producirán resultados incorrectos y, en algunos casos, podrían desencadenar una excepción de memoria. Sin embargo, actualmente estos problemas no se consideran críticos para la seguridad. Cambiar la clave y/o las longitudes de IV no se considera una operación común y la API vulnerable se introdujo recientemente. Además, es probable que los desarrolladores de aplicaciones hayan detectado este problema durante las pruebas, ya que el descifrado fallaría a menos que ambos interlocutores en la comunicación fueran igualmente vulnerables. Por estas razones, esperamos que la probabilidad de que una aplicación sea vulnerable a esto sea bastante baja. Sin embargo, si una aplicación es vulnerable, el problema se considera muy grave. Por estos motivos, hemos evaluado este problema como de gravedad moderada en general. La implementación de OpenSSL SSL/TLS no se ve afectada por este problema. Los proveedores FIPS OpenSSL 3.0 y 3.1 no se ven afectados por esto porque el problema se encuentra fuera de los límites del proveedor FIPS. OpenSSL 3.1 y 3.0 son vulnerables a este problema.
  • Vulnerabilidad en kernel de Linux (CVE-2024-40901)
    Severidad: ALTA
    Fecha de publicación: 12/07/2024
    Fecha de última actualización: 03/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: mpt3sas: Evite que test/set_bit() opere en memoria no asignada. Existe un posible acceso fuera de los límites cuando se usa test_bit() en una sola palabra. Las funciones test_bit() y set_bit() operan con valores largos y, al probar o configurar una sola palabra, pueden exceder el límite de la palabra. KASAN detecta este problema y produce un volcado: ERROR: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/ bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas Escritura de tamaño 8 en la dirección ffff8881d26e3c60 mediante tarea kworker/u1536:2/2965 Para obtener el registro completo, consulte [1]. Realice la asignación al menos del tamaño de sizeof(unsigned long) para que set_bit() y test_bit() tengan suficiente espacio para operaciones de lectura/escritura sin sobrescribir la memoria no asignada. [1] Enlace: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/
  • Vulnerabilidad en kernel de Linux (CVE-2024-46828)
    Severidad: ALTA
    Fecha de publicación: 27/09/2024
    Fecha de última actualización: 03/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched: sch_cake: arregla la lógica de contabilidad de flujo masivo para la equidad del host En sch_cake, hacemos un seguimiento del recuento de flujos masivos activos por host, cuando se ejecuta en modo de equidad de host dst/src, que se utiliza como el peso round-robin cuando se itera a través de flujos. El recuento de flujos masivos activos se actualiza siempre que un flujo cambia de estado. Esto tiene una interacción peculiar con el manejo de colisiones de hash: cuando ocurre una colisión de hash (después del hash asociativo de conjuntos), el estado del depósito de hash simplemente se actualiza para que coincida con el nuevo paquete que colisionó, y si la equidad del host está habilitada, eso también significa asignar un nuevo estado por host al flujo. Por este motivo, los contadores de flujo masivo de los host asignados al flujo se decrementan, antes de que se asigne un nuevo estado (y los contadores, que pueden no pertenecer más al mismo host, se incrementan nuevamente). Cuando se introdujo este código, el modo de equidad del host siempre estaba habilitado, por lo que la disminución era incondicional. Cuando se introdujeron los indicadores de configuración, el *incremento* se hizo condicional, pero el *decremento* no. Lo que, por supuesto, puede conducir a un decremento espurio (y un retorno asociado a U16_MAX). AFAICT, cuando la equidad del host está deshabilitada, la disminución y el retorno ocurren tan pronto como ocurre una colisión de hash (lo que no es tan común en sí mismo, debido al hash asociativo de conjuntos). Sin embargo, en la mayoría de los casos esto es inofensivo, ya que el valor solo se usa cuando el modo de equidad del host está habilitado. Entonces, para activar un desbordamiento de matriz, sch_cake primero debe configurarse con la equidad del host deshabilitada y, mientras se ejecuta en este modo, debe ocurrir una colisión de hash para causar el desbordamiento. Luego, la qdisc debe reconfigurarse para habilitar la equidad del host, lo que lleva a que la matriz esté fuera de los límites porque el valor de retorno se conserva y se usa como un índice de matriz. Parece que syzbot logró activar esto, lo que es bastante impresionante en sí mismo. Este parche corrige el problema introduciendo la misma verificación condicional en la disminución que se usa en el incremento. El error original es anterior a la actualización de Cake, pero el commit que aparece en la etiqueta de correcciones abordó ese código, lo que significa que este parche no se aplicará antes de esa fecha.
  • Vulnerabilidad en kernel de Linux (CVE-2024-46830)
    Severidad: ALTA
    Fecha de publicación: 27/09/2024
    Fecha de última actualización: 03/11/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Adquirir kvm->srcu al manejar KVM_SET_VCPU_EVENTS Adquiera kvm->srcu al procesar KVM_SET_VCPU_EVENTS, ya que KVM abandonará a la fuerza el VMX/SVM anidado si se alterna el modo SMM, y al abandonar el VMX anidado se lee la memoria del invitado. Tenga en cuenta que kvm_vcpu_ioctl_x86_set_vcpu_events() también se puede llamar desde KVM_RUN a través de sync_regs(), que ya contiene SRCU. Es decir, intentar usar con precisión kvm_vcpu_srcu_read_lock() alrededor del código SMM problemático causaría problemas. Adquirir SRCU no es tan caro, así que para simplificar, tómelo incondicionalmente para KVM_SET_VCPU_EVENTS. ============================= ADVERTENCIA: uso sospechoso de RCU 6.10.0-rc7-332d2c1d713e-next-vm #552 No contaminado ----------------------------- include/linux/kvm_host.h:1027 ¡Uso sospechoso de rcu_dereference_check()! Otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 1 bloqueo retenido por repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, en: kvm_vcpu_ioctl+0x7d/0x970 [kvm] seguimiento de pila: CPU: 15 PID: 1071 Comm: repro No contaminado 6.10.0-rc7-332d2c1d713e-next-vm #552 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Seguimiento de llamadas: dump_stack_lvl+0x7f/0x90 kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm] kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm] ? kvm_vcpu_ioctl+0x497/0x970 [kvm] kvm_vcpu_ioctl+0x497/0x970 [kvm] ? bloqueo_adquirir+0xba/0x2d0 ? encontrar_bloqueo_retenido+0x2b/0x80 ? hacer_error_dirección_usuario+0x40c/0x6f0 ? liberación_de_bloqueo+0xb7/0x270 __x64_sys_ioctl+0x82/0xb0 hacer_llamada_al_sistema_64+0x6c/0x170 entrada_SYSCALL_64_después_de_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539