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-2023-52683)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ACPI: LPIT: Evitar desbordamiento de multiplicación u32 En lpit_update_residency() existe la posibilidad de desbordamiento en la multiplicación, si tsc_khz es lo suficientemente grande (> UINT_MAX/1000). Cambie la multiplicación a mul_u32_u32(). Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.
Vulnerabilidad en kernel de Linux (CVE-2023-52693)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: vídeo: comprueba si hay errores al buscar el dispositivo de retroiluminación principal. Si la llamada acpi_get_parent() en acpi_video_dev_register_backlight() fallo, por ejemplo, porque acpi_ut_acquire_mutex() fallo dentro de acpi_get_parent), esto puede provocar que se pase el identificador acpi_parent incorrecto (no inicializado) a acpi_get_pci_dev() para detectar el dispositivo pci principal. Verifique el resultado de acpi_get_parent() y configure el dispositivo principal solo en caso de éxito. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.
Vulnerabilidad en kernel de Linux (CVE-2023-52694)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/bridge: tpd12s015: Eliminar anotación __exit con errores para eliminar función Con tpd12s015_remove() marcado con __exit, esta función se descarta cuando el controlador se compila como integrado. El resultado es que cuando el controlador se desvincula no se realiza ninguna limpieza, lo que resulta en una fuga de recursos o algo peor.
Vulnerabilidad en kernel de Linux (CVE-2024-35897)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_tables: descartar actualización del indicador de tabla con eliminación pendiente de la cadena base. La cancelación del registro del gancho se difiere hasta la fase de confirmación; lo mismo ocurre con las actualizaciones del gancho activadas por el indicador inactivo de la tabla. Cuando se combinan ambos comandos, esto da como resultado la eliminación de una cadena base y deja su gancho aún registrado en el núcleo.
Vulnerabilidad en kernel de Linux (CVE-2024-35900)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_tables: rechazar nueva cadena base después de actualizar la bandera de la tabla Cuando se activa la bandera inactiva, los enlaces se desactivan en la fase de confirmación al iterar sobre las cadenas actuales en la tabla (existentes y nuevas). La siguiente configuración permite un estado inconsistente: agregar tabla x agregar cadena xy { tipo filtro gancho entrada prioridad 0; } agregar tabla x {banderas inactivas; } agregar cadena xw {tipo filtro gancho entrada prioridad 1; } que activa la siguiente advertencia al intentar cancelar el registro de la cadena w que ya está cancelada. [127.322252] ADVERTENCIA: CPU: 7 PID: 1211 en net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260 [...] [ 127.322519] Seguimiento de llamadas: [ 127.322521] [ 127.322524] ? __advertir+0x9f/0x1a0 [ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260 [127.322537]? report_bug+0x1b1/0x1e0 [127.322545]? handle_bug+0x3c/0x70 [127.322552]? exc_invalid_op+0x17/0x40 [127.322556]? asm_exc_invalid_op+0x1a/0x20 [127.322563]? kasan_save_free_info+0x3b/0x60 [127.322570]? __nf_unregister_net_hook+0x6a/0x260 [127.322577]? __nf_unregister_net_hook+0x21a/0x260 [127.322583]? __nf_unregister_net_hook+0x6a/0x260 [127.322590]? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables] [ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables] [ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables]
Vulnerabilidad en kernel de Linux (CVE-2024-35910)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: termina correctamente los temporizadores para los sockets del kernel. Recibimos varios informes de syzbot sobre los temporizadores tcp que se activan después de que se han desmantelado las redes correspondientes. Afortunadamente, Josef Bacik pudo provocar el problema con más frecuencia y pudo probar un parche que escribí hace dos años. Cuando los sockets TCP están cerrados, llamamos a inet_csk_clear_xmit_timers() para "detener" los temporizadores. Se puede llamar a inet_csk_clear_xmit_timers() desde cualquier contexto, incluso cuando se mantiene el bloqueo del socket. Esta es la razón por la que usa sk_stop_timer(), también conocido como del_timer(). Esto significa que los cronómetros en curso podrían finalizar mucho más tarde. Para los sockets de usuario, esto está bien porque cada temporizador en ejecución tiene una referencia en el socket, y el socket de usuario tiene una referencia en las redes. Para los sockets del kernel, corremos el riesgo de que la red se libere antes de que se complete el temporizador, porque los sockets del kernel no mantienen referencias en las redes. Este parche agrega la función inet_csk_clear_xmit_timers_sync() que usa sk_stop_timer_sync() para garantizar que todos los temporizadores finalicen antes de que se libere el socket del kernel. Los módulos que utilizan sockets del kernel los cierran en su controlador netns exit(). También agregue el asistente sock_not_owned_by_me() para obtener soporte LOCKDEP: no se debe llamar a inet_csk_clear_xmit_timers_sync() mientras se mantiene el bloqueo del socket. Es muy posible que podamos revertir en el futuro la confirmación 3a58f13a881e ("net: rds: adquirir refcount en sockets TCP") que intentó resolver el problema solo en rds. (net/smc/af_smc.c y net/mptcp/subflow.c tienen código similar) Probablemente podamos eliminar las pruebas check_net() de tcp_out_of_resources() y __tcp_close() en el futuro.
Vulnerabilidad en kernel de Linux (CVE-2024-35934)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: reduce la presión rtnl en smc_pnet_create_pnetids_list() Muchos informes de syzbot muestran una presión rtnl extrema, y muchos de ellos insinúan que smc adquiere rtnl en la creación de netns sin una buena razón [1] Este parche regresa temprano desde smc_pnet_net_init() si aún no hay un netdevice. Ni siquiera estoy seguro de por qué existe smc_pnet_create_pnetids_list(), porque smc_pnet_netdev_event() también llama a smc_pnet_add_base_pnetid() cuando maneja el evento NETDEV_UP. [1] extracto de informes típicos de syzbot 2 bloqueos mantenidos por syz-executor.3/12252: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core /net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+ .+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.4/12253: #0: ffffffff8f369610 (pernet_ops_rwsem){+++ +}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/ smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.1/12257: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex ){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en : smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.2/12261: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns +0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1 : ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.0/12265: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3 }, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet. c:878 2 bloqueos retenidos por syz-executor.3/12268: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c: 491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}- {3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.4/12271: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3 :3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c :809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.1 /12274: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+ .}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/ 0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.2/12280: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net /core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex) {+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
Vulnerabilidad en kernel de Linux (CVE-2024-35936)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: maneja el error de búsqueda del árbol de fragmentos en btrfs_relocate_sys_chunks() El caso no controlado en el bucle btrfs_relocate_sys_chunks() es una corrupción, ya que solo podría ser causado por dos condiciones imposibles: - al principio el La clave de búsqueda está configurada para buscar un elemento del árbol de fragmentos, con desplazamiento -1, esta es una búsqueda inexacta y la clave->desplazamiento contendrá el desplazamiento correcto tras una búsqueda exitosa, un elemento de árbol de fragmentos válido no puede tener un desplazamiento -1 - después de la primera búsqueda exitosa, found_key corresponde a un elemento fragmentado, el desplazamiento se reduce en 1 antes del siguiente ciclo, es imposible encontrar un elemento fragmentado allí debido a restricciones de alineación y tamaño
Vulnerabilidad en kernel de Linux (CVE-2024-35944)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: VMCI: corrigió la advertencia de tiempo de ejecución de memcpy() en dg_dispatch_as_host() Syzkaller presionó el error 'ADVERTENCIA en dg_dispatch_as_host'. memcpy: se detectó escritura que abarca todos los campos (tamaño 56) de un solo campo "&dg_info->msg" en drivers/misc/vmw_vmci/vmci_datagram.c:237 (tamaño 24) ADVERTENCIA: CPU: 0 PID: 1555 en drivers/misc/vmw_vmci /vmci_datagram.c:237 dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237 Algunos comentarios de código, según tengo entendido: 544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size ) /// Esto es 24 + payload_size memcpy(&dg_info->msg, dg, dg_size); Destino = dg_info->msg ---> esta es una estructura de 24 bytes (struct vmci_datagram) Fuente = dg --> esta es una estructura de 24 bytes (struct vmci_datagram) Tamaño = dg_size = 24 + payload_size {payload_size = 56-24 = 32} -- Syzkaller logró establecer payload_size en 32. 35 struct delay_datagram_info { 36 struct datagram_entry *entry; 37 struct work_struct work; 38 bool in_dg_host_queue; 39 /* msg y msg_payload deben estar juntos. */ 40 struct vmci_datagram mensaje; 41 u8 msg_payload[]; 42}; Entonces, esos bytes adicionales de payload se copian en msg_payload[], se ve una advertencia de tiempo de ejecución mientras se utiliza Syzkaller. Una forma posible de solucionar la advertencia es dividir memcpy() en dos partes: una, asignación directa del mensaje y la segunda, encargada del payload. Gustavo citó: "Bajo FORTIFY_SOURCE no debemos copiar datos entre varios miembros de una estructura".
Vulnerabilidad en kernel de Linux (CVE-2024-35950)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/client: Protege completamente los modos[] con dev->mode_config.mutex. La matriz modes[] contiene punteros a los modos en las listas de modos de los conectores, que están protegidos por dev- >mode_config.mutex. Por lo tanto, necesitamos extender modes[] la misma protección o, cuando la usemos, es posible que los elementos ya estén apuntando a la memoria liberada/reutilizada.
Vulnerabilidad en kernel de Linux (CVE-2024-35958)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ena: soluciona el comportamiento incorrecto sin descriptor. ENA tiene dos tipos de colas TX: - colas que solo procesan paquetes TX que llegan desde la pila de red - colas que solo procesan paquetes TX reenviados a mediante instrucciones XDP_REDIRECT o XDP_TX. Ena_free_tx_bufs() recorre todos los descriptores en una cola de TX y desasigna + libera todos los descriptores que aún no han sido reconocidos por el dispositivo (transacciones de TX incompletas). La función supone que la cola TX procesada es necesariamente de la primera categoría enumerada anteriormente y termina usando napi_consume_skb() para los descriptores que pertenecen a una cola XDP específica. Este parche resuelve un error por el cual, en caso de restablecer VF, los descriptores no se liberan correctamente, lo que provoca fallos.
Vulnerabilidad en kernel de Linux (CVE-2024-35962)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: validación completa de la entrada del usuario En mi confirmación reciente, omití que los controladores do_replace() usan copy_from_sockptr() (que arreglé), seguido de llamadas inseguras copy_from_sockptr_offset(). En todas las funciones, podemos realizar la validación @optlen incluso antes de llamar a xt_alloc_table_info() con la siguiente comprobación: if ((u64)optlen < (u64)tmp.size + sizeof(tmp)) return -EINVAL;
Vulnerabilidad en kernel de Linux (CVE-2024-35988)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: corrige TASK_SIZE en NOMMU de 64 bits En NOMMU, la memoria del espacio de usuario puede provenir de cualquier lugar de la RAM física. La definición actual de TASK_SIZE es incorrecta si existe RAM por encima de 4G, lo que provoca fallos falsos en las rutinas de acceso al espacio de usuario.
Vulnerabilidad en kernel de Linux (CVE-2024-35996)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cpu: vuelva a habilitar las mitigaciones de CPU de forma predeterminada para arquitecturas !X86. Cambie el nombre de x86 a CPU_MITIGATION, defínalo en código genérico y fuércelo para todas las arquitecturas con excepción de x86. Una confirmación reciente para desactivar las mitigaciones de forma predeterminada si SPECULATION_MITIGATION=n pasó por alto que "cpu_mitigations" es completamente genérico, mientras que SPECULATION_MITIGATIONS es específico de x86. Cambie el nombre de SPECULATIVE_MITIGATION de x86 en lugar de conservar ambos y haga que seleccione CPU_MITIGATION, ya que tener dos configuraciones para lo mismo es innecesario y confuso. Esto también permitirá que x86 use la perilla para administrar mitigaciones que no están estrictamente relacionadas con la ejecución especulativa. Utilice otro Kconfig para comunicar al código común que CPU_MITIGACIONES ya está definida en lugar de que el menú de x86 dependa de CPU_MITIGACIONES comunes. Esto permite mantener un único punto de contacto para todas las mitigaciones de x86, y no está claro que otras arquitecturas *quieran* permitir deshabilitar las mitigaciones en tiempo de compilación.
Vulnerabilidad en kernel de Linux (CVE-2024-36004)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i40e: no utilice el indicador WQ_MEM_RECLAIM para la cola de trabajo Problema informado por el cliente durante las pruebas SRIOV, seguimiento de llamadas: cuando se cargan tanto el i40e como el controlador i40iw, se activa una advertencia en check_flush_dependency. Esto parece deberse a que la cola de trabajo del controlador i40e está asignada con el indicador WQ_MEM_RECLAIM, y la del i40iw no. También se encontró un error similar en el ice y se solucionó quitando la bandera. Haz lo mismo con el i40e también. [9 de febrero 09:08] ------------[ cortar aquí ]------------ [ +0.000004] cola de trabajo: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] está vaciando !WQ_MEM_RECLAIM infiniband:0x0 [ +0.000060] ADVERTENCIA: CPU: 0 PID: 937 en kernel/workqueue.c:2966 check_flush_dependency+0x10b/0x120 [ +0.000007] Módulos vinculados en: snd_seq_dummy snd_hrtimer snd_seq snd_timer s nd_seq_device snd soundcore nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod fusible [+0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: cargado No contaminado 6.8.0 -rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Nombre del hardware: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 15/12/2020 [ +0.0000 01] Cola de trabajo: i40e i40e_service_task [i40e ] [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120 [ +0.000003] Código: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 RETRASOS: 00010282 [ + 0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [+0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 00000000000000000(0000) GS:ffff94d47f600000(000) 0) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ + 0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [+0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Seguimiento de llamadas : [ +0.000001] [ +0.000002] ? __advertir+0x80/0x130 [ +0.000003] ? check_flush_dependency+0x10b/0x120 [+0.000002]? report_bug+0x195/0x1a0 [+0.000005]? handle_bug+0x3c/0x70 [+0.000003]? exc_invalid_op+0x14/0x70 [+0.000002]? asm_exc_invalid_op+0x16/0x20 [+0.000006]? check_flush_dependency+0x10b/0x120 [+0.000002]? check_flush_dependency+0x10b/0x120 [ +0.000002] __flush_workqueue+0x126/0x3f0 [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core] [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core] +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core] [ +0.000020] i40iw_close+0x4b/0x90 [irdma] [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e] [ +0.000035] i40e_service_task+0x126/0x190 [i40e] [ +0.000 024] process_one_work+0x174/0x340 [+0.000003] worker_th ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-36005)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: honrar el indicador inactivo de la tabla desde la ruta del evento de lanzamiento de netdev. Verifique el indicador inactivo de la tabla; de lo contrario, la ruta del evento de lanzamiento de netdev intenta cancelar el registro de un enlace que ya no está registrado. [524854.857999] ------------[ cortar aquí ]------------ [524854.858010] ADVERTENCIA: CPU: 0 PID: 3386599 en net/netfilter/core.c :501 __nf_unregister_net_hook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 No contaminado 6.9.0-rc3+ #365 [524854.858869] Cola de trabajo: netns cleanup_net [524854 .858886] QEPD: 0010 :__nf_unregister_net_hook+0x21a/0x260 [524854.858903] Código: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 83 y sigs 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 24854.858926] RAX: 00000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 00000000000000 01 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 00000000000000005 [524854.858962] R13: 16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971 ] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Seguimiento de llamadas: [ 524854.859006] [524854.859013] ? __warn+0x9f/0x1a0 [524854.859027] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859044] ? report_bug+0x1b1/0x1e0 [524854.859060] ? handle_bug+0x3c/0x70 [524854.859071] ? exc_invalid_op+0x17/0x40 [524854.859083] ? asm_exc_invalid_op+0x1a/0x20 [524854.859100] ? __nf_unregister_net_hook+0x6a/0x260 [524854.859116] ? __nf_unregister_net_hook+0x21a/0x260 [524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables] [524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859461] ? packet_notifier+0xb3/0x360 [524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40 [524854.859489] ? dcbnl_netdevice_event+0x35/0x140 [524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables] [524854.859661] notifier_call_chain+0x7d/0x140 [524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0
Vulnerabilidad en kernel de Linux (CVE-2024-36006)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: corrige el uso incorrecto de la API de lista. Tanto la función que migra todos los fragmentos dentro de una región como la función que migra todas las entradas dentro de un fragmento llaman a list_first_entry() en el respectivo listas sin verificar que las listas no estén vacías. Este es un uso incorrecto de la API, lo que genera la siguiente advertencia [1]. Para solucionarlo, regrese si las listas están vacías, ya que en este caso no hay nada que migrar. [1] ADVERTENCIA: CPU: 0 PID: 6437 en drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0> Módulos vinculados en: CPU: 0 PID: 6437 Comm: kworker/0:37 No contaminado 6.9.0-rc3-custom-00883-g94a65f079ef6 #39 Nombre del hardware: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 06/01/2019 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP 0010:mlxsw_sp _acl_tcam_vchunk_migrate_all+0x1f1/0x2c0 [... ] Seguimiento de llamadas: mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0 Process_one_work+0x151/0x370 Workers_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x3 0
Vulnerabilidad en kernel de Linux (CVE-2024-36007)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: Advertencia de corrección durante el rehash Como se explicó anteriormente, el trabajo retrasado del rehash migra filtros de una región a otra. Esto se hace iterando sobre todos los fragmentos (todos los filtros con la misma prioridad) en la región y en cada fragmento iterando sobre todos los filtros. Cuando el trabajo se queda sin créditos, almacena el fragmento y la entrada actuales como marcadores en el contexto por trabajo para saber dónde reanudar la migración la próxima vez que se programe el trabajo. En caso de error, el marcador de fragmento se restablece a NULL, pero sin restablecer los marcadores de entrada a pesar de ser relativos a él. Esto puede provocar que la migración se reanude desde una entrada que no pertenece al fragmento que se está migrando. A su vez, esto eventualmente conducirá a que se repita un fragmento como si fuera una entrada. Debido a cómo se definen las dos estructuras, esto no genera símbolos KASAN, sino advertencias como [1]. Para solucionarlo, cree un asistente que restablezca todos los marcadores y llámelo desde todos los lugares donde actualmente solo restablece el marcador de fragmentos. Por si acaso, llámelo también al iniciar un rehash completamente nuevo. Agregue una advertencia para evitar casos futuros. [1] ADVERTENCIA: CPU: 7 PID: 1076 en drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0 Módulos vinculados en: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted : GW 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Nombre del hardware: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 06/01/2019 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP 0010:mlxsw_af k_encode+0x242/0x2f0 [... ] Seguimiento de llamadas: mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6 c/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50
Vulnerabilidad en kernel de Linux (CVE-2023-52880)
Severidad: MEDIA
Fecha de publicación: 24/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: n_gsm: requiere CAP_NET_ADMIN para adjuntar el ldisc N_GSM0710. Cualquier usuario sin privilegios puede adjuntar el ldisc N_GSM0710, pero de todos modos requiere CAP_NET_ADMIN para crear una red GSM. Requiere el espacio de nombres inicial CAP_NET_ADMIN para hacer eso.
Vulnerabilidad en kernel de Linux (CVE-2024-36017)
Severidad: MEDIA
Fecha de publicación: 30/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtnetlink: Validación correcta del atributo IFLA_VF_VLAN_LIST anidado. Se supone que cada atributo dentro de un IFLA_VF_VLAN_LIST anidado es una estructura ifla_vf_vlan_info, por lo que el tamaño de dicho atributo debe ser al menos de sizeof(struct ifla_vf_vlan_info), que es de 14 bytes. La validación de tamaño actual en do_setvfinfo es contra NLA_HDRLEN (4 bytes), que es menor que sizeof(struct ifla_vf_vlan_info), por lo que esta validación no es suficiente y un atributo demasiado pequeño podría convertirse en una estructura ifla_vf_vlan_info, esto podría resultar en un acceso de lectura fuera de banda al acceder a la entrada guardada (transmitida) en ivvl.
Vulnerabilidad en kernel de Linux (CVE-2024-36889)
Severidad: MEDIA
Fecha de publicación: 30/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mptcp: asegúrese de que snd_nxt se inicialice correctamente al conectar Christoph informó un símbolo que indica un snd_una dañado: ADVERTENCIA: CPU: 1 PID: 38 en net/mptcp/protocol.c:1005 __mptcp_clean_una +0x4b3/0x620 net/mptcp/protocol.c:1005 Módulos vinculados en: CPU: 1 PID: 38 Comm: kworker/1:1 No contaminado 6.9.0-rc1-gbbeac67456c9 #59 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 01/04/2014 Cola de trabajo: eventos mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Código: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: 3cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000000000 R11: fefefefefefefeff R12 : ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 00000000000000000(0000) GS:ffff88813bd00000(0000) nlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Rastreo de llamadas: __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [en línea] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [en línea] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/ 0x740 neto/ mptcp/protocol.c:2767 Process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 Process_scheduled_works kernel/workqueue.c:3335 [en línea] work_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread .c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 Cuando el retorno a TCP ocurre temprano en un socket de cliente , snd_nxt aún no está inicializado y cualquier confirmación entrante copiará dicho valor en snd_una. Si el trabajador mptcp (tontamente) intenta la reinyección a nivel de mptcp después de tal confirmación, eso desencadenaría incondicionalmente una sanitización del búfer de envío utilizando valores snd_una 'incorrectos'. Podríamos desactivar fácilmente la reinyección para los sockets de respaldo, pero un comportamiento tan tonto ya ayudó a detectar algunos problemas sutiles y un impacto de muy bajo a cero en la práctica. En su lugar, resuelva el problema siempre inicializando snd_nxt (y write_seq, para mantener la coherencia) en el momento de la conexión.
Vulnerabilidad en kernel de Linux (CVE-2024-36939)
Severidad: MEDIA
Fecha de publicación: 30/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: nfs: Maneja el error de rpc_proc_register() en nfs_net_init(). syzkaller informó que se activó una advertencia [0] al destruir redes inmaduras. Se llamó a rpc_proc_register() en init_nfs_fs(), pero su error se ignoró al menos desde el commit inicial 1da177e4c3f4 ("Linux-2.6.12-rc2"). Recientemente, el commit d47151b79e32 ("nfs: exponen /proc/net/sunrpc/nfs in net namespaces") convirtió los procfs a per-netns e hizo que el problema fuera más visible. Incluso cuando rpc_proc_register() falla, nfs_net_init() podría tener éxito y, por lo tanto, se llamará a nfs_net_exit() mientras se destruyen las redes. Luego, se llamará a remove_proc_entry() para un directorio proc no existente y se activará la siguiente advertencia. Manejemos el error de rpc_proc_register() correctamente en nfs_net_init(). [0]: nombre 'nfs' ADVERTENCIA: CPU: 1 PID: 1710 en fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Módulos vinculados en: CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/ 01/2014 RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Código: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 10286 RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001 RBP: 0000000000000000 R08: 00000000 00000001 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: 5741ff8 FS: 00007f30cfba8640(0000) GS: ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff51afe8000 CR3: 000000005a60a005 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 00000000000000000 DR6: 00000000ffe0ff0 DR7: 000000400 PKRU: 55555554 Llamar Seguimiento: rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310 nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438 ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170 setup_net+0x46c /0x660 net/core/net_namespace.c:372 copy_net_ns+0x244/0x590 net/core/net_namespace.c:505 create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228 ksys_unshare +0x342/0x760 kernel/fork.c:3322 __do_sys_unshare kernel/fork.c:3393 [en línea] __se_sys_unshare kernel/fork.c:3391 [en línea] __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391 do_syscall_x64 arch/x86/ entrada/common.c:52 [en línea] do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entrada_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0x7f30d0febe5d Código: ff c3 66 2e 0f 1f 84 00 00 0 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d X: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600 RBP: 00000000004bbf80 R08: 00000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000
Vulnerabilidad en kernel de Linux (CVE-2024-36950)
Severidad: MEDIA
Fecha de publicación: 30/05/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firewire: ohci: enmascara las interrupciones de reinicio del bus entre ISR y la mitad inferior. En el controlador de interrupciones FireWire OHCI, si se ha producido una interrupción de reinicio del bus, enmascara las interrupciones de reinicio del bus hasta que bus_reset_work haya sido reparado y borrado la interrupción. Normalmente, siempre dejamos enmascaradas las interrupciones de reinicio del bus. Inferimos el reinicio del bus a partir de la interrupción de la autoidentificación que ocurre poco después. En 2008 se introdujo un escenario en el que desenmascaramos las interrupciones de reinicio del bus en a007bb857e0b26f5d8b73c2ff90782d9c0972620: Si OHCI_PARAM_DEBUG_BUSRESETS (8) está configurado en la máscara de bits del parámetro de depuración, desenmascararemos las interrupciones de reinicio del bus para poder registrarlas. irq_handler registra la interrupción de reinicio del bus. Sin embargo, no podemos borrar el indicador de evento de reinicio del bus en irq_handler porque no atenderemos el evento hasta más tarde. irq_handler sale con el indicador de evento aún configurado. Si la interrupción correspondiente aún está desenmascarada, el primer reinicio del bus generalmente congelará el sistema debido a que se vuelve a llamar a irq_handler cada vez que sale. Esta congelación se puede reproducir cargando firewire_ohci con "modprobe firewire_ohci debug=-1" (para habilitar todos los resultados de depuración). Aparentemente, también hay algunos casos en los que se llamará a bus_reset_work lo suficientemente pronto como para borrar el evento y la operación continuará normalmente. Esta congelación se informó por primera vez unos meses después del commit a007bb85, pero hasta ahora nunca se había solucionado. El nivel de depuración podría establecerse de forma segura en -1 a través de sysfs después de cargar el módulo, pero esto sería ineficaz para registrar las interrupciones de reinicio del bus ya que sólo se desenmascararon durante la inicialización. irq_handler ahora dejará establecido el indicador de evento pero enmascarará las interrupciones de reinicio del bus, por lo que no se volverá a llamar a irq_handler y no se congelará. Si OHCI_PARAM_DEBUG_BUSRESETS está habilitado, bus_reset_work desenmascarará la interrupción después de atender el evento, por lo que las interrupciones futuras se detectarán según se desee. Como efecto secundario de este cambio, OHCI_PARAM_DEBUG_BUSRESETS ahora se puede habilitar a través de sysfs además de durante la carga inicial del módulo. Sin embargo, cuando se habilita a través de sysfs, el registro de interrupciones de reinicio del bus será efectivo solo a partir del segundo reinicio del bus, después de que se haya ejecutado bus_reset_work.
Vulnerabilidad en kernel de Linux (CVE-2024-36964)
Severidad: MEDIA
Fecha de publicación: 03/06/2024
Fecha de última actualización: 17/12/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/9p: solo traduce permisos RWX para 9P2000 simple. Se permite el paso de basura en bits permanentes de 9P2000 simple, lo que hace que pueda establecer (entre otros) el bit suid. Probablemente esta no era la intención, ya que los bits extendidos de Unix se manejan explícita y condicionalmente en .u.