Instituto Nacional de ciberseguridad. Sección Incibe

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 kernel de Linux (CVE-2024-46869)
    Severidad: MEDIA
    Fecha de publicación: 30/09/2024
    Fecha de última actualización: 13/11/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btintel_pcie: Asignar memoria para datos privados del controlador Se corrige el problema que provoca que el controlador no asigne memoria para la estructura btintel_data que se utiliza para almacenar datos internos.
  • Vulnerabilidad en kernel de Linux (CVE-2024-49864)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 13/11/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Corrige una ejecución entre la configuración del socket y la creación del hilo de E/S En rxrpc_open_socket(), configura el socket y luego configura el hilo de E/S que lo manejará. Sin embargo, esto es un problema, ya que hay una brecha entre las dos fases en las que un paquete puede llegar a rxrpc_encap_rcv() desde el paquete UDP, pero fallo al intentar despertar el hilo de E/S aún no creado. Como solución rápida, simplemente haga que rxrpc_encap_rcv() descarte el paquete si aún no hay un hilo de E/S. Una solución mejor, pero más intrusiva, tal vez sería reorganizar las cosas de modo que la creación del socket la realice el hilo de E/S.
  • Vulnerabilidad en kernel de Linux (CVE-2024-49872)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 13/11/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/gup: corregir pánico en ejecución de asignación de memfd_pin_folios Si memfd_pin_folios intenta crear una página hugetlb, pero alguien más ya lo hizo, entonces folio obtiene el valor -EEXIST aquí: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; luego en el siguiente viaje a través del bucle "while start_idx" entramos en pánico aquí: if (folio) { folio_put(folio); Para corregirlo, configure folio en NULL en caso de error.
  • Vulnerabilidad en kernel de Linux (CVE-2024-49878)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 13/11/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: recurso: corregir region_intersects() frente a add_memory_driver_managed() En un sistema con memoria CXL, el árbol de recursos (/proc/iomem) relacionado con la memoria CXL puede parecerse a lo siguiente. 490000000-50fffffff: CXL Window 0 490000000-50fffffff: region0 490000000-50fffffff: dax0.0 490000000-50fffffff: RAM del sistema (kmem) Debido a que drivers/dax/kmem.c llama a add_memory_driver_managed() durante la conexión en línea de la memoria CXL, lo que hace que "System RAM (kmem)" sea un descendiente de "CXL Window X". Esto confunde a region_intersects(), que espera que todos los recursos de "RAM del sistema" estén en el nivel superior de iomem_resource. Esto puede provocar errores. Por ejemplo, cuando se ejecuta la siguiente línea de comando para escribir algo de memoria en el rango de memoria CXL a través de /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copies, 0.0283507 s, 0.0 kB/s el comando falla como se esperaba. Sin embargo, el código de error es incorrecto. Debería ser "Operación no permitida" en lugar de "Dirección incorrecta". Más grave aún, la comprobación de permisos de /dev/mem en devmem_is_allowed() pasa incorrectamente. Aunque el acceso se impide más tarde porque ioremap() no tiene permiso para mapear la RAM del sistema, es un problema de seguridad potencial. Durante la ejecución del comando, se informa la siguiente advertencia en el registro del núcleo por llamar a ioremap() en la RAM del sistema. ioremap en RAM en 0x0000000490000000 - 0x0000000490000fff ADVERTENCIA: CPU: 2 PID: 416 en arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Rastreo de llamadas: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 Los detalles del proceso de ejecución del comando son los siguientes. En el árbol de recursos anterior, "System RAM" es un descendiente de "CXL Window 0" en lugar de un recurso de nivel superior. Por lo tanto, region_intersects() no informará de forma incorrecta ningún recurso de System RAM en la región de memoria CXL, porque solo comprueba los recursos de nivel superior. En consecuencia, devmem_is_allowed() devolverá 1 (permitirá el acceso a través de /dev/mem) para la región de memoria CXL de forma incorrecta. Afortunadamente, ioremap() no permite mapear System RAM y rechazar el acceso. Por lo tanto, es necesario corregir region_intersects() para que funcione correctamente con el árbol de recursos con "System RAM" no en el nivel superior como se indica anteriormente. Para corregirlo, si encontramos un recurso no coincidente en el nivel superior, continuaremos buscando recursos coincidentes en sus recursos descendientes. Por lo tanto, ya no nos perderemos ningún recurso coincidente en el árbol de recursos. En la nueva implementación, un árbol de recursos de ejemplo |------------- "CXL Window 0" ------------| |-- "System RAM" --| se comportará de manera similar al siguiente árbol de recursos falso para region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- "RAM del sistema" --||-- "Ventana CXL 0a" --| Donde "Ventana CXL 0a" es parte de la "Ventana CXL 0" original que no está cubierta por la "RAM del sistema".
  • Vulnerabilidad en kernel de Linux (CVE-2024-49885)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 13/11/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm, slub: evitar poner a cero la zona roja de kmalloc Desde el commit 946fa0dbf2d8 ("mm/slub: extender la comprobación de la zona roja a espacio de kmalloc asignado adicional al solicitado"), al establecer orig_size se trata el espacio desperdiciado (object_size - orig_size) como una zona roja. Sin embargo, con init_on_free=1 borramos todo el objeto->size, incluida la zona roja. Además, borramos los metadatos del objeto, incluido el orig_size almacenado, haciéndolo cero, lo que hace que check_object() trate todo el objeto como una zona roja. Estos problemas conducen al siguiente informe de ERROR con "slub_debug=FUZ init_on_free=1": [ 0.000000] ===================================================================================== [ 0.000000] ERROR kmalloc-8 (no contaminado): kmalloc Redzone sobrescrito [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. Primer byte 0x0 en lugar de 0xcc [ 0.000000] CORREGIR kmalloc-8: Restaurando kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Losa 0xfffffdffc0400c80 objetos=36 usados=23 fp=0xffff000010032a18 indicadores=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Objeto 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Objeto ffff000010032858: cc cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc cc ........ [ 0.000000] Relleno ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: intercambiador/0 No contaminado 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Nombre del hardware: Placa NXP i.MX95 19X19 (DT) [ 0.000000] Rastreo de llamadas: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec Para solucionar el problema, use orig_size para limpiar el área usada. Y restaure el valor de orig_size después de limpiar el área restante. Cuando CONFIG_SLUB_DEBUG no está definido, (get_orig_size()' retorna directamente s->object_size. Entonces, cuando se usa memset para inicializar el área, el tamaño puede ser simplemente orig_size, ya que orig_size retorna object_size cuando CONFIG_SLUB_DEBUG no está habilitado. Y orig_size nunca puede ser mayor que object_size.
  • Vulnerabilidad en kernel de Linux (CVE-2024-49902)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 13/11/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: jfs: comprobar si leafidx es mayor que la cantidad de hojas por árbol dmap syzbot informa que dbSplit está fuera de los límites, esto se debe a que dmt_leafidx es mayor que la cantidad de hojas por árbol dmap, se agrega una verificación para dmt_leafidx en dbFindLeaf. Shaggy: Se modificó la verificación de cordura para que se aplique a las páginas de control y a las páginas de hoja.
  • Vulnerabilidad en kernel de Linux (CVE-2024-49940)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 13/11/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: l2tp: evitar un posible desbordamiento del recuento de referencias del túnel Cuando se crea una sesión, establece un puntero hacia atrás a su túnel. Cuando el recuento de referencias de la sesión cae a 0, l2tp_session_free descarta el recuento de referencias del túnel si session->tunnel no es NULL. Sin embargo, session->tunnel se establece en l2tp_session_create, antes de que el recuento de referencias del túnel se incremente mediante l2tp_session_register, lo que deja una pequeña ventana donde session->tunnel no es NULL cuando el recuento de referencias del túnel no se ha incrementado. Mover la asignación a l2tp_session_register es trivial, pero l2tp_session_create llama a l2tp_session_set_header_len, que usa session->tunnel para obtener el encap del túnel. Agregue un argumento de encap a l2tp_session_set_header_len para evitar usar session->tunnel. Si las sesiones l2tpv3 tienen identificadores en conflicto, es posible que l2tp_v3_session_get compita con l2tp_session_register y obtenga una sesión que aún no tenga configurado session->tunnel. Agregue una verificación para este caso.
  • Vulnerabilidad en kernel de Linux (CVE-2024-49944)
    Severidad: MEDIA
    Fecha de publicación: 21/10/2024
    Fecha de última actualización: 13/11/2024
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: volver a establecer sk_state en CERRADO si fallo la vinculación automática en sctp_listen_start En sctp_listen_start() invocado por sctp_inet_listen(), debería volver a establecer sk_state en CERRADO si sctp_autobind() falla por cualquier motivo. De lo contrario, la próxima vez que se llame a sctp_inet_listen(), si sctp_sk(sk)->reuse ya está establecido mediante setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash se desreferenciará ya que sk_state está ESCUCHANDO, lo que provoca un bloqueo ya que bind_hash es NULL. KASAN: null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Seguimiento de llamadas: __sys_listen_socket net/socket.c:1883 [en línea] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [en línea]
  • Vulnerabilidad en Micah Blu RSVP ME (CVE-2024-50491)
    Severidad: CRÍTICA
    Fecha de publicación: 28/10/2024
    Fecha de última actualización: 13/11/2024
    La vulnerabilidad de neutralización incorrecta de elementos especiales utilizados en un comando SQL ('Inyección SQL') en Micah Blu RSVP ME permite la inyección SQL. Este problema afecta a RSVP ME: desde n/a hasta 1.9.9.
  • Vulnerabilidad en YARPP YARPP (CVE-2024-43919)
    Severidad: CRÍTICA
    Fecha de publicación: 01/11/2024
    Fecha de última actualización: 13/11/2024
    Vulnerabilidad de control de acceso en YARPP YARPP permite. Este problema afecta a YARPP: desde n/a hasta 5.30.10.