Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Vulnerabilidades

Con el objetivo de informar, advertir y ayudar a los profesionales sobre las ultimas vulnerabilidades de seguridad en sistemas tecnológicos, ponemos a disposición de los usuarios interesados en esta información una base de datos con información en castellano sobre cada una de las ultimas vulnerabilidades documentadas y conocidas.

Este repositorio con más de 75.000 registros esta basado en la información de NVD (National Vulnerability Database) – en función de un acuerdo de colaboración – por el cual desde INCIBE realizamos la traducción al castellano de la información incluida. En ocasiones este listado mostrará vulnerabilidades que aún no han sido traducidas debido a que se recogen en el transcurso del tiempo en el que el equipo de INCIBE realiza el proceso de traducción.

Se emplea el estándar de nomenclatura de vulnerabilidades CVE (Common Vulnerabilities and Exposures), con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Cada una de las vulnerabilidades recogidas enlaza a diversas fuentes de información así como a parches disponibles o soluciones aportadas por los fabricantes y desarrolladores. Es posible realizar búsquedas avanzadas teniendo la opción de seleccionar diferentes criterios como el tipo de vulnerabilidad, fabricante, tipo de impacto entre otros, con el fin de acortar los resultados.

Mediante suscripción RSS o Boletines podemos estar informados diariamente de las ultimas vulnerabilidades incorporadas al repositorio.

Vulnerabilidad en kernel de Linux (CVE-2024-43878)

Fecha de publicación:
21/08/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: corrige el error de acceso a la memoria de la ruta de entrada Cuando hay una mala configuración del estado de entrada, la ruta lenta KASAN informa el error. Corrija este error. inicio de sesión oeste: [52.987278] eth1: renombrado de veth11 [53.078814] eth1: renombrado de veth21 [53.181355] eth1: renombrado de veth31 [54.921702] ===================== =============================================== [ 54.922602] ERROR : KASAN: acceso a memoria salvaje en xfrmi_rcv_cb+0x2d/0x295 [ 54.923393] Lectura de tamaño 8 en la dirección 6b6b6b6b00000000 mediante tarea ping/512 [ 54.924169] [ 54.924386] CPU: 0 PID: 512 Comm: ping No contaminado 6. 9.0- 08574-gcd29a4313a1b #25 [ 54.925290] Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 [ 54.926401] Seguimiento de llamadas: [ 54.926731] [54.927009] dump_stack_lvl+0x2a/0x3b [54.927478] kasan_report+0x84/0xa6 [54.927930]? xfrmi_rcv_cb+0x2d/0x295 [ 54.928410] xfrmi_rcv_cb+0x2d/0x295 [ 54.928872] ? xfrm4_rcv_cb+0x3d/0x5e [ 54.929354] xfrm4_rcv_cb+0x46/0x5e [ 54.929804] xfrm_rcv_cb+0x7e/0xa1 [ 54.930240] xfrm_input+0x1b3a/0x1b96 [ 54.930715] ? xfrm_offload+0x41/0x41 [54.931182]? raw_rcv+0x292/0x292 [54.931617]? nf_conntrack_confirm+0xa2/0xa2 [54.932158]? skb_sec_path+0xd/0x3f [54.932610]? xfrmi_input+0x90/0xce [ 54.933066] xfrm4_esp_rcv+0x33/0x54 [ 54.933521] ip_protocol_deliver_rcu+0xd7/0x1b2 [ 54.934089] ip_local_deliver_finish+0x110/0x120 [ 54.93 4659] ? ip_protocol_deliver_rcu+0x1b2/0x1b2 [ 54.935248] NF_HOOK.constprop.0+0xf8/0x138 [ 54.935767] ? ip_sublist_rcv_finish+0x68/0x68 [54.936317]? ¿secure_tcpv6_ts_off+0x23/0x168 [54.936859]? ip_protocol_deliver_rcu+0x1b2/0x1b2 [54.937454]? __xfrm_policy_check2.constprop.0+0x18d/0x18d [ 54.938135] NF_HOOK.constprop.0+0xf8/0x138 [ 54.938663] ? ip_sublist_rcv_finish+0x68/0x68 [54.939220]? __xfrm_policy_check2.constprop.0+0x18d/0x18d [54.939904]? ip_local_deliver_finish+0x120/0x120 [ 54.940497] __netif_receive_skb_one_core+0xc9/0x107 [ 54.941121] ? __netif_receive_skb_list_core+0x1c2/0x1c2 [54.941771]? blk_mq_start_stopped_hw_queues+0xc7/0xf9 [54.942413]? blk_mq_start_stopped_hw_queue+0x38/0x38 [54.943044]? virtqueue_get_buf_ctx+0x295/0x46b [ 54.943618] Process_backlog+0xb3/0x187 [ 54.944102] __napi_poll.constprop.0+0x57/0x1a7 [ 54.944669] net_rx_action+0x1cb/0x380 [ 54.94 5150] ? __napi_poll.constprop.0+0x1a7/0x1a7 [54.945744]? vring_new_virtqueue+0x17a/0x17a [54.946300]? note_interrupt+0x2cd/0x367 [ 54.946805] handle_softirqs+0x13c/0x2c9 [ 54.947300] do_softirq+0x5f/0x7d [ 54.947727] [ 54.948014] [ 54.948300] _enable_ip+0x48/0x62 [ 54.948832] __neigh_event_send+0x3fd/0x4ca [ 54.949361] neigh_resolve_output+0x1e/0x210 [ 54.949896] ip_finish_output2+0x4bf/0x4f0 [ 54.950410] ? __ip_finish_output+0x171/0x1b8 [ 54.950956] ip_send_skb+0x25/0x57 [ 54.951390] raw_sendmsg+0xf95/0x10c0 [ 54.951850] ? check_new_pages+0x45/0x71 [ 54.952343] ? raw_hash_sk+0x21b/0x21b [54.952815]? kernel_init_pages+0x42/0x51 [54.953337]? prep_new_page+0x44/0x51 [54.953811]? get_page_from_freelist+0x72b/0x915 [54.954390]? signal_pending_state+0x77/0x77 [54.954936]? preempt_count_sub+0x14/0xb3 [54.955450]? __might_resched+0x8a/0x240 [ 54.955951] ? __might_sleep+0x25/0xa0 [ 54.956424] ? first_zones_zonelist+0x2c/0x43 [ 54.956977] ? __rcu_read_lock+0x2d/0x3a [ 54.957476] ? __pte_offset_map+0x32/0xa4 [54.957980]? __might_resched+0x8a/0x240 [ 54.958483] ? __might_sleep+0x25/0xa0 [ 54.958963] ? inet_send_prepare+0x54/0x54 [54.959478]? sock_sendmsg_nosec+0x42/0x6c [ 54.960000] sock_sendmsg_nosec+0x42/0x6c [ 54.960502] __sys_sendto+0x15d/0x1cc [ 54.960966] ? __x64_sys_getpeername+0x44/0x44 [ 54.961522] ? __handle_mm_fault+0x679/0xae4 [ 54.962068] ? find_vma+0x6b/0x ---truncado---
Gravedad CVSS v3.1: ALTA
Última modificación:
26/09/2025

Vulnerabilidad en kernel de Linux (CVE-2024-43881)

Fecha de publicación:
21/08/2024
Idioma:
Español
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath12k: cambia la dirección de DMA al mapear paquetes reinyectados. Para paquetes fragmentados, ath12k vuelve a ensamblar cada fragmento como un paquete normal y luego lo reinyecta en el anillo HW. En este caso, la dirección DMA debe ser DMA_TO_DEVICE, no DMA_FROM_DEVICE. De lo contrario, se puede reinyectar una carga útil no válida en el HW y posteriormente entregarla al host. Dado que se puede asignar memoria arbitraria al búfer skb, falta conocimiento sobre los datos contenidos en el búfer reinyectado. En consecuencia, existe el riesgo de que se filtre información privada. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1
Gravedad CVSS v3.1: ALTA
Última modificación:
26/09/2025

Vulnerabilidad en kernel de Linux (CVE-2024-43877)

Fecha de publicación:
21/08/2024
Idioma:
Español
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: pci: ivtv: Agregar verificación para el resultado del mapa DMA En caso de que DMA falle, 'dma->SG_length' es 0. Este valor se usa luego para acceder a 'dma->SGarray [dma->SG_length - 1]', lo que provocará un acceso fuera de los límites. Agregue un cheque para devolver anticipadamente un valor no válido. Ajuste las advertencias en consecuencia. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.
Gravedad CVSS v3.1: ALTA
Última modificación:
03/11/2025

Vulnerabilidad en kernel de Linux (CVE-2024-43879)

Fecha de publicación:
21/08/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: maneja la asignación de 2x996 RU en cfg80211_calculate_bitrate_he() Actualmente, NL80211_RATE_INFO_HE_RU_ALLOC_2x996 no se maneja en cfg80211_calculate_bitrate_he(), lo que genera la siguiente advertencia: kernel: invalid HE MCS: bw:6, ru :6 kernel: ADVERTENCIA: CPU: 0 PID: 2312 en net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Solucionelo manejando la asignación de 2x996 RU de la misma manera que el ancho de banda de 160 MHz.
Gravedad CVSS v3.1: MEDIA
Última modificación:
03/11/2025

Vulnerabilidad en kernel de Linux (CVE-2024-43880)

Fecha de publicación:
21/08/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_erp: corrige la advertencia de anidamiento de objetos. Las ACL en Spectrum-2 y los ASIC más nuevos pueden residir en el TCAM algorítmico (A-TCAM) o en el TCAM de circuito ordinario (C-TCAM). El primero puede contener más ACL (es decir, filtros tc), pero el número de máscaras en cada región (es decir, cadena tc) es limitado. Para mitigar los efectos de la limitación anterior, el dispositivo permite que los filtros compartan una única máscara si sus máscaras solo difieren en hasta 8 bits consecutivos. Por ejemplo, dst_ip/25 se puede representar usando dst_ip/24 con un delta de 1 bit. C-TCAM no tiene un límite en la cantidad de máscaras que se utilizan (y por lo tanto no admite la agregación de máscaras), pero puede contener una cantidad limitada de filtros. El controlador utiliza la librería "objagg" para realizar la agregación de máscaras pasándole objetos que constan de la máscara del filtro y si el filtro se insertará en la A-TCAM o en la C-TCAM, ya que los filtros en diferentes TCAM no pueden compartir una máscara. El conjunto de objetos creados depende del orden de inserción de los filtros y no es necesariamente óptimo. Por lo tanto, el controlador solicitará periódicamente a la librería que calcule un conjunto más óptimo ("sugerencias") observando todos los objetos existentes. Cuando la librería pregunta al controlador si se pueden agregar dos objetos, el controlador solo compara las máscaras proporcionadas e ignora la indicación A-TCAM/C-TCAM. Esto es lo correcto ya que el objetivo es mover tantos filtros como sea posible a la A-TCAM. El driver también prohíbe agregar dos máscaras idénticas, ya que esto solo puede suceder si una se colocó intencionalmente en la C-TCAM para evitar un conflicto en la A-TCAM. Lo anterior puede dar como resultado el siguiente conjunto de sugerencias: H1: {máscara X, A-TCAM} -> H2: {máscara Y, A-TCAM} // X es Y + delta H3: {máscara Y, C-TCAM} -> H4: {máscara Z, A-TCAM} // Y es Z + delta Después de obtener las sugerencias de la librería, el controlador comenzará a migrar filtros de una región a otra mientras consulta las sugerencias calculadas e indica al dispositivo que realice una búsqueda. en ambas regiones durante la transición. Suponiendo que se está migrando un filtro con máscara X a la A-TCAM en la nueva región, la búsqueda de sugerencias devolverá H1. Dado que H2 es el padre de H1, la librería intentará encontrar el objeto asociado con él y crearlo si es necesario, en cuyo caso se realizará otra búsqueda de sugerencias (recursiva). Esta búsqueda de sugerencias para {máscara Y, A-TCAM} devolverá H2 o H3 ya que el controlador pasa a la librería una función de comparación de objetos que ignora la indicación A-TCAM/C-TCAM. En última instancia, esto puede conducir a objetos anidados que no son compatibles con la librería [1]. Para solucionarlo, elimine la función de comparación de objetos tanto del controlador como de la librería, ya que el controlador era el único usuario. De esa forma, la búsqueda solo arrojará coincidencias exactas. No tengo un reproductor confiable que pueda reproducir el problema de manera oportuna, pero antes de solucionarlo, el problema se reproducía en varios minutos y con la solución no se reproduce en más de una hora. Tenga en cuenta que la utilidad actual de las sugerencias es limitada porque incluyen la indicación C-TCAM y representan una agregación que en realidad no puede ocurrir. Esto se abordará en net-next. [1] ADVERTENCIA: CPU: 0 PID: 153 en lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0 Módulos vinculados en: CPU: 0 PID: 153 Comm: kworker/0:18 No contaminado 6.9.0-rc6-custom -g70fbc2c1c38b #42 Nombre del hardware: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0 [...] Seguimiento de llamadas: < TAREA> ---truncado----
Gravedad CVSS v3.1: MEDIA
Última modificación:
03/11/2025

Vulnerabilidad en kernel de Linux (CVE-2024-43882)

Fecha de publicación:
21/08/2024
Idioma:
Español
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.
Gravedad CVSS v3.1: ALTA
Última modificación:
03/11/2025

Vulnerabilidad en kernel de Linux (CVE-2024-43872)

Fecha de publicación:
21/08/2024
Idioma:
Español
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.
Gravedad CVSS v3.1: MEDIA
Última modificación:
03/09/2024

Vulnerabilidad en kernel de Linux (CVE-2024-43874)

Fecha de publicación:
21/08/2024
Idioma:
Español
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---
Gravedad CVSS v3.1: MEDIA
Última modificación:
03/09/2024

Vulnerabilidad en kernel de Linux (CVE-2024-43869)

Fecha de publicación:
21/08/2024
Idioma:
Español
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.
Gravedad CVSS v3.1: MEDIA
Última modificación:
03/11/2025

Vulnerabilidad en kernel de Linux (CVE-2024-43870)

Fecha de publicación:
21/08/2024
Idioma:
Español
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().
Gravedad CVSS v3.1: MEDIA
Última modificación:
03/11/2025

Vulnerabilidad en kernel de Linux (CVE-2024-43871)

Fecha de publicación:
21/08/2024
Idioma:
Español
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().
Gravedad CVSS v3.1: MEDIA
Última modificación:
03/11/2025

Vulnerabilidad en kernel de Linux (CVE-2024-43873)

Fecha de publicación:
21/08/2024
Idioma:
Español
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
Gravedad CVSS v3.1: ALTA
Última modificación:
03/11/2025