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 la función de verificación en Encryption/Symmetric.php en Malcolm Fell jwt (CVE-2016-7037)
Severidad: ALTA
Fecha de publicación: 23/01/2017
Fecha de última actualización: 18/11/2025
La función de verificación en Encryption/Symmetric.php en Malcolm Fell jwt en versiones anteriores a 1.0.3 no utiliza una función segura de temporización para la comparación de hash, lo que permite a los atacantes suplantar firmas a través de un ataque de temporización.
Vulnerabilidad en las funciones de hashing HMAC en JWT (CVE-2021-41106)
Severidad: MEDIA
Fecha de publicación: 28/09/2021
Fecha de última actualización: 18/11/2025
JWT es una biblioteca para trabajar con JSON Web Token y JSON Web Signature. Antes de las versiones 3.4.6, 4.0.4 y 4.1.5, los usuarios de los algoritmos basados en HMAC (HS256, HS384 y HS512) combinados con "Lcobucci\JWT\Signer\Key\LocalFileReference" como clave están emitiendo/validando sus tokens usando la ruta del archivo como clave de hashing - en lugar del contenido. Las funciones de hashing HMAC aceptan cualquier cadena como entrada y, dado que los usuarios pueden emitir y comprobar tokens, los usuarios son llevados a creer que todo funciona correctamente. Las versiones 3.4.6, 4.0.4 y 4.1.5 han sido parcheadas para cargar siempre el contenido del archivo, desaprobando la función "Lcobucci\JWT\Signer\Key\LocalFileReference", y sugiriendo "Lcobucci\JWT\Signer\Key\InMemory" como alternativa. Como solución, use "Lcobucci\JWT\SignerKey\InMemory" en lugar de "Lcobucci\JWT\SignerKey\LocalFileReference" para crear las instancias de las claves propias
Vulnerabilidad en Veeam Backup para Microsoft Azure (CVE-2025-23082)
Severidad: ALTA
Fecha de publicación: 14/01/2025
Fecha de última actualización: 18/11/2025
Veeam Backup para Microsoft Azure es vulnerable a Server-Side Request Forgery (SSRF). Esto puede permitir que un atacante no autenticado envíe solicitudes no autorizadas desde el sistema, lo que podría provocar la enumeración de la red o facilitar otros ataques.
Vulnerabilidad en kernel de Linux (CVE-2025-37895)
Severidad: MEDIA
Fecha de publicación: 20/05/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Corregir la ruta de manejo de errores en bnxt_init_chip() WARN_ON() se activa en __flush_work() si bnxt_init_chip() falla porque llamamos a cancel_work_sync() en el trabajo de atenuación que no se ha inicializado. ADVERTENCIA: CPU: 37 PID: 5223 en kernel/workqueue.c:4201 __flush_work.isra.0+0x212/0x230 El controlador se basa en el bit BNXT_STATE_NAPI_DISABLED para comprobar si el trabajo de atenuación ya se ha cancelado. Pero en la ruta bnxt_open(), BNXT_STATE_NAPI_DISABLED no está configurado y esto hace que la ruta de error piense que necesita cancelar el trabajo de atenuación no inicializado. Corríjalo configurando BNXT_STATE_NAPI_DISABLED durante la inicialización. El bit se borrará cuando habilitemos NAPI e inicialicemos el trabajo de atenuación.
Vulnerabilidad en kernel de Linux (CVE-2025-38307)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: avs: Verificar el contenido devuelto por parse_int_array(). El primer elemento de la matriz devuelta almacena su longitud. Si es 0, cualquier manipulación más allá del elemento en el índice 0 termina con null-ptr-deref.
Vulnerabilidad en kernel de Linux (CVE-2025-38308)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: Intel: avs: Se corrige la posible desreferencia de PTR nula al inicializar hardware. El resultado de la búsqueda de avs_dai_find_path_template() debe verificarse antes de usarse. Dado que "template" ya se conoce al ejecutar avs_hw_constraints_init(), se omite la búsqueda por completo.
Vulnerabilidad en kernel de Linux (CVE-2025-38309)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/vm: mover xe_svm_init() antes. En xe_vm_close_and_put(), debemos poder llamar a xe_svm_fini(); sin embargo, durante la creación de la máquina virtual, podemos llamarlo en la ruta de error, antes de haber inicializado realmente el estado de svm, lo que provoca varios splats seguidos de un NPD fatal. (seleccionado del commit 4f296d77cf49fcb5f90b4674123ad7f3a0676165)
Vulnerabilidad en kernel de Linux (CVE-2025-38311)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iavf: eliminar el bloqueo crítico. Eliminar el bloqueo crítico. Esto nos libera de la lógica propensa a errores de try_locks. Gracias a netdev_lock() de Jakub, ahora es fácil, y en la mayoría de los casos ya estábamos protegidos por él: reemplazar el bloqueo crítico por el bloqueo netdev cuando no era el caso. Lockdep informa que debemos cancelar el trabajo bajo crit_lock [splat1], y ese fue el esquema que hemos seguido principalmente desde [1] de Slawomir. Pero una vez hecho esto, seguimos teniendo interbloqueos [splat2]. Así que, en lugar de eso, deberíamos analizar el problema más grave, es decir, el "bloqueo/programación extraño" de iavf. El primer paso para solucionarlo es eliminar el bloqueo crítico. Seguiré con una serie de -next que simplifica la programación/tareas. Cancelar el trabajo sin el bloqueo de netdev (un esquema extraño de desbloqueo y bloqueo) para corregir el [splat2] (que sería un desastre si hubiéramos mantenido el bloqueo crítico). Extender la parte protegida de iavf_watchdog_task() para incluir la programación de más trabajo. Tenga en cuenta que el comentario eliminado en iavf_reset_task() estaba mal ubicado; pertenecía a la condición if eliminada, por lo que ya no está. [splat1] - sin este parche - El bloqueo durante la eliminación de VF: ADVERTENCIA: se detectó una posible dependencia de bloqueo circular sh/3825 está intentando adquirir el bloqueo: ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, en: start_flush_work+0x1a1/0x470 pero la tarea ya tiene el bloqueo: (&adapter->crit_lock){+.+.}-{4:4}, en: iavf_remove+0xd1/0x690 [iavf] cuyo bloqueo ya depende del nuevo bloqueo. [splat2] - al cancelar trabajo bajo bloqueo crítico, sin esta serie, vea [2] para el intento de curita ADVERTENCIA: posible dependencia de bloqueo circular detectada sh/3550 está intentando adquirir el bloqueo: ((wq_completion)iavf){+.+.}-{0:0}, en: touch_wq_lockdep_map+0x26/0x90 pero la tarea ya tiene el bloqueo: (&dev->lock){+.+.}-{4:4}, en: iavf_remove+0xa6/0x6e0 [iavf] cuyo bloqueo ya depende del nuevo bloqueo. [1] fc2e6b3b132a ("iavf: Rehacer mutexes para mejor sincronización") [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a
Vulnerabilidad en kernel de Linux (CVE-2025-38314)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-pci: Se corrige el tamaño del resultado devuelto para la finalización del comando admin El tamaño del resultado devuelto por virtio_pci_admin_dev_parts_get() es 8 bytes más grande que el tamaño real de los datos del resultado. Esto ocurre porque el campo result_sg_size del comando se llena con la longitud del resultado de virtqueue_get_buf(), que incluye tanto el tamaño de los datos como 8 bytes adicionales de estado. Este tamaño de resultado sobredimensionado causa dos problemas: 1. El estado transferido al destino incluye 8 bytes de datos adicionales al final. 2. El búfer asignado en el kernel puede ser más pequeño que el tamaño devuelto, lo que provoca fallas al leer más allá del tamaño asignado. La confirmación corrige esto restando el tamaño del estado del resultado de virtqueue_get_buf(). Esta corrección se ha probado a través de migraciones en vivo con dispositivos virtio-net, virtio-net-transitional y virtio-blk.
Vulnerabilidad en kernel de Linux (CVE-2025-38315)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btintel: Verificar el tamaño de dsbr desde la variable EFI. Dado que el tamaño de struct btintel_dsbr ya se conoce, podemos empezar por ahí en lugar de consultar el tamaño de la variable EFI. Si el resultado final no coincide con lo esperado, también falla. Esto corrige un desbordamiento del búfer de pila cuando la variable EFI es mayor que struct btintel_dsbr.
Vulnerabilidad en kernel de Linux (CVE-2025-38316)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7996: evitar la desreferencia de punteros nulos en mt7996_set_monitor(). La función mt7996_set_monitor() desreferencia phy antes de la comprobación de validez de punteros nulos. Corrija esto para evitar la desreferencia de punteros nulos moviendo la desreferencia después de la comprobación.
Vulnerabilidad en kernel de Linux (CVE-2025-38317)
Severidad: ALTA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Se corrige el desbordamiento de búfer en debugfs. Si el usuario intenta escribir más de 32 bytes, se produce una corrupción de memoria. Afortunadamente, esto es debugfs, por lo que está limitado a usuarios root.
Vulnerabilidad en kernel de Linux (CVE-2025-38318)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: arm-ni: corrige la falta de platform_set_drvdata(). Agrega platform_set_drvdata() faltante en arm_ni_probe(); de lo contrario, llamar a platform_get_drvdata() en remove devuelve NULL.
Vulnerabilidad en kernel de Linux (CVE-2025-38321)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: Registra un error cuando close_all_cached_dirs falla. En condiciones de poca memoria, close_all_cached_dirs() no puede mover las entradas a una lista separada para dput() una vez que se eliminan los bloqueos. Esto generará un error "Dentry aún en uso", por lo que debe agregar un mensaje de error que aclare que esto es lo que sucedió: [ 495.281119] CIFS: VFS: \\otters.example.com\share Sin memoria al eliminar dentries [ 495.281595] ------------[ cortar aquí ]------------ [ 495.281887] ERROR: Dentry ffff888115531138{i=78,n=/} aún en uso (2) [desmontar cifs cifs] [ 495.282391] ADVERTENCIA: CPU: 1 PID: 2329 en fs/dcache.c:1536 umount_check+0xc8/0xf0 Además, abandone el bucle a través de todos los tcons tan pronto como falle una sola asignación, ya que estamos en problemas y kmalloc() intenta Es probable que las tcons subsiguientes fallen tal como lo hizo la primera.
Vulnerabilidad en kernel de Linux (CVE-2025-38325)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se añaden operaciones free_transport en la conexión ksmbd. La función free_transport para la conexión TCP se puede llamar desde smbdirect. Esto provoca errores en el kernel. Este parche añade operaciones free_transport en la conexión ksmbd y añade free_transport tanto para TCP como para smbdirect.
Vulnerabilidad en kernel de Linux (CVE-2025-38327)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fgraph: No habilitar el rastreador function_graph al configurar funcgraph-args. Al configurar la opción funcgraph-args cuando el rastreador de gráficos de funciones está habilitado en la red, lo habilita incorrectamente. Peor aún, se anula el registro cuando nunca se registró. Luego, cuando se habilita de nuevo, se registrará por segunda vez, lo que provocará una advertencia. ~# echo 1 > /sys/kernel/tracing/options/funcgraph-args ~# head -20 /sys/kernel/tracing/trace # tracer: nop # # entries-in-buffer/entries-written: 813/26317372 #P:8 # # _-----=> irqs-off/BH-disabled # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / _-=> migrate-disable # |||| / delay # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | -0 [007] d..4. 358.966010: 7) 1.692 us | fetch_next_timer_interrupt(basej=4294981640, basem=357956000000, base_local=0xffff88823c3ae040, base_global=0xffff88823c3af300, tevt=0xffff888100e47cb8); -0 [007] d..4. 358.966012: 7) | tmigr_cpu_deactivate(nextexp=357988000000) { -0 [007] d..4. 358.966013: 7) | _raw_spin_lock(lock=0xffff88823c3b2320) { -0 [007] d..4. 358.966014: 7) 0.981 us | preempt_count_add(val=1); -0 [007] d..5. 358.966017: 7) 1.058 us | do_raw_spin_lock(lock=0xffff88823c3b2320); -0 [007] d..4. 358.966019: 7) 5.824 us | } -0 [007] d..5. 358.966021: 7) | tmigr_inactive_up(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) { -0 [007] d..5. 358.966022: 7) | tmigr_update_events(group=0xffff888100cb9000, child=0x0, data=0xffff888100e47bc0) { Observe el "tracer: nop" en la parte superior. El trazador actual es el trazador "nop", pero el contenido es, obviamente, el trazador del grafo de funciones. Al habilitar el seguimiento del gráfico de funciones, se registrará nuevamente y se activará una advertencia en la contabilidad: ~# echo function_graph > /sys/kernel/tracing/current_tracer -bash: echo: error de escritura: Dispositivo o recurso ocupado Con el dmesg de: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 7 PID: 1095 at kernel/trace/ftrace.c:3509 ftrace_startup_subops+0xc1e/0x1000 Modules linked in: kvm_intel kvm irqbypass CPU: 7 UID: 0 PID: 1095 Comm: bash Not tainted 6.16.0-rc2-test-00006-gea03de4105d3 #24 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:ftrace_startup_subops+0xc1e/0x1000 Code: 48 b8 22 01 00 00 00 00 ad de 49 89 84 24 88 01 00 00 8b 44 24 08 89 04 24 e9 c3 f7 ff ff c7 04 24 ed ff ff ff e9 b7 f7 ff ff <0f> 0b c7 04 24 f0 ff ff ff e9 a9 f7 ff ff c7 04 24 f4 ff ff ff e9 RSP: 0018:ffff888133cff948 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 1ffff1102679ff31 RCX: 0000000000000000 RDX: 1ffffffff0b27a60 RSI: ffffffff8593d2f0 RDI: ffffffff85941140 RBP: 00000000000c2041 R08: ffffffffffffffff R09: ffffed1020240221 R10: ffff88810120110f R11: ffffed1020240214 R12: ffffffff8593d2f0 R13: ffffffff8593d300 R14: ffffffff85941140 R15: ffffffff85631100 FS: 00007f7ec6f28740(0000) GS:ffff8882b5251000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7ec6f181c0 CR3: 000000012f1d0005 CR4: 0000000000172ef0 Call Trace: ? __pfx_ftrace_startup_subops+0x10/0x10 ? find_held_lock+0x2b/0x80 ? ftrace_stub_direct_tramp+0x10/0x10 ? ftrace_stub_direct_tramp+0x10/0x10 ? trace_preempt_on+0xd0/0x110 ? __pfx_trace_graph_entry_args+0x10/ ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2025-38329)
Severidad: ALTA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: cs_dsp: Se corrige el acceso de lectura de memoria OOB en la prueba KUnit (información de wmfw) KASAN informó un acceso fuera de los límites - cs_dsp_mock_wmfw_add_info(), porque la longitud de la cadena de origen se redondeó al tamaño de asignación.
Vulnerabilidad en kernel de Linux (CVE-2025-38330)
Severidad: ALTA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: cs_dsp: Se corrige el acceso de lectura a memoria fuera de los límites en la prueba KUnit (caché CTL). KASAN reportó un acceso fuera de los límites: cs_dsp_ctl_cache_init_multiple_offsets(). El código usa mock_coeff_template.length_bytes (4 bytes) para la asignación de valores de registro. Sin embargo, posteriormente, esta longitud se establece en 8 bytes, lo que provoca fallos en el código de prueba. Como solución, simplemente elimine la anulación de longitud, manteniendo el valor original de 4 para todas las operaciones.
Vulnerabilidad en kernel de Linux (CVE-2025-38333)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para salir en get_new_segment() ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc pc : new_curseg+0x5e8/0x6dc Call trace: new_curseg+0x5e8/0x6dc f2fs_allocate_data_block+0xa54/0xe28 do_write_page+0x6c/0x194 f2fs_do_write_node_page+0x38/0x78 __write_node_page+0x248/0x6d4 f2fs_sync_node_pages+0x524/0x72c f2fs_write_checkpoint+0x4bc/0x9b0 __checkpoint_and_complete_reqs+0x80/0x244 issue_checkpoint_thread+0x8c/0xec kthread+0x114/0x1bc ret_from_fork+0x10/0x20 get_new_segment() detecta un estado inconsistente entre free_segmap y free_secmap, registremos dicho error en el superbloque y rescatemos get_new_segment() en lugar de continuar usando el segmento.
Vulnerabilidad en kernel de Linux (CVE-2025-38338)
Severidad: ALTA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/nfs/read: corrige error de doble desbloqueo en nfs_return_empty_folio() En ocasiones, cuando se leía un archivo mientras otro cliente NFS lo estaba truncando, el kernel podía bloquearse porque se llamaba a folio_unlock() dos veces y la segunda llamada XOR devolvería el indicador `PG_locked`. La mayoría de las veces (dependiendo del momento del truncamiento), nadie nota el problema porque folio_unlock() se llama tres veces, lo que desactiva `PG_locked`: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio El problema es que nfs_read_add_folio() no debe desbloquear el folio si fscache está habilitado, y falta una comprobación nfs_netfs_folio_unlock() en nfs_return_empty_folio(). En raras ocasiones, esto genera una advertencia en netfs_read_collection(): ------------[ cortar aquí ]------------ R=0000031c: el folio 10 no está bloqueado ADVERTENCIA: CPU: 0 PID: 29 en fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Cola de trabajo: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Rastreo de llamadas: netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0worker_thread+0x295/0x3a0 Sin embargo, la mayoría de las veces, los procesos simplemente se quedan atascados para siempre en folio_wait_bit_common(), esperando que `PG_locked` desaparezca, lo que nunca sucede porque nadie está realmente reteniendo el cerradura de folio.
Vulnerabilidad en kernel de Linux (CVE-2025-38339)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/bpf: corrección del cálculo del tamaño del código JIT del trampolín BPF. arch_bpf_trampoline_size() proporciona el tamaño JIT del trampolín BPF antes de asignar el búfer para su procesamiento JIT. El número total de instrucciones emitidas para el código JIT del trampolín BPF depende de la ubicación de la imagen final. Por lo tanto, el tamaño obtenido con el paso ficticio en arch_bpf_trampoline_size() puede variar del tamaño real necesario en arch_prepare_bpf_trampoline(). Cuando las instrucciones contabilizadas en arch_bpf_trampoline_size() son menores que la cantidad de instrucciones emitidas durante la compilación JIT real del trampolín, se produce la siguiente advertencia: ADVERTENCIA: CPU: 8 PID: 204190 en arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc que es: /* Asegúrese de que la lógica de generación del trampolín no se desborde */ if (image && WARN_ON_ONCE(&image[ctx->idx] > (u32 *)rw_image_end - BPF_INSN_SAFETY)) { Entonces, durante el pase ficticio, en lugar de proporcionar una ubicación de imagen arbitraria, tenga en cuenta la máxima cantidad de instrucciones posibles si y cuando exista una dependencia con la ubicación de la imagen para JIT.
Vulnerabilidad en kernel de Linux (CVE-2025-38340)
Severidad: ALTA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: cs_dsp: Se corrige el acceso de lectura de memoria OOB en la prueba KUnit KASAN informó un acceso fuera de los límites - cs_dsp_mock_bin_add_name_or_info(), porque la longitud de la cadena de origen se redondeó al tamaño de asignación.
Vulnerabilidad en kernel de Linux (CVE-2025-38341)
Severidad: ALTA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: fbnic: evita la doble liberación al no poder asignar DMA a FW msg. La semántica es que quien llama a fbnic_mbx_map_msg() conserva la propiedad del mensaje en caso de error. Todos los que llaman liberan la página correctamente.
Vulnerabilidad en kernel de Linux (CVE-2025-38343)
Severidad: MEDIA
Fecha de publicación: 10/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7996: la eliminación de fragmentos con RA de multidifusión o difusión. La fragmentación IEEE 802.11 solo se puede aplicar a tramas de unidifusión. Por lo tanto, se deben eliminar fragmentos con RA de multidifusión o difusión. Este parche corrige vulnerabilidades como CVE-2020-26145.
Vulnerabilidad en kernel de Linux (CVE-2025-38349)
Severidad: ALTA
Fecha de publicación: 18/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eventpoll: no decrementar el recuento de referencias de ep mientras se mantiene el mutex de ep. Jann Horn señala que epoll decrementa el recuento de referencias de ep y luego ejecuta un mutex_unlock(&ep->mtx);. Esto es totalmente erróneo, ya que puede provocar un use-after-free. Este patrón funciona correctamente para la última referencia, ya que el código en cuestión retrasará la llamada a "ep_free(ep)" hasta después de desbloquear el mutex. Sin embargo, es incorrecto para el caso mucho más sutil del penúltimo, cuando alguien *más* también podría eliminar su referencia y liberar el ep mientras aún usamos el mutex. Cabe destacar que esto es cierto incluso si ese otro usuario también usa el mismo mutex de ep: los mutex, a diferencia de los spinlocks, no se pueden usar para la propiedad de objetos, incluso si garantizan la exclusión mutua. Una operación de desbloqueo de mutex no es atómica, y como un usuario sigue accediendo al mutex durante el proceso de desbloqueo, otro usuario puede acceder y obtener el mutex liberado, liberando así la estructura de datos mientras el primer usuario realiza la limpieza. Consulte nuestra documentación sobre mutex en Documentation/locking/mutex-design.rst, en particular la sección [1] sobre semántica: «mutex_unlock() puede acceder a la estructura del mutex incluso después de haber liberado el bloqueo internamente; por lo tanto, no es seguro que otro contexto adquiera el mutex y asuma que el contexto mutex_unlock() ya no utiliza la estructura». Por lo tanto, si eliminamos nuestra referencia ep antes del desbloqueo del mutex, pero no fuimos los últimos, podríamos desbloquear el mutex; otro usuario entra, elimina su referencia y libera el 'ep', ya que ya no tiene usuarios, todo mientras mutex_unlock() sigue accediendo a él. Arregle esto simplemente moviendo el refcount ep que cae fuera del mutex: el refcount en sí es atómico y no necesita protección de mutex (ese es el _objetivo_ de los refcounts: a diferencia de los mutex, son inherentemente acerca de la duración de los objetos).
Vulnerabilidad en kernel de Linux (CVE-2025-38351)
Severidad: MEDIA
Fecha de publicación: 19/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/Hyper-V: Omisión de direcciones no canónicas durante el vaciado de TLB de PV. En invitados KVM con hiperllamadas de Hyper-V habilitadas, las hiperllamadas HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST y HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX permiten que un invitado solicite la invalidación de partes de una TLB virtual. Para ello, el parámetro hypercall incluye una lista de GVA que se supone que deben invalidarse. Sin embargo, cuando se pasan GVA no canónicos, actualmente no hay ningún filtrado implementado y finalmente se pasan a invocaciones comprobadas de INVVPID en Intel / INVLPGA en AMD. Mientras que el INVLPGA de AMD ignora silenciosamente las direcciones no canónicas (efectivamente, una operación nula), el INVVPID de Intel señala explícitamente VM-Fail y, en última instancia, activa WARN_ONCE en invvpid_error(): invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel] Seguimiento de llamadas: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel] kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm] Hyper-V informa que las GVA no válidas (aquellas que superan el espacio de GVA de una partición) deben ignorarse. Aunque no está del todo claro si esta regla también se aplica a las GVA no canónicas, es probable que sea correcto asumirlo, y las pruebas manuales en Azure confirman que Hyper-V "real" interpreta la especificación de la misma manera. Omita las GVA no canónicas al procesar la lista de direcciones para evitar el error INVVPID. Como alternativa, KVM podría filtrar los GVA "malos" antes de insertarlos en el FIFO, pero en términos prácticos, la única desventaja de trasladar la validación al procesamiento final es que hacerlo no es óptimo para el invitado y ningún invitado que se comporte bien solicitará vaciados de TLB para direcciones no canónicas.
Vulnerabilidad en kernel de Linux (CVE-2025-38353)
Severidad: MEDIA
Fecha de publicación: 25/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Se corrige la toma de un bloqueo no válido en una cuña. Si el dispositivo realiza una cuña durante, por ejemplo, la carga de GuC, el envío aún no está habilitado y el estado ni siquiera se inicializa. Se protege la llamada a la cuña para que no haga nada en este caso. Corrige el siguiente problema: [] xe 0000:bf:00.0: [drm] device wedged, needs recovery [] ------------[ cut here ]------------ [] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60 ... [] RIP: 0010:__mutex_lock+0x8a1/0xe60 [] mutex_lock_nested+0x1b/0x30 [] xe_guc_submit_wedge+0x80/0x2b0 [xe]
Vulnerabilidad en kernel de Linux (CVE-2025-38355)
Severidad: MEDIA
Fecha de publicación: 25/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe: Proceso diferido de eliminaciones de nodos GGTT al desenrollar el dispositivo Mientras drenamos indirectamente nuestra cola de trabajo dedicada ggtt->wq que usamos para completar la eliminación asincrónica de algunos nodos GGTT, esto sucede como parte del desenrollado de managed-drm (ggtt_fini_early), que podría ser posterior al desenrollado de managed-device, donde ya podríamos desasignar nuestra asignación MMIO/GMS (mmio_fini). Esto se observó recientemente durante una inicialización de VF fallida: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes) [ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes) [ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes) and this was leading to: [ ] BUG: unable to handle page fault for address: ffffc900058162a0 [ ] #PF: supervisor write access in kernel mode [ ] #PF: error_code(0x0002) - not-present page [ ] Oops: Oops: 0002 [#1] SMP NOPTI [ ] Tainted: [W]=WARN [ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe] [ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe] [ ] Call Trace: [ ] [ ] xe_ggtt_clear+0xb0/0x270 [xe] [ ] ggtt_node_remove+0xbb/0x120 [xe] [ ] ggtt_node_remove_work_func+0x30/0x50 [xe] [ ] process_one_work+0x22b/0x6f0 [ ] worker_thread+0x1e8/0x3d Se agregó una acción de dispositivo administrado que drenará explícitamente la cola de trabajo con todas las eliminaciones de nodos pendientes antes de liberar la asignación de MMIO/GSM. (Seleccionado del commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391)
Vulnerabilidad en kernel de Linux (CVE-2025-38356)
Severidad: MEDIA
Fecha de publicación: 25/07/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/guc: Salida explícita del modo seguro CT al desenrollar. Durante la prueba del controlador, podríamos usar brevemente el modo seguro CT, que se basa en un trabajo retrasado, pero normalmente podemos detenerlo una vez que IRQ esté completamente operativo. Sin embargo, si cancelamos la prueba antes de tiempo, durante la desenrollación podríamos intentar destruir la cola de trabajos mientras aún haya un trabajo retrasado pendiente que intenta reiniciarse, lo que activa una advertencia. Esto se observó recientemente durante una inicialización de VF fallida: [ ] xe 0000:00:02.1: probe with driver xe failed with error -62 [ ] ------------[ cut here ]------------ [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710 [ ] RIP: 0010:__queue_work+0x287/0x710 [ ] Call Trace: [ ] delayed_work_timer_fn+0x19/0x30 [ ] call_timer_fn+0xa1/0x2a0 Salga del modo seguro de CT al desenrollar para evitar esa advertencia. (seleccionado del commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)