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 BIG-IP AFM (CVE-2024-25560)
Severidad: ALTA
Fecha de publicación: 08/05/2024
Fecha de última actualización: 21/10/2025
Cuando se otorga licencia y aprovisionamiento de BIG-IP AFM, el tráfico DNS no divulgado puede provocar la finalización del Microkernel de gestión de tráfico (TMM). Nota: Las versiones de software que han llegado al final del soporte técnico (EoTS) no se evalúan.
-
Vulnerabilidad en BIG-IP (CVE-2024-31156)
Severidad: ALTA
Fecha de publicación: 08/05/2024
Fecha de última actualización: 21/10/2025
Existe una vulnerabilidad de cross site scripting (XSS) almacenado en una página no divulgada de la utilidad de configuración BIG-IP que permite a un atacante ejecutar JavaScript en el contexto del usuario actualmente conectado. Nota: Las versiones de software que han llegado al final del soporte técnico (EoTS) no se evalúan.
-
Vulnerabilidad en BIG-IP (CVE-2024-32761)
Severidad: MEDIA
Fecha de publicación: 08/05/2024
Fecha de última actualización: 21/10/2025
Bajo ciertas condiciones, puede ocurrir una posible fuga de datos en los micronúcleos de administración de tráfico (TMM) de los inquilinos de BIG-IP que se ejecutan en plataformas VELOS y rSeries. Sin embargo, un atacante no puede aprovechar este problema porque no se puede reproducir de forma consistente y está fuera de su control. Nota: Las versiones de software que han llegado al final del soporte técnico (EoTS) no se evalúan
-
Vulnerabilidad en BIG-IP (CVE-2024-33604)
Severidad: MEDIA
Fecha de publicación: 08/05/2024
Fecha de última actualización: 21/10/2025
Existe una vulnerabilidad de cross site scripting (XSS) reflejado en una página no revelada de la utilidad de configuración BIG-IP que permite a un atacante ejecutar JavaScript en el contexto del usuario actualmente conectado. Nota: Las versiones de software que han llegado al final del soporte técnico (EoTS) no se evalúan
-
Vulnerabilidad en F5 Networks (CVE-2024-33608)
Severidad: ALTA
Fecha de publicación: 08/05/2024
Fecha de última actualización: 21/10/2025
Cuando se configura IPsec en un servidor virtual, el tráfico no divulgado puede provocar la finalización del Microkernel de gestión de tráfico (TMM). Nota: Las versiones de software que han llegado al final del soporte técnico (EoTS) no se evalúan.
-
Vulnerabilidad en RunGptLLM (CVE-2024-4181)
Severidad: ALTA
Fecha de publicación: 16/05/2024
Fecha de última actualización: 21/10/2025
Existe una vulnerabilidad de inyección de comandos en la clase RunGptLLM de la librería llama_index, versión 0.9.47, utilizada por el marco RunGpt de JinaAI para conectarse a los modelos de aprendizaje de idiomas (LLM). La vulnerabilidad surge del uso inadecuado de la función de evaluación, lo que permite que un proveedor de alojamiento LLM malicioso o comprometido ejecute comandos arbitrarios en la máquina del cliente. Este problema se solucionó en la versión 0.10.13. La explotación de esta vulnerabilidad podría llevar a que un proveedor de alojamiento obtenga control total sobre las máquinas cliente.
-
Vulnerabilidad en RTI Connext Professional (CVE-2024-25724)
Severidad: ALTA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 21/10/2025
En RTI Connext Professional 5.3.1 a 6.1.0 anterior a 6.1.1, un desbordamiento del búfer en el análisis XML del servicio de enrutamiento, el servicio de grabación, el servicio de colas y el servicio de descubrimiento en la nube permite a los atacantes ejecutar código con los privilegios del servicio afectado y comprometer la seguridad del servicio. integridad, filtrar información confidencial o bloquear el servicio. Estos ataques podrían realizarse a través de un mensaje RTPS malicioso remoto; una llamada comprometida con parámetros maliciosos a las API públicas RTI_RoutingService_new, rti::recording::Service, RTI_QueuingService_new o RTI_CDS_Service_new; o un sistema de archivos local comprometido que contiene un archivo XML malicioso.
-
Vulnerabilidad en Meshtastic (CVE-2024-45038)
Severidad: ALTA
Fecha de publicación: 27/08/2024
Fecha de última actualización: 21/10/2025
El firmware del dispositivo Meshtastic es un firmware para que los dispositivos meshtastic ejecuten una red de malla de código abierto, fuera de la red, descentralizada y diseñada para funcionar en dispositivos asequibles y de bajo consumo. El firmware del dispositivo Meshtastic está sujeto a una vulnerabilidad de denegación de servicio en el manejo de MQTT, corregida en la versión 2.4.1 del firmware Meshtastic y en el Broker MQTT público Meshtastic. Se recomienda encarecidamente que todos los usuarios de Meshtastic, especialmente aquellos que se conectan a un servidor MQTT alojado de forma privada, actualicen a esta o a una versión estable más reciente de inmediato. No se conocen workarounds para esta vulnerabilidad.
-
Vulnerabilidad en Meshtastic (CVE-2024-47079)
Severidad: MEDIA
Fecha de publicación: 07/10/2024
Fecha de última actualización: 21/10/2025
Meshtastic es una red en malla descentralizada, fuera de la red y de código abierto diseñada para funcionar en dispositivos asequibles y de bajo consumo. El firmware Meshtastic es una implementación de firmware de código abierto para un proyecto más amplio. El módulo de hardware remoto del firmware no tiene las comprobaciones adecuadas para garantizar que se reciba un mensaje de control de hardware remoto que se considere válido. Este problema se ha solucionado en la versión 2.5.1. Se recomienda a todos los usuarios que actualicen. No existen workarounds conocidas para esta vulnerabilidad.
-
Vulnerabilidad en F5 Networks (CVE-2024-45844)
Severidad: ALTA
Fecha de publicación: 16/10/2024
Fecha de última actualización: 21/10/2025
La función de monitorización de BIG-IP puede permitir que un atacante eluda las restricciones de control de acceso, independientemente de la configuración de bloqueo de puertos. Nota: Las versiones de software que han alcanzado el fin del soporte técnico (EoTS) no se evalúan.
-
Vulnerabilidad en 1902756969 reggie 1.0 (CVE-2025-0401)
Severidad: MEDIA
Fecha de publicación: 13/01/2025
Fecha de última actualización: 21/10/2025
Se ha encontrado una vulnerabilidad clasificada como crítica en 1902756969 reggie 1.0. La función de descarga del archivo src/main/java/com/itheima/reggie/controller/CommonController.java se ve afectada. La manipulación del nombre del argumento provoca un path traversal. Es posible lanzar el ataque de forma remota. El exploit se ha hecho público y puede utilizarse.
-
Vulnerabilidad en 1902756969 reggie 1.0 (CVE-2025-0402)
Severidad: MEDIA
Fecha de publicación: 13/01/2025
Fecha de última actualización: 21/10/2025
Se ha encontrado una vulnerabilidad clasificada como crítica en 1902756969 reggie 1.0. Esta vulnerabilidad afecta la función de carga del archivo src/main/java/com/itheima/reggie/controller/CommonController.java. La manipulación del archivo de argumentos permite una carga sin restricciones. El ataque puede ejecutarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse.
-
Vulnerabilidad en 1902756969 reggie 1.0 (CVE-2025-0403)
Severidad: MEDIA
Fecha de publicación: 13/01/2025
Fecha de última actualización: 21/10/2025
Se ha encontrado una vulnerabilidad clasificada como problemática en 1902756969 reggie 1.0. Este problema afecta a una funcionalidad desconocida del archivo /user/sendMsg del componente Phone Number Validation Handler. La manipulación del código de argumentos conduce a la divulgación de información. El ataque puede ejecutarse de forma remota. El exploit se ha hecho público y puede utilizarse.
-
Vulnerabilidad en kernel de Linux (CVE-2024-57888)
Severidad: MEDIA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: workqueue: No advertir al cancelar el trabajo de WQ_MEM_RECLAIM del trabajador !WQ_MEM_RECLAIM Después de la confirmación 746ae46c1113 ("drm/sched: Marcar las colas de trabajo del programador con WQ_MEM_RECLAIM") amdgpu comenzó a ver la siguiente advertencia: [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu] ... [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched] ... [ ] Call Trace: [ ] ... [ ] ? check_flush_dependency+0xf5/0x110 ... [ ] cancel_delayed_work_sync+0x6e/0x80 [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu] [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu] [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu] [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched] [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu] [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched] [ ] process_one_work+0x217/0x720 ... [ ] La intención de la verificación realizada en check_flush_depedency es asegurar el progreso hacia adelante durante la recuperación de memoria, marcando los casos en los que un proceso de recuperación de memoria o un elemento de trabajo de recuperación de memoria se vacían de un contexto no marcado como seguro para la recuperación de memoria. Esto es correcto durante el vaciado, pero cuando se llama desde las rutas cancel(_delayed)_work_sync() es un falso positivo porque el trabajo ya se está ejecutando o no se ejecutará en absoluto. Por lo tanto, cancelarlo es seguro y podemos relajar los criterios de advertencia informando al asistente del contexto de llamada. Referencias: 746ae46c1113 ("drm/sched: Marcar las colas de trabajo del programador con WQ_MEM_RECLAIM")
-
Vulnerabilidad en kernel de Linux (CVE-2024-57897)
Severidad: MEDIA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Corrija la dirección del mapa DMA de migración La dirección del mapa del dispositivo DMA de SVM debe configurarse igual que la configuración de anulación del mapa DMA; de lo contrario, el núcleo DMA informará la siguiente advertencia. Antes de finalizar esta solución, hay una discusión sobre el tipo de mapeo DMA (basado en flujo o coherente) en este caso de migración KFD, seguido de https://lore.kernel.org/all/04d4ab32 -45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/. Como no hay dma_sync_single_for_*() en el búfer DMA al que se accede, esto se debe a que esta operación de migración debe sincronizarse de manera adecuada y automática. Dado que es posible que no haya un problema de rendimiento en varias políticas de sincronización de caché de la sincronización DMA. Por lo tanto, para simplificar la alineación de la configuración de la dirección DMA, configuremos la dirección del mapa DMA como BIDIRECCIONAL. [ 150.834218] ADVERTENCIA: CPU: 8 PID: 1812 en kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930 [ 150.834225] Módulos vinculados en: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter overlay nvme_fabrics nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd leds de entrada [ 150.834310] wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [ 150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Contaminado: G OE 6.10.0-custom #492 [ 150.834358] Nombre del hardware: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 13/06/2021 [ 150.834360] RIP: 0010:check_unmap+0x1cc/0x930 [ 150.834363] Código: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff <0f> 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50 [ 150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086 [ 150.834368] RAX: 00000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027 [ 150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680 [ 150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850 [ 150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40 [ 150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b [ 150.834377] FS: 00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000 [ 150.834379] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0 [ 150.834383] Seguimiento de llamadas: [ 150.834385] [ 150.834387] ? show_regs+0x6d/0x80 [ 150.834393] ? __warn+0x8c/0x140 [ 150.834397] ? check_unmap+0x1cc/0x930 [ 150.834400] ? report_bug+0x193/0x1a0 [ 150.834406] ? exc_invalid_op+0x1d/0x80 [ 150.834413] ? asm_exc_invalid_op+0x1f/0x30 [ 150.834420] ? check_unmap+0x1cc/0x930 [ 150.834425] debug_dma_unmap_page+0x86/0x90 [ 150.834431] ? ---truncado---
-
Vulnerabilidad en iControl REST y BIG-IP TMOS Shell (CVE-2025-20029)
Severidad: ALTA
Fecha de publicación: 05/02/2025
Fecha de última actualización: 21/10/2025
Existe una vulnerabilidad de inyección de comandos en el comando de guardado de iControl REST y BIG-IP TMOS Shell (tmsh), que puede permitir que un atacante autenticado ejecute comandos arbitrarios del sistema. Nota: Las versiones de software que han alcanzado el fin del soporte técnico (EoTS) no se evalúan.
-
Vulnerabilidad en F5 Networks (CVE-2025-20045)
Severidad: ALTA
Fecha de publicación: 05/02/2025
Fecha de última actualización: 21/10/2025
Cuando el perfil de modo de puerta de enlace de nivel de aplicación (ALG) de sesión SIP con modo Passthru habilitado y el perfil ALG SIP router se configuran en un servidor virtual de tipo de enrutamiento de mensajes, el tráfico no revelado puede provocar la finalización del microkernel de administración de tráfico (TMM). Nota: Las versiones de software que han llegado al final del soporte técnico (EoTS) no se evalúan.
-
Vulnerabilidad en F5 Networks (CVE-2025-20058)
Severidad: ALTA
Fecha de publicación: 05/02/2025
Fecha de última actualización: 21/10/2025
Cuando se configura un perfil de enrutamiento de mensajes BIG-IP en un servidor virtual, el tráfico no revelado puede provocar un aumento en la utilización de recursos de memoria. Nota: Las versiones de software que han llegado al final del soporte técnico (EoTS) no se evalúan.
-
Vulnerabilidad en F5 Networks (CVE-2025-21087)
Severidad: ALTA
Fecha de publicación: 05/02/2025
Fecha de última actualización: 21/10/2025
Cuando se configuran perfiles SSL de cliente o servidor en un servidor virtual, o se utilizan operaciones de firma DNSSEC, el tráfico no revelado puede provocar un aumento en la utilización de recursos de CPU y memoria. Nota: Las versiones de software que han llegado al final del soporte técnico (EoTS) no se evalúan
-
Vulnerabilidad en F5 Networks (CVE-2025-21091)
Severidad: ALTA
Fecha de publicación: 05/02/2025
Fecha de última actualización: 21/10/2025
Cuando SNMP v1 o v2c están deshabilitados en BIG-IP, las solicitudes no reveladas pueden provocar un aumento en la utilización de los recursos de memoria. Nota: Las versiones de software que han llegado al final del soporte técnico (EoTS) no se evalúan
-
Vulnerabilidad en kernel de Linux (CVE-2022-49189)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: clk-rcg2: Actualizar la lógica para calcular el valor D para RCG El reloj de píxeles de la pantalla tiene un requisito en ciertas plataformas más nuevas para admitir M/N como (2/3) y el valor D final calculado da como resultado errores de desbordamiento. Como la implementación actual no verifica que el valor D esté dentro del rango aceptado para un valor M & N dado. Actualice la lógica para calcular el valor D final según el rango.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49192)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: ethernet: cpsw: fix panic when interrumpe coaleceing is seted via ethtool cpsw_ethtool_begin directamente devuelve el resultado de pm_runtime_get_sync cuando es exitoso. pm_runtime_get_sync devuelve el código de error en caso de fallo y 0 en caso de reanudación exitosa, pero también 1 cuando el dispositivo ya está activo. Por lo tanto, el caso común para cpsw_ethtool_begin es devolver 1. Eso lleva a llamadas inconsistentes a pm_runtime_put en la cadena de llamadas, de modo que pm_runtime_put se llama una vez de más y, como resultado, deja suspendido el cpsw dev. El cpsw dev suspendido lleva a una violación de acceso más adelante por diferentes partes del controlador cpsw. Solucione esto llamando a la función pm_runtime_resume_and_get, que es amigable con los retornos.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49193)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: fix 'scheduling while atomic' on aux critical err interrupción Hay un ERROR del kernel en el procesamiento de interrupciones de error crítico auxiliar en ice_misc_intr(): [ 2100.917085] ERROR: scheduling while atomic: swapper/15/0/0x00010000 ... [ 2101.060770] Seguimiento de llamadas: [ 2101.063229] [ 2101.065252] dump_stack+0x41/0x60 [ 2101.068587] __schedule_bug.cold.100+0x4c/0x58 [ 2101.073060] __schedule+0x6a4/0x830 [ [2101.076570] schedule+0x35/0xa0 [2101.079727] schedule_preempt_disabled+0xa/0x10 [2101.084284] __mutex_lock.isra.7+0x310/0x420 [2101.088580] ? ice_misc_intr+0x201/0x2e0 [hielo] [ 2101.093078] ice_send_event_to_aux+0x25/0x70 [hielo] [ 2101.097921] ice_misc_intr+0x220/0x2e0 [hielo] [ 2101.102232] __handle_irq_event_percpu+0x40/0x180 [ 2101.106965] handle_irq_event_percpu+0x30/0x80 [ 2101.111434] handle_irq_event+0x36/0x53 [ 2101.115292] handle_edge_irq+0x82/0x190 [ 2101.119148] handle_irq+0x1c/0x30 [ 2101.122480] do_IRQ+0x49/0xd0 [ 2101.125465] common_interrupt+0xf/0xf [ 2101.129146] ... Como Andrew mencionó correctamente anteriormente[0], ocurre la siguiente escalera de llamadas: ice_misc_intr() <- hardirq ice_send_event_to_aux() device_lock() mutex_lock() might_sleep() might_resched() <- oops Agregue un nuevo bit de estado de PF que indique que ocurrió un error crítico auxiliar y sirvalo en ice_service_task() en el contexto del proceso. El nuevo ice_pf::oicr_err_reg es de lectura y escritura tanto en contextos de hardirq como de proceso, pero solo 3 bits de datos no críticos probablemente no merezcan una sincronización explícita (e incluso están en el mismo byte [31:24]). [0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch
-
Vulnerabilidad en kernel de Linux (CVE-2022-49194)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bcmgenet: Use lecturas/escrituras de registros más fuertes para asegurar el orden GCC12 parece ser mucho más inteligente sobre su seguimiento de dependencias y es consciente de que las variantes relajadas son solo cargas y almacenamientos normales y esto está causando problemas como: [ 210.074549] ------------[ cortar aquí ]------------ [ 210.079223] NETDEV WATCHDOG: enabcm6e4ei0 (bcmgenet): se agotó el tiempo de espera de la cola de transmisión 1 [ 210.086717] ADVERTENCIA: CPU: 1 PID: 0 en net/sched/sch_generic.c:529 dev_watchdog+0x234/0x240 [ 210.095044] Módulos vinculados en: genet(E) nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 CPPC ACPI: el canal de verificación de PCC falló para ss: 0. ret=-110 [ 210.146927] CPU: 1 PID: 0 Comm: swapper/1 Contaminado: GE 5.17.0-rc7G12+ #58 [ 210.153226] CPPC Cpufreq:cppc_scale_freq_workfn: no se pudieron leer los contadores de rendimiento [ 210.161349] Nombre del hardware: Raspberry Pi Foundation Raspberry Pi 4 Model B/Raspberry Pi 4 Model B, BIOS EDK2-DEV 02/08/2022 [ [210.161353] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [210.161358] pc: dev_watchdog+0x234/0x240 [210.161364] lr: dev_watchdog+0x234/0x240 [210.161368] sp: ffff8000080a3a40 [210.161370] x29: ffff8000080a3a40 x28: ffffcd425af87000 x27: ffff8000080a3b20 [210.205150] x26: ffffcd425aa00000 x25: 0000000000000001 x24: ffffcd425af8ec08 [ 210.212321] x23: 0000000000000100 x22: ffffcd425af87000 x21: ffff55b142688000 [ 210.219491] x20: 0000000000000001 x19: ffff55b1426884c8 x18: ffffffffffffffffff [ 210.226661] x17: 64656d6974203120 x16: 0000000000000001 x15: 6d736e617274203a [210.233831] x14: 2974656e65676d63 x13: ffffcd4259c300d8 x12: ffffcd425b07d5f0 [210.241001] x11: 00000000ffffffff x10: ffffcd425b07d5f0 x9: ffffcd4258bdad9c [210.248171] x8: 00000000ffffdfff x7: 000000000000003f x6: 0000000000000000 [210.255341] x5: 0000000000000000 x4 : 0000000000000000 x3 : 00000000000001000 [ 210.262511] x2 : 0000000000001000 x1 : 0000000000000005 x0 : 0000000000000044 [ 210.269682] Rastreo de llamadas: [ 210.272133] dev_watchdog+0x234/0x240 [ 210.275811] call_timer_fn+0x3c/0x15c [ 210.279489] __run_timers.part.0+0x288/0x310 [ 210.283777] run_timer_softirq+0x48/0x80 [ 210.287716] __do_softirq+0x128/0x360 [ 210.291392] __irq_exit_rcu+0x138/0x140 [ 210.295243] irq_exit_rcu+0x1c/0x30 [ 210.298745] el1_interrupt+0x38/0x54 [ 210.302334] el1h_64_irq_handler+0x18/0x24 [ 210.306445] el1h_64_irq+0x7c/0x80 [ 210.309857] arch_cpu_idle+0x18/0x2c [ 210.313445] default_idle_call+0x4c/0x140 [ 210.317470] cpuidle_idle_call+0x14c/0x1a0 [ 210.321584] do_idle+0xb0/0x100 [ 210.324737] cpu_startup_entry+0x30/0x8c [ 210.328675] secondary_start_kernel+0xe4/0x110 [ 210.333138] __secondary_switched+0x94/0x98 La suposición cuando se relajaron estos parece ser que la memoria del dispositivo se asignaría sin reordenamiento, y que otras construcciones (spinlocks/etc) proporcionaría las barreras para asegurar que los datos de los paquetes y los anillos/colas en memoria se ordenaran con respecto a las lecturas/escrituras de los registros del dispositivo. Esto en sí mismo parece un poco impreciso, pero el problema real con GCC12 es que está moviendo las lecturas/escrituras reales a voluntad como si fueran operaciones independientes cuando en realidad no lo son, pero el compilador no puede saberlo. Al observar los volcados de ensamblaje para muchas de estas rutinas, es posible ver operaciones muy limpias, pero no estrictamente en el orden del programa, que ocurren como el compilador podría hacer si no fueran operaciones de lectura/escritura de registros en realidad. Es posible suprimir el tiempo de espera con un poco de dma_mb() esparcidos por ahí, pero el dispositivo todavía parece incapaz de enviar/recibir datos de manera confiable. Un mejor plan es usar el readl/writel más seguro en todas partes. Dado que esto revierte parcialmente una confirmación anterior, que señala el uso de las variantes relajadas por razones de rendimiento. ---truncado---
-
Vulnerabilidad en kernel de Linux (CVE-2022-49199)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/nldev: evitar desbordamientos por debajo de la capacidad en nldev_stat_set_counter_dynamic_doit() Este código comprueba el "índice" en busca de un límite superior, pero no comprueba los valores negativos. Cambie el tipo a unsigned para evitar desbordamientos por debajo de la capacidad.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49204)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Se corrige más mensajes sin cargar mientras msg tiene more_data En tcp_bpf_send_verdict(), si msg tiene más datos después de tcp_bpf_sendmsg_redir(): tcp_bpf_send_verdict() tosend = msg->sg.size //msg->sg.size = 22220 caso __SK_REDIRECT: sk_msg_return() //mensaje sin cargar->sg.size(22220) sk->sk_forward_alloc tcp_bpf_sendmsg_redir() //después de tcp_bpf_sendmsg_redir, msg->sg.size=11000 goto more_data; tosend = msg->sg.size //msg->sg.size = 11000 caso __SK_REDIRECT: sk_msg_return() //msg->sg.size(11000) no cargado a sk->sk_forward_alloc El msg->sg.size(11000) se ha descargado dos veces, para solucionarlo podemos cargar el msg->sg.size restante antes de ir a más datos. Este problema puede generar la siguiente información: ADVERTENCIA: CPU: 0 PID: 9860 en net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Seguimiento de llamadas: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 ? vfs_write+0x237/0x290 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae ADVERTENCIA: CPU: 0 PID: 2136 en net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Rastreo de llamadas: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
-
Vulnerabilidad en kernel de Linux (CVE-2022-49217)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: pm8001: Se ha corregido la interrupción de todas las inicializaciones de tareas. En pm80xx_send_abort_all(), el campo n_elem del ccb utilizado no se inicializa a 0. Esta inicialización faltante a veces provoca que la ruta de finalización de la tarea vea el ccb con un n_elem distinto de cero, lo que da como resultado la ejecución de llamadas dma_unmap_sg() no válidas en pm8001_ccb_task_free(), lo que provoca un bloqueo como el siguiente: [ 197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280 [ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012 [ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0 [ 197.712687] RDX: 00000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0 [ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b [ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000 [ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000 [ 197.741493] FS: 000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000 [ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0 [ 197.762656] Rastreo de llamadas: [ 197.765127] [ 197.767162] pm8001_ccb_task_free+0x5f1/0x820 [pm80xx] [ 197.772364] ? do_raw_spin_unlock+0x54/0x220 [ 197.776680] pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx] [ 197.782406] process_oq+0xe85/0x7890 [pm80xx] [ 197.786817] ? lock_acquire+0x194/0x490 [ 197.790697] ? handle_irq_event+0x10e/0x1b0 [ 197.794920] ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx] [ 197.800378] ? __wake_up_bit+0x100/0x100 [ 197.804340] ? lock_is_held_type+0x98/0x110 [ 197.808565] pm80xx_chip_isr+0x94/0x130 [pm80xx] [ 197.813243] tasklet_action_common.constprop.0+0x24b/0x2f0 [ 197.818785] __do_softirq+0x1b5/0x82d [ 197.822485] ? do_raw_spin_unlock+0x54/0x220 [ 197.826799] __irq_exit_rcu+0x17e/0x1e0 [ 197.830678] irq_exit_rcu+0xa/0x20 [ 197.834114] common_interrupt+0x78/0x90 [ 197.840051] [ 197.844236] [ 197.848397] asm_common_interrupt+0x1e/0x40 Evite este problema inicializando siempre el campo n_elem de ccb en 0 en pm8001_send_abort_all(), pm8001_send_read_log() y pm80xx_send_abort_all().
-
Vulnerabilidad en kernel de Linux (CVE-2022-49220)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dax: asegúrese de que los inodos se vacíen antes de destruir la caché. Se puede activar un error con el siguiente comando $ modprobe nd_pmem && modprobe -r nd_pmem [ 10.060014] ERROR dax_cache (no contaminado): objetos restantes en dax_cache en __kmem_cache_shutdown() [ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node) [ 10.062433] Seguimiento de llamadas: [ 10.062673] dump_stack_lvl+0x34/0x44 [ 10.062865] slab_err+0x90/0xd0 [ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0 [ 10.063848] kmem_cache_destroy+0x4a/0x110 [ 10.064058] __x64_sys_delete_module+0x265/0x300 Esto se debe a que dax_fs_exit() no vacía los inodos antes de destruir la caché. Para solucionar este problema, llame a rcu_barrier() antes de destruir la caché.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49226)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: asix: agregar manejo de errores adecuado para errores de lectura de USB Syzbot una vez más alcanzó un valor uninit en el controlador asix. El problema sigue siendo el mismo: asix_read_cmd() lee menos bytes de los que solicitó el llamador. Dado que todas las solicitudes de lectura se realizan a través de asix_read_cmd(), detectemos el error relacionado con USB allí y agreguemos la notación __must_check para asegurarnos de que todos los llamadores realmente verifiquen el valor de retorno. Entonces, este parche agrega una verificación de cordura dentro de asix_read_cmd(), que simplemente verifica si los bytes leídos no son menores que los solicitados y agrega la gestión de errores faltantes de asix_read_cmd() en todo el código del controlador.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49227)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igc: evitar advertencia del kernel al cambiar los parámetros del anillo RX Llamar a ethtool cambiando los parámetros del anillo RX de esta manera: $ ethtool -G eth0 rx 1024 en igc activa advertencias del kernel como esta: [ 225.198467] ------------[ cortar aquí ]------------ [ 225.198473] Falta anulación del registro, controlador manejado pero corregido [ 225.198485] ADVERTENCIA: CPU: 7 PID: 959 en net/core/xdp.c:168 xdp_rxq_info_reg+0x79/0xd0 [...] [ 225.198601] Seguimiento de llamada: [ 225.198604] [ 225.198609] igc_setup_rx_resources+0x3f/0xe0 [igc] [ 225.198617] igc_ethtool_set_ringparam+0x30e/0x450 [igc] [ 225.198626] ethnl_set_rings+0x18a/0x250 [ 225.198631] genl_family_rcv_msg_doit+0xca/0x110 [ 225.198637] genl_rcv_msg+0xce/0x1c0 [ 225.198640] ? rings_prepare_data+0x60/0x60 [ 225.198644] ? genl_get_cmd+0xd0/0xd0 [ 225.198647] netlink_rcv_skb+0x4e/0xf0 [ 225.198652] genl_rcv+0x24/0x40 [ 225.198655] netlink_unicast+0x20e/0x330 [ 225.198659] netlink_sendmsg+0x23f/0x480 [ 225.198663] sock_sendmsg+0x5b/0x60 [ 225.198667] __sys_sendto+0xf0/0x160 [ 225.198671] ? handle_mm_fault+0xb2/0x280 [ 225.198676] ? do_user_addr_fault+0x1eb/0x690 [ 225.198680] __x64_sys_sendto+0x20/0x30 [ 225.198683] do_syscall_64+0x38/0x90 [ 225.198687] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 225.198693] RIP: 0033:0x7f7ae38ac3aa igc_ethtool_set_ringparam() copia la estructura igc_ring pero no restablece el miembro xdp_rxq_info antes de llamar a igc_setup_rx_resources(). Esto, a su vez, llama a xdp_rxq_info_reg() con un xdp_rxq_info ya registrado. Asegúrese de anular el registro de la estructura xdp_rxq_info primero en igc_setup_rx_resources.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49229)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ptp: anular el registro de los relojes virtuales al anular el registro del reloj físico. Al anular el registro de un reloj físico que tiene algunos relojes virtuales, anule el registro de los relojes virtuales con él. Esto corrige los siguientes errores, que pueden desencadenarse al descargar un controlador que proporciona un reloj PTP cuando ha habilitado los relojes virtuales: ERROR: no se puede manejar el fallo de página para la dirección: ffffffffc04fc4d8 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ptp_vclock_read+0x31/0xb0 Seguimiento de llamadas: timecounter_read+0xf/0x50 ptp_vclock_refresh+0x2c/0x50 ? ptp_clock_release+0x40/0x40 ptp_aux_kworker+0x17/0x30 kthread_worker_fn+0x9b/0x240 ? kthread_should_park+0x30/0x30 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
-
Vulnerabilidad en kernel de Linux (CVE-2022-49243)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: atmel: se agregó la función of_node_put() faltante en at91sam9g20ek_audio_probe. Este puntero de nodo es devuelto por of_parse_phandle() con refcount incrementado en esta función. Se llama a of_node_put() para evitar la fuga de refcount.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49247)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: stk1160: Si falla el inicio de la transmisión, se devuelven los búferes con VB2_BUF_STATE_QUEUED Si falla la devolución de llamada 'start_streaming', todos los búferes en cola en el controlador deben devolverse con el estado 'VB2_BUF_STATE_QUEUED'. Actualmente, se devuelven con 'VB2_BUF_STATE_ERROR', lo cual es incorrecto. Arregle esto. Esto también corrige la advertencia: [ 65.583633] ADVERTENCIA: CPU: 5 PID: 593 en drivers/media/common/videobuf2/videobuf2-core.c:1612 vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.585027] Módulos vinculados en: snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_soc_hdmi_codec dw_hdmi_i2s_audio saa7115 stk1160 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc crct10dif_ce panfrost snd_soc_simple_card snd_soc_audio_graph_card snd_soc_spdif_tx snd_soc_simple_card_utils gpu_sched phy_rockchip_pcie snd_soc_rockchip_i2s rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi cec drm_kms_helper drm rtc_rk808 rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchip_thermal pcie_rockchip_host ip_tables x_tables ipv6 [ 65.589383] CPU: 5 PID: 593 Comm: v4l2src0:src Contaminado: GW 5.16.0-rc4-62408-g32447129cb30-dirty #14 [ 65.590293] Hardware nombre: Radxa ROCK Pi 4B (DT) [ 65.590696] estado de la página: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 65.591304] computadora personal: vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.591850] lr: vb2_start_streaming+0x6c/0x160 [videobuf2_common] [ 65.592395] servidor de correo electrónico: ffff800012bc3ad0 [ 65.592685] x29: ffff800012bc3ad0 x28: 0000000000000000 x27: ffff800012bc3cd8 [ 65.593312] x26: 0000000000000000 x25: ffff00000d8a7800 x24: 0000000040045612 [ 65.593938] x23: ffff800011323000 x22: ffff800012bc3cd8 x21: ffff00000908a8b0 [ 65.594562] x20: ffff00000908a8c8 x19: 00000000ffffff4 x18: ffffffffffffffff [ 65.595188] x17: 000000040044ffff x16: 00400034b5503510 x15: ffff800011323f78 [ 65.595813] x14: ffff000013163886 x13: ffff000013163885 x12: 00000000000002ce [ 65.596439] x11: 0000000000000028 x10: 0000000000000001 x9: 0000000000000228 [65.597064] x8: 0101010101010101 x7: 7f7f7f7f7f7f7f7f x6 : fefefeff726c5e78 [ 65.597690] x5 : ffff800012bc3990 x4 : 0000000000000000 x3 : ffff000009a34880 [ 65.598315] x2 : 000000000000000 x1 : 0000000000000000 x0 : ffff000007cd99f0 [ 65.598940] Rastreo de llamadas: [ 65.599155] vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.599672] vb2_core_streamon+0x17c/0x1a8 [videobuf2_common] [ 65.600179] vb2_streamon+0x54/0x88 [videobuf2_v4l2] [ 65.600619] vb2_ioctl_streamon+0x54/0x60 [videobuf2_v4l2] [ 65.601103] v4l_streamon+0x3c/0x50 [videodev] [ 65.601521] __video_do_ioctl+0x1a4/0x428 [videodev] [ 65.601977] video_usercopy+0x320/0x828 [videodev] [ 65.602419] video_ioctl2+0x3c/0x58 [videodev] [ 65.602830] v4l2_ioctl+0x60/0x90 [videodev] [ 65.603227] __arm64_sys_ioctl+0xa8/0xe0 [ 65.603576] invoke_syscall+0x54/0x118 [ 65.603911] el0_svc_common.constprop.3+0x84/0x100 [ 65.604332] do_el0_svc+0x34/0xa0 [ 65.604625] el0_svc+0x1c/0x50 [ 65.604897] el0t_64_sync_handler+0x88/0xb0 [ 65.605264] el0t_64_sync+0x16c/0x170 [ 65.605587] ---[ fin del seguimiento 578e0ba07742170d ]---
-
Vulnerabilidad en kernel de Linux (CVE-2022-49255)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige el nid libre faltante en f2fs_handle_failed_inode Este parche corrige el error xfstests/generic/475. [ 293.680694] F2FS-fs (dm-1): puede perder un inodo huérfano, ejecute fsck para corregirlo. [ 293.685358] Error de E/S de búfer en dev dm-1, bloque lógico 8388592, lectura de página asíncrona [ 293.691527] Error de E/S de búfer en dev dm-1, bloque lógico 8388592, lectura de página asíncrona [ 293.691764] sh (7615): drop_caches: 3 [ 293.691819] sh (7616): drop_caches: 3 [ 293.694017] Error de E/S de búfer en dev dm-1, bloque lógico 1, lectura de página asíncrona [ 293.695659] sh (7618): drop_caches: 3 [ 293.696979] sh (7617): drop_caches: 3 [ 293.700290] sh (7623): eliminar_cachés: 3 [ 293.708621] sh (7626): eliminar_cachés: 3 [ 293.711386] sh (7628): eliminar_cachés: 3 [ 293.711825] sh (7627): eliminar_cachés: 3 [ 293.716738] sh (7630): eliminar_cachés: 3 [ 293.719613] sh (7632): eliminar_cachés: 3 [ 293.720971] sh (7633): eliminar_cachés: 3 [ 293.727741] sh (7634): eliminar_cachés: 3 [ 293.730783] sh (7636): drop_caches: 3 [ 293.732681] sh (7635): drop_caches: 3 [ 293.732988] sh (7637): drop_caches: 3 [ 293.738836] sh (7639): drop_caches: 3 [ 293.740568] sh (7641): drop_caches: 3 [ 293.743053] sh (7640): drop_caches: 3 [ 293.821889] ------------[ cortar aquí ]------------ [ 293.824654] ¡ERROR del núcleo en fs/f2fs/node.c:3334! [ 293.826226] Código de operación no válido: 0000 [#1] PREEMPT SMP PTI [ 293.828713] CPU: 0 PID: 7653 Comm: umount Contaminado: G OE 5.17.0-rc1-custom #1 [ 293.830946] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 293.832526] RIP: 0010:f2fs_destroy_node_manager+0x33f/0x350 [f2fs] [ 293.833905] Código: e8 d6 3d f9 f9 48 8b 45 d0 65 48 2b 04 25 28 00 00 00 75 1a 48 81 c4 28 03 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b [ 293.837783] RSP: 0018:ffffb04ec31e7a20 EFLAGS: 00010202 [ 293.839062] RAX: 000000000000001 RBX: ffff9df947db2eb8 RCX: 0000000080aa0072 [ 293.840666] RDX: 000000000000000 RSI: ffffe86c0432a140 RDI: ffffffffc0b72a21 [ 293.842261] RBP: ffffb04ec31e7d70 R08: ffff9df94ca85780 R09: 0000000080aa0072 [ 293.843909] R10: ffff9df94ca85700 R11: ffff9df94e1ccf58 R12: ffff9df947db2e00 [ 293.845594] R13: ffff9df947db2ed0 R14: ffff9df947db2eb8 R15: ffff9df947db2eb8 [ 293.847855] FS: 00007f5a97379800(0000) GS:ffff9dfa77c00000(0000) knlGS:00000000000000000 [ 293.850647] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 293.852940] CR2: 00007f5a97528730 CR3: 000000010bc76005 CR4: 0000000000370ef0 [ 293.854680] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 293.856423] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 293.858380] Rastreo de llamadas: [ 293.859302] [ 293.860311] ? ttwu_do_wakeup+0x1c/0x170 [ 293.861800] ? ttwu_do_activate+0x6d/0xb0 [ 293.863057] ? _raw_spin_unlock_irqrestore+0x29/0x40 [ 293.864411] ? try_to_wake_up+0x9d/0x5e0 [ 293.865618] ? debug_smp_processor_id+0x17/0x20 [ 293.866934] ? debug_smp_processor_id+0x17/0x20 [ 293.868223] ? free_unref_page+0xbf/0x120 [ 293.869470] ? __free_slab+0xcb/0x1c0 [ 293.870614] ? preempt_count_add+0x7a/0xc0 [ 293.871811] ? __slab_free+0xa0/0x2d0 [ 293.872918] ? __wake_up_common_lock+0x8a/0xc0 [ 293.874186] ? __slab_free+0xa0/0x2d0 [ 293.875305] ? free_inode_nonrcu+0x20/0x20 [ 293.876466] ? free_inode_nonrcu+0x20/0x20 [ 293.877650] ? debug_smp_processor_id+0x17/0x20 [ 293.878949] ? call_rcu+0x11a/0x240 [ 293.880060] ? f2fs_destroy_stats+0x59/0x60 [f2fs] [ 293.881437] ? kfree+0x1fe/0x230 [ 293.882674] f2fs_put_super+0x160/0x390 [f2fs] [ 293.883978] generic_shutdown_super+0x7a/0x120 [ 293.885274] kill_block_super+0x27/0x50 [ 293.886496] kill_f2fs_super+0x7f/0x100 [f2fs] [ 293.887806] deactivate_locked_super+0x35/0xa0 [ 293.889271] deactivate_super+0x40/0x50 [ 293.890513] cleanup_mnt+0x139/0x190 [ 293.891689] __cleanup_mnt+0x12/0x20 [ 293.892850] task_work_run+0x64/0xa0 [ 293.894035] exit_to_user_mode_prepare+0x1b7 ---truncado---
-
Vulnerabilidad en kernel de Linux (CVE-2022-49259)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloquo: no eliminar la cola kobject antes de que sus kobjects hijos no se eliminen antes de que se eliminen sus kobjects hijos. Aparentemente, esto suele ser benigno; Sin embargo, se activará una ADVERTENCIA si uno de los kobjects secundarios tiene un grupo de atributos con nombre: sysfs group 'modes' not found for kobject 'crypto' ADVERTENCIA: CPU: 0 PID: 1 en fs/sysfs/group.c:278 sysfs_remove_group+0x72/0x80 ... Seguimiento de llamadas: sysfs_remove_groups+0x29/0x40 fs/sysfs/group.c:312 __kobject_del+0x20/0x80 lib/kobject.c:611 kobject_cleanup+0xa4/0x140 lib/kobject.c:696 kobject_release lib/kobject.c:736 [en línea] kref_put include/linux/kref.h:65 [en línea] kobject_put+0x53/0x70 lib/kobject.c:753 blk_crypto_sysfs_unregister+0x10/0x20 block/blk-crypto-sysfs.c:159 blk_unregister_queue+0xb0/0x110 block/blk-sysfs.c:962 del_gendisk+0x117/0x250 block/genhd.c:610 Solucione esto moviendo kobject_del() y el kobject_uevent() correspondiente al lugar correcto.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49260)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: hisilicon/sec - corrige el error de respaldo del software aead para el motor. Debido al mal uso del puntero subreq de la memoria de contexto privada, el cifrado suave aead a veces provoca un pánico del sistema operativo al configurar la página de 64K. Aquí se soluciona.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49264)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exec: Forzar una sola cadena vacía cuando argv está vacío Citando[1] a Ariadne Conill: "En varios otros sistemas operativos, es un requisito estricto que el segundo argumento de execve(2) sea el nombre de un programa, lo que prohíbe un escenario donde argc < 1. POSIX 2017 también recomienda este comportamiento, pero no es un requisito explícito[2]: el argumento arg0 debe apuntar a una cadena de nombre de archivo que esté asociada con el proceso que inicia una de las funciones exec. ... Curiosamente, Michael Kerrisk abrió un problema sobre esto en 2008[3], pero no hubo consenso para apoyar la solución de este problema en ese momento. Con suerte, ahora que CVE-2021-4034 muestra un uso explotador práctico[4] de este error en un shellcode, podemos reconsiderarlo. Este problema se está rastreando en el rastreador de problemas de KSPP[5]". Si bien las búsquedas de código iniciales[6][7] dieron como resultado lo que parecían ser principalmente pruebas de casos extremos, intentar simplemente rechazar argv == NULL (o una lista de punteros terminada inmediatamente) rápidamente comenzó a hacer tropezar[8] a los programas de espacio de usuario existentes. El siguiente mejor enfoque es forzar una sola cadena vacía en argv y ajustar argc para que coincida. La cantidad de programas que dependen de argc == 0 parece un conjunto más pequeño que los que llaman a execve con un argv NULL. Tenga en cuenta el espacio de pila adicional en bprm_stack_limits(). Inyecte una cadena vacía cuando argc == 0 (y establezca argc = 1). Advertir sobre el caso para que el espacio de usuario tenga algún aviso sobre el cambio: proceso './argc0' lanzado './argc0' con argv NULL: cadena vacía agregada Además, WARN() y rechace el uso de argv NULL para subprocesos del kernel. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/ [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0 [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0 [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/
-
Vulnerabilidad en kernel de Linux (CVE-2022-49265)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: dominios: Se corrige el error sleep-in-atomic causado por genpd_debug_remove() Cuando se elimina un genpd con GENPD_FLAG_IRQ_SAFE, se verá el siguiente error sleep-in-atomic, ya que se llamará a genpd_debug_remove() con un spinlock retenido. [ 0.029183] ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/rwsem.c:1460 [ 0.029204] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0 [ 0.029219] preempt_count: 1, expected: 0 [ 0.029230] CPU: 1 PID: 1 Comm: swapper/0 No contaminado 5.17.0-rc4+ #489 [ 0.029245] Nombre del hardware: Thundercomm TurboX CM2290 (DT) [ 0.029256] Rastreo de llamadas: [ 0.029265] dump_backtrace.part.0+0xbc/0xd0 [ 0.029285] show_stack+0x3c/0xa0 [ 0.029298] dump_stack_lvl+0x7c/0xa0 [ 0.029311] dump_stack+0x18/0x34 [ 0.029323] __might_resched+0x10c/0x13c [ 0.029338] __might_sleep+0x4c/0x80 [ 0.029351] down_read+0x24/0xd0 [ 0.029363] lookup_one_len_unlocked+0x9c/0xcc [ 0.029379] lookup_positive_unlocked+0x10/0x50 [ 0.029392] debugfs_lookup+0x68/0xac [ 0.029406] genpd_remove.part.0+0x12c/0x1b4 [ 0.029419] of_genpd_remove_last+0xa8/0xd4 [ 0.029434] psci_cpuidle_domain_probe+0x174/0x53c [ 0.029449] platform_probe+0x68/0xe0 [ 0.029462] really_probe+0x190/0x430 [ 0.029473] __driver_probe_device+0x90/0x18c [ 0.029485] driver_probe_device+0x40/0xe0 [ 0.029497] __driver_attach+0xf4/0x1d0 [ 0.029508] bus_for_each_dev+0x70/0xd0 [ 0.029523] driver_attach+0x24/0x30 [ 0.029534] bus_add_driver+0x164/0x22c [ 0.029545] driver_register+0x78/0x130 [ 0.029556] __platform_driver_register+0x28/0x34 [ 0.029569] psci_idle_init_domains+0x1c/0x28 [ 0.029583] do_one_initcall+0x50/0x1b0 [ 0.029595] kernel_init_freeable+0x214/0x280 [ 0.029609] kernel_init+0x2c/0x13c [ 0.029622] ret_from_fork+0x10/0x200 No parece necesario llamar a genpd_debug_remove() con el bloqueo, así que sáquelo del bloqueo para solucionar el problema.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49266)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: fix rq-qos breakage from skipping rq_qos_done_bio() a647a524a467 ("block: don't call rq_qos_ops->done_bio if the bio isn't tracked") hizo que bio_endio() saltara rq_qos_done_bio() si BIO_TRACKED no está configurado. Si bien esto solucionó un posible error, también rompió blk-iocost al saltarse la devolución de llamada done_bio para bios fusionados. Antes, ya sea que una bio pase por rq_qos_throttle() o rq_qos_merge(), rq_qos_done_bio() se llamaría en la bio al completarse con BIO_TRACKED distinguiendo la primera de la segunda. rq_qos_done_bio() no se llama para bios que pasaron por rq_qos_merge(). Esto confunde mucho a blk-iocost, ya que las bios fusionadas nunca terminan y se consideran en constante funcionamiento. Un modo de falla reproducible de manera confiable es un cgroup intermedio que se queda bloqueado en modo activo, lo que impide que sus hijos se activen debido a la regla de solo hojas, lo que lleva a la pérdida de control. Lo siguiente es del escenario de protección de resctl-bench que emula el aislamiento de una carga de trabajo similar a la de un servidor web de una bomba de memoria ejecutada en una configuración de iocost que debería producir un nivel razonable de protección. # cat /sys/block/nvme2n1/device/model Samsung SSD 970 PRO 512GB # cat /sys/fs/cgroup/io.cost.model 259:0 ctrl=usuario model=linear rbps=834913556 rseqiops=93622 rrandiops=102913 wbps=618985353 wseqiops=72325 wrandiops=71025 # cat /sys/fs/cgroup/io.cost.qos 259:0 enable=1 ctrl=usuario rpct=95.00 rlat=18776 wpct=95.00 wlat=8897 mín=60.00 máx=100.00 # resctl-bench -m 29.6G -r out.json ejecutar protection::scenario=mem-hog,loops=1 ... Resumen de acaparadores de memoria ================== Latencia de E/S: R p50=242u:336u/2,5 m p90=794u:1,4 m/7,5 m p99=2,7 m:8,0 m/62,5 m máx.=8,0 m:36,4 m/350 m W p50=221u:323u/1,5 m p90=709u:1,2 m/5,5 m p99=1,5 m:2,5 m/9,5 m máx.=6,9 m:35,9 m/350 m Distribuciones del impacto de latencia de solicitud y aislamiento: mín. p01 p05 p10 p25 p50 p75 p90 p95 p99 máx. media desviación estándar isol% 15,90 15,90 15,90 40,05 57,24 59,07 60,01 74,63 74,63 90,35 90,35 58,12 15,82 lat-imp% 0 0 0 0 0 4,55 14,68 15,54 233,5 548,1 548,1 53,88 143,6 Resultado: isol=58,12:15,82% lat_imp=53,88%:143,6 work_csv=100,0% missing=3,96% El resultado de aislamiento de 58,12% es cercano a lo que este dispositivo mostraría sin ningún control de E/S. Arréglelo introduciendo una nueva bandera BIO_QOS_MERGED para marcar las bios fusionadas y llamando a rq_qos_done_bio() en ellas también. Para mayor coherencia y claridad, cambie el nombre de BIO_TRACKED a BIO_QOS_THROTTLED. Las comprobaciones de banderas se mueven a rq_qos_done_bio() para que estén junto a las rutas de código que establecen las banderas. Con el parche aplicado, el mismo punto de referencia anterior muestra: # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1 ... Resumen de acaparamiento de memoria ================== Latencia de E/S: R p50=123u:84.4u/985u p90=322u:256u/2.5m p99=1.6m:1.4m/9.5m máx.=11.1m:36.0m/350m W p50=429u:274u/995u p90=1.7m:1.3m/4.5m p99=3.4m:2.7m/11.5m máx.=7.9m:5.9m/26.5m Distribuciones de impacto de latencia de solicitud y aislamiento: min p01 p05 p10 p25 p50 p75 p90 p95 p99 media máxima desviación estándar isol% 84,91 84,91 89,51 90,73 92,31 94,49 96,36 98,04 98,71 100,0 100,0 94,42 2,81 lat-imp% 0 0 0 0 0 2,81 5,73 11,11 13,92 17,53 22,61 4,10 4,68 Resultado: isol=94,42:2,81% lat_imp=4,10%:4,68 work_csv=58,34% missing=0%
-
Vulnerabilidad en kernel de Linux (CVE-2022-49267)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: core: use sysfs_emit() en lugar de sprintf() sprintf() (que todavía se usa en el núcleo de MMC para la salida de sysfs) es vulnerable al desbordamiento del búfer. Use el nuevo sysfs_emit() en su lugar. Encontrado por Linux Verification Center (linuxtesting.org) con la herramienta de análisis estático SVACE.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49269)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: isotp: sanitize CAN ID checks in isotp_bind() Syzbot creó un entorno que condujo a un estado de máquina de estados al que no se puede acceder con una configuración de dirección CAN ID compatible. La información de dirección proporcionada consistía en CAN ID 0x6000001 y 0xC28001, que se reducen a 11 bits CAN ID 0x001 en envío y recepción. Sanitize los valores SFF/EFF CAN ID antes de realizar las comprobaciones de dirección.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49281)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: fix handlecache y multiuser En multiuser, cada usuario individual tiene su propia estructura tcon para el recurso compartido y, por lo tanto, su propio identificador para un directorio en caché. Cuando desmontamos un recurso compartido de este tipo, debemos asegurarnos de liberar la entrada dentry fijada para cada uno de esos tcon y no solo el tcon maestro. De lo contrario, recibiremos advertencias desagradables al desmontar que indican que las dentry aún están en uso: [ 3459.590047] ERROR: Dentry 00000000115c6f41{i=12000000019d95,n=/} aún en uso\ (2) [desmontaje de cifs cifs] ... [ 3459.590492] Seguimiento de llamadas: [ 3459.590500] d_walk+0x61/0x2a0 [ 3459.590518] ? shrink_lock_dentry.part.0+0xe0/0xe0 [ 3459.590526] shrink_dcache_for_umount+0x49/0x110 [ 3459.590535] generic_shutdown_super+0x1a/0x110 [ 3459.590542] kill_anon_super+0x14/0x30 [ 3459.590549] cifs_kill_sb+0xf5/0x104 [cifs] [ 3459.590773] deactivate_locked_super+0x36/0xa0 [ 3459.590782] cleanup_mnt+0x131/0x190 [ 3459.590789] task_work_run+0x5c/0x90 [ 3459.590798] exit_to_user_mode_loop+0x151/0x160 [ 3459.590809] exit_to_user_mode_prepare+0x83/0xd0 [ 3459.590818] syscall_exit_to_user_mode+0x12/0x30 [ 3459.590828] do_syscall_64+0x48/0x90 [ 3459.590833] entry_SYSCALL_64_after_hwframe+0x44/0xae
-
Vulnerabilidad en kernel de Linux (CVE-2022-49293)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: inicializar registros en nft_do_chain() Inicializar registros para evitar fugas de pila en el espacio de usuario.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49297)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nbd: se corrige el bloqueo de E/S al desconectar el dispositivo En nuestras pruebas, "qemu-nbd" activa un bloqueo de E/S: INFORMACIÓN: la tarea qemu-nbd:11445 estuvo bloqueada durante más de 368 segundos. No contaminada 5.18.0-rc3-next-20220422-00003-g2176915513ca #884 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. tarea:qemu-nbd estado:D pila: 0 pid:11445 ppid: 1 indicadores:0x00000000 Seguimiento de llamadas: __schedule+0x480/0x1050 ? _raw_spin_lock_irqsave+0x3e/0xb0 schedule+0x9c/0x1b0 blk_mq_freeze_queue_wait+0x9d/0xf0 ? ipi_rseq+0x70/0x70 blk_mq_freeze_queue+0x2b/0x40 nbd_add_socket+0x6b/0x270 [nbd] nbd_ioctl+0x383/0x510 [nbd] blkdev_ioctl+0x18e/0x3e0 __x64_sys_ioctl+0xac/0x120 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fd8ff706577 RSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577 RDX: 000000000000000d RSI: 000000000000ab00 RDI: 00000000000000f RBP: 00000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0 R10: 00000002aff20000 R11: 0000000000000246 R12: 0000000000000006d R13: 00000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0 "qemu-ndb -d" llamará primero a ioctl 'NBD_DISCONNECT', sin embargo, se encontró el siguiente mensaje: block nbd0: Send desconect failed -32 Lo que indica que algo anda mal con el servidor. Luego, "qemu-nbd -d" llamará a ioctl 'NBD_CLEAR_SOCK', sin embargo, ioctl no puede borrar las solicitudes después de el commit 2516ab1543fd("nbd: solo limpia la cola al desmantelar el dispositivo"). Mientras tanto, la solicitud no se puede completar después del tiempo de espera porque nbd_xmit_timeout() siempre devolverá 'BLK_EH_RESET_TIMER', lo que significa que dicha solicitud nunca se completará en esta situación. Ahora que el indicador 'NBD_CMD_INFLIGHT' puede garantizar que las solicitudes no se completen varias veces, vuelva a llamar a nbd_clear_sock() en nbd_clear_sock_ioctl(), de modo que las solicitudes en curso se puedan borrar.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49306)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: host: Detener la configuración del compañero ACPI Ya no es necesario. El puntero sysdev ahora se utiliza al asignar los compañeros ACPI a los puertos xHCI y dispositivos USB. Asignar el compañero ACPI aquí resultó en que el puntero fwnode->secondary también se reemplazara para el dispositivo dwc3 principal ya que el fwnode primario (el compañero ACPI) se compartía. Eso no fue intencional y creó posibles efectos secundarios como fugas de recursos.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49308)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: extcon: Modificar el dispositivo extcon para que se cree después de que se configuren los datos del controlador. Actualmente, alguien puede invocar el sysfs como state_show() de forma intermitente antes de que se realice dev_set_drvdata(). Y puede ser una causa de errores del kernel debido a que edev es Null en ese momento. Por lo tanto, se modificó el registro del controlador después de configurar los datos del controlador. - Ups, el backtrace. Rastreo inverso: [] (mostrar estado) desde [] (mostrar atributo de desarrollo) [] (mostrar atributo de desarrollo) desde [] (mostrar secuencia de sysfs_kf_seq) [] (mostrar secuencia de sysfs_kf_seq) desde [] (mostrar secuencia de kernfs) [] (mostrar secuencia de kernfs) desde [] (leer secuencia) [] (leer secuencia) desde [] (leer secuencia de kernfs_fop) [] (kernfs_fop_read) desde [] (__vfs_read) [] (__vfs_read) desde [] (vfs_read) [] (vfs_read) desde [] (ksys_read) [] (ksys_read) desde [] (sys_read) [] (sys_read) desde [] (__sys_trace_return)
-
Vulnerabilidad en kernel de Linux (CVE-2022-49333)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: E-Switch, emparejar solo dispositivos compatibles con OFFLOADS El emparejamiento con devcom solo es posible en dispositivos que admiten LAG. Filtrar en función de las capacidades de retraso. Esto soluciona un problema en el que se llamaba a mlx5_get_next_phys_dev() sin mantener el bloqueo de la interfaz. Este problema se encontró cuando el commit bc4c2f2e0179 ("net/mlx5: Lag, filtrar dispositivos no compatibles") agregó una afirmación que verifica que se mantenga el bloqueo de la interfaz. ADVERTENCIA: CPU: 9 PID: 1706 en drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core] Módulos vinculados en: mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm ib_uverbs ib_core overlay fuse [última descarga: mlx5_core] CPU: 9 PID: 1706 Comm: devlink No contaminado 5.18.0-rc7+ #11 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 RIP: 0010:mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core] Código: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ff RSP: 0018:ffff88811bf47458 EFLAGS: 00010246 RAX: 000000000000000 RBX: ffff88811b398000 RCX: 000000000000001 RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78 RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437 R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000 R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428 FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: mlx5_esw_offloads_devcom_event+0x99/0x3b0 [mlx5_core] mlx5_devcom_send_event+0x167/0x1d0 mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core] mlx5_devcom_send_event+0x167/0x1d0 [mlx5_core] esw_offloads_enable+0x1153/0x1500 [mlx5_core] ? mlx5_esw_offloads_controller_valid+0x170/0x170 [mlx5_core] ? wait_for_completion_io_timeout+0x20/0x20 ? mlx5_rescan_drivers_locked+0x318/0x810 [mlx5_core] mlx5_eswitch_enable_locked+0x586/0xc50 [mlx5_core] ? mlx5_eswitch_disable_pf_vf_vports+0x1d0/0x1d0 [mlx5_core] ? mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core] ? mlx5_eswitch_enable+0x270/0x270 [mlx5_core] ? __debugfs_create_file+0x260/0x3e0 mlx5_devlink_eswitch_mode_set+0x27e/0x870 [mlx5_core] ? mutex_lock_io_nested+0x12c0/0x12c0 ? esw_offloads_disable+0x250/0x250 [mlx5_core] ? devlink_nl_cmd_trap_get_dumpit+0x470/0x470 ? rcu_read_lock_sched_held+0x3f/0x70 devlink_nl_cmd_eswitch_set_doit+0x217/0x620
-
Vulnerabilidad en kernel de Linux (CVE-2022-49336)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/etnaviv: comprobar mapeo cosechado en etnaviv_iommu_unmap_gem Cuando el mapeo ya fue cosechado, anular el mapeo debe ser una operación nula, ya que de lo contrario intentaríamos eliminar el mapeo dos veces, corrompiendo las estructuras de datos involucradas.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49338)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: CT: Se corrige la limpieza de CT antes de la limpieza de las reglas ct de TC La limpieza de CT supone que todas las reglas tc se eliminaron primero y, por lo tanto, es libre de eliminar los recursos compartidos de CT (por ejemplo, dr_action fwd_action que se comparte para todas las tuplas). Pero actualmente para el enlace ascendente, esto sucede a la inversa, lo que provoca el siguiente rastro. La limpieza de CT se llama desde: mlx5e_cleanup_rep_tx()->mlx5e_cleanup_uplink_rep_tx()-> mlx5e_rep_tc_cleanup()->mlx5e_tc_esw_cleanup()-> mlx5_tc_ct_clean() Solo después, se llama a la limpieza de tc desde: mlx5e_cleanup_rep_tx()->mlx5e_tc_ht_cleanup() que habría eliminado todas las reglas de tc ct y, por lo tanto, eliminaría todas las tuplas descargadas. Corrija esto invirtiendo el orden de init y on cleanup, lo que dará como resultado tc cleanup y luego ct cleanup. [ 9443.593347] ADVERTENCIA: CPU: 2 PID: 206774 en drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1882 mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core] [ 9443.593349] Módulos vinculados en: act_ct nf_flow_table rdma_ucm(O) rdma_cm(O) iw_cm(O) ib_ipoib(O) ib_cm(O) ib_umad(O) mlx5_core(O-) mlxfw(O) mlxdevm(O) auxiliar(O) ib_uverbs(O) psample ib_core(O) mlx_compat(O) ip_gre gre ip_tunnel act_vlan enlace geneve esp6_offload esp6 esp4_offload esp4 act_tunnel_key vxlan ip6_udp_tunnel udp_tunnel act_mirred act_skbedit act_gact cls_flower sch_ingress nfnetlink_cttimeout nfnetlink xfrm_user xfrm_algo 8021q garp stp ipmi_devintf mrp ipmi_msghandler llc openvswitch nsh nf_conncount nf_nat mst_pciconf(O) dm_multipath sbsa_gwdt uio_pdrv_genirq uio mlxbf_pmc mlxbf_pka mlx_trio mlx_bootctl(O) bluefield_edac sch_fq_codel tablas ip ipv6 crc_ccitt btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq raid1 raid0 crct10dif_ce i2c_mlxbf gpio_mlxbf2 mlxbf_gige aes_neon_bs aes_neon_blk [última descarga: mlx5_ib] [ 9443.593419] CPU: 2 PID: 206774 Comm: modprobe Contaminado: GO 5.4.0-1023.24.gc14613d-bluefield #1 [ 9443.593422] Nombre del hardware: https://www.mellanox.com SoC BlueField/SoC BlueField, BIOS BlueField:143ebaf 11 de enero de 2022 [ 9443.593424] estado de la página: 20000005 (nzCv daif -PAN -UAO) [ 9443.593489] computadora personal: mlx5dr_action_destroy+0x188/0x1a0 [núcleo mlx5] [ 9443.593545] estado de la línea: mlx5_ct_fs_smfs_destroy+0x24/0x30 [núcleo mlx5] [ 9443.593546] servidor de correo: ffff8000135dbab0 [ 9443.593548] x29: ffff8000135dbab0 x28: ffff0003a6ab8e80 [ 9443.593550] x27: 0000000000000000 x26: ffff0003e07d7000 [ 9443.593552] x25: ffff800009609de0 x24: ffff000397fb2120 [ 9443.593554] x23: ffff0003975c0000 x22: 0000000000000000 [ 9443.593556] x21: ffff0003975f08c0 x20: ffff800009609de0 [ 9443.593558] x19: ffff0003c8a13380 x18: 0000000000000014 [ 9443.593560] x17: 0000000067f5f125 x16: 000000006529c620 [ 9443.593561] x15: 000000000000000b x14: 0000000000000000 [ 9443.593563] x13: 0000000000000002 x12: 0000000000000001 [ 9443.593565] x11: ffff800011108868 x10: 0000000000000000 [ 9443.593567] x9 : 0000000000000000 x8 : ffff8000117fb270 [ 9443.593569] x7 : ffff0003ebc01288 x6 : 0000000000000000 [ 9443.593571] x5 : ffff800009591ab8 x4 : fffffe000f6d9a20 [ 9443.593572] x3 : 0000000080040001 x2 : fffffe000f6d9a20 [ 9443.593574] x1 : ffff8000095901d8 x0 : 0000000000000025 [ 9443.593577] Rastreo de llamadas: [ 9443.593634] mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core] [ 9443.593688] mlx5_ct_fs_smfs_destroy+0x24/0x30 [mlx5_core] [ 9443.593743] mlx5_tc_ct_clean+0x34/0xa8 [mlx5_core] [ 9443.593797] mlx5e_tc_esw_cleanup+0x58/0x88 [mlx5_core] [ 9443.593851] mlx5e_rep_tc_cleanup+0x24/0x30 [mlx5_core] [ 9443.593905] mlx5e_cleanup_rep_tx+0x6c/0x78 [mlx5_core] [ 9443.593959] mlx5e_detach_netdev+0x74/0x98 [mlx5_core] [ 9443.594013] mlx5e_netdev_change_profile+0x70/0x180 [mlx5_core] [ 9443.594067] mlx5e_netdev_attach_nic_profile+0x34/0x40 [mlx5_core] [ 9443.594122] mlx5e_vport_rep_unload+0x15c/0x1a8 [mlx5_co ---truncado---
-
Vulnerabilidad en kernel de Linux (CVE-2022-49340)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ip_gre: prueba csum_start en lugar del encabezado de transporte GRE con TUNNEL_CSUM aplicará la descarga de suma de comprobación local en los paquetes CHECKSUM_PARTIAL. ipgre_xmit debe validar csum_start después de un skb_pull opcional, de lo contrario lco_csum puede provocar un desbordamiento. La comprobación original era if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL; Esto tenía falsos positivos cuando skb_checksum_start no está definido: cuando ip_summed no es CHECKSUM_PARTIAL. Una mejora discutida fue sencilla if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL; Pero finalmente se revisó más a fondo: - restringir la verificación a la única rama donde sea necesario, en una ruta GRE poco común que usa header_ops y llama a skb_pull. - probar skb_transport_header, que se establece junto con csum_start en skb_partial_csum_set en la ruta de datos header_ops normal. Resulta que skbs puede llegar a esta rama sin el encabezado de transporte establecido, por ejemplo, a través de la redirección BPF. Revise la verificación nuevamente para verificar csum_start directamente, y solo si CHECKSUM_PARTIAL. Deje la verificación en la ubicación actualizada. Verifique el campo independientemente de si TUNNEL_CSUM está configurado.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49341)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, arm64: Borrar prog->jited_len junto con prog->jited syzbot informó un intento ilegal de copy_to_user() desde bpf_prog_get_info_by_fd() [1] Todavía no hubo reproducción de este error, pero creo que el commit 0aef499f3172 ("mm/usercopy: Detectar desbordamientos de vmalloc") está exponiendo un error anterior en bpf arm64. bpf_prog_get_info_by_fd() analiza prog->jited_len para determinar si la imagen JIT se puede copiar al espacio de usuario. Mi teoría es que syzbot logró obtener un programa donde prog->jited_len se ha establecido en 43, mientras que prog->bpf_func se ha borrado. No está claro por qué copy_to_user(uinsns, NULL, ulen) está activando esta advertencia en particular. Pensé que find_vma_area(NULL) no encontraría un vm_struct. Como no tenemos el bloqueo de giro vmap_area_lock, es posible que el vm_struct encontrado fuera basura. [1] usercopy: ¡Se detectó un intento de exposición de memoria del kernel desde vmalloc (desplazamiento 792633534417210172, tamaño 43)! ¡ERROR del kernel en mm/usercopy.c:101! Error interno: Oops - BUG: 0 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 25002 Comm: syz-executor.1 No contaminado 5.18.0-syzkaller-10139-g8291eaafed36 #0 Nombre del hardware: linux,dummy-virt (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101 lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89 sp : ffff80000b773a20 x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48 x26: 0000000000000000 x25: 000000000000002b x24: 00000000000000000 x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001 x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420 x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031 x11: 3237313434333533 x10: 3336323937207465 x9: 657275736f707865 x8: ffff80000a30c550 x7: ffff80000b773830 x6: ffff80000b773830 x5: 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000 x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 00000000000000064 Rastreo de llamadas: usercopy_abort+0x90/0x94 mm/usercopy.c:89 check_heap_object mm/usercopy.c:186 [en línea] __check_object_size mm/usercopy.c:252 [en línea] __check_object_size+0x198/0x36c mm/usercopy.c:214 check_object_size include/linux/thread_info.h:199 [en línea] check_copy_size include/linux/thread_info.h:235 [en línea] copia_al_usuario include/linux/uaccess.h:159 [en línea] bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993 bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253 __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956 __do_sys_bpf kernel/bpf/syscall.c:5021 [en línea] __se_sys_bpf kernel/bpf/syscall.c:5019 [en línea] __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019 __invoke_syscall arch/arm64/kernel/syscall.c:38 [en línea] invocar_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142 do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206 el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624 el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581 Código: aa0003e3 d00038c0 91248000 97fff65f (d4210000)
-
Vulnerabilidad en kernel de Linux (CVE-2022-49343)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: evitar ciclos en el directorio h-tree Un sistema de archivos dañado maliciosamente puede contener ciclos en el h-tree almacenados dentro de un directorio. Eso puede hacer que el kernel corrompa fácilmente los nodos del árbol que ya se habían verificado bajo su control mientras realizaba una división de nodos y, en consecuencia, accediera a memoria no asignada. Solucione el problema verificando que los números de bloque recorridos sean únicos.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49348)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: filtrar EXT4_FC_REPLAY del campo s_state del superbloque en disco El bit EXT4_FC_REPLAY en sbi->s_mount_state se usa para indicar que estamos en medio de la reproducción del diario de confirmación rápida. En realidad, esto fue un error, ya que sbi->s_mount_info se inicializa desde es->s_state. Podría decirse que s_mount_state tiene un nombre engañoso, pero el nombre es histórico --- s_mount_state y s_state se remontan a ext2. Lo que se debería haber usado son las funciones en línea ext4_{set,clear,test}_mount_flag(), que establecen los bits EXT4_MF_* en sbi->s_mount_flags. El problema con el uso de EXT4_FC_REPLAY es que un superbloque dañado maliciosamente podría provocar que EXT4_FC_REPLAY se establezca en s_mount_state. Esto evita algunas comprobaciones de cordura y puede desencadenar un error en ext4_es_cache_extent(). Como solución fácil de implementar, filtre el bit EXT4_FC_REPLAY por ahora. Deberíamos dejar de usar EXT4_FC_REPLAY para pasar a algo como EXT4_MF_REPLAY.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49352)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: advertencia de corrección en ext4_handle_inode_extension Tenemos el siguiente problema: Error EXT4-fs (device loop0) en ext4_reserve_inode_write:5741: Sin memoria Error EXT4-fs (device loop0): ext4_setattr:5462: inodo n.º 13: comm syz-executor.0: error mark_inode_dirty Error EXT4-fs (device loop0) en ext4_setattr:5519: Sin memoria Error EXT4-fs (device loop0): ext4_ind_map_blocks:595: inodo n.º 13: comm syz-executor.0: No se pueden asignar bloques para inodos no asignados a extensión con bigalloc ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 1 PID: 4361 en fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220 Módulos vinculados: CPU: 1 PID: 4361 Comm: syz-executor.0 No contaminado 5.10.0+ #1 RIP: 0010:ext4_file_write_iter+0x11c9/0x1220 RSP: 0018:ffff924d80b27c00 EFLAGS: 00010282 RAX: ffffffff815a3379 RBX: 000000000000000 RCX: 000000003b000000 RDX: ffff924d81601000 RSI: 000000000000009cc RDI: 00000000000009cd RBP: 000000000000000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12: 00000000000000a R13: 000000000000001 R14: ffff902e0e52aa10 R15: ffffffffffffff8b FS: 00007f81a7f65700(0000) GS:ffff902e3bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffff600400 CR3: 000000012db88001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: do_iter_readv_writev+0x2e5/0x360 do_iter_write+0x112/0x4c0 do_pwritev+0x1e5/0x390 __x64_sys_pwritev2+0x7e/0xa0 do_syscall_64+0x37/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xa9 El problema anterior puede ocurrir de la siguiente manera: Suponga que inode.i_size=4096 EXT4_I(inodo)->i_disksize=4096 paso 1: establezca inode->i_isize = 8192 ext4_setattr if (attr->ia_size != inode->i_size) EXT4_I(inodo)->i_disksize = attr->ia_size; rc = ext4_mark_inode_dirty ext4_reserve_inode_write ext4_get_inode_loc __ext4_get_inode_loc sb_getblk devolver -->ENOMEM ... si (!error) ->no se actualizará i_size i_size_write(inodo, attr->ia_size); Ahora: inode.i_size=4096 EXT4_I(inode)->i_disksize=8192 paso 2: Escritura directa de 4096 bytes ext4_file_write_iter ext4_dio_write_iter iomap_dio_rw ->devuelve error if (extend) ext4_handle_inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize); ->Entonces activa la advertencia. Para resolver el problema anterior, si la marca de inodo sucio falló en ext4_setattr simplemente configure 'EXT4_I(inode)->i_disksize' con el valor anterior.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49356)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: Trampa desbordamientos de segmentos RDMA Impide que svc_rdma_build_writes() se aleje del final de la matriz de segmentos de un fragmento de escritura. Detectado con KASAN. La prueba que esta corrección reemplaza no es válida y podría haber quedado de un prototipo anterior del trabajo de PCL.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49357)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: efi: No importar certificados desde UEFI Secure Boot para Mac T2 En Mac T2 de Apple, cuando Linux intenta leer las variables efi db y dbx en el arranque temprano para cargar certificados UEFI Secure Boot, se produce un error de página en el código de firmware de Apple y los servicios de tiempo de ejecución de EFI se desactivan con los siguientes registros: [Error de firmware]: Error de página causado por el firmware en PA: 0xffffb1edc0068000 ADVERTENCIA: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) Call Trace: page_fault_oops+0x4f/0x2c0 ? search_bpf_extables+0x6b/0x80 ? search_module_extables+0x50/0x80 ? search_exception_tables+0x5b/0x60 kernelmode_fixup_or_oops+0x9e/0x110 __bad_area_nosemaphore+0x155/0x190 bad_area_nosemaphore+0x16/0x20 do_kern_addr_fault+0x8c/0xa0 exc_page_fault+0xd8/0x180 asm_exc_page_fault+0x1e/0x30 (Removed some logs from here) ? __efi_call+0x28/0x30 ? switch_mm+0x20/0x30 ? efi_call_rts+0x19a/0x8e0 ? process_one_work+0x222/0x3f0 ? worker_thread+0x4a/0x3d0 ? kthread+0x17a/0x1a0 ? process_one_work+0x3f0/0x3f0 ? set_kthread_struct+0x40/0x40 ? ret_from_fork+0x22/0x30 ---[ end trace 1f82023595a5927f ]--- efi: Froze efi_rts_wq and disabled EFI Runtime Services integrity: Couldn't get size: 0x8000000000000015 integrity: MODSIGN: Couldn't get UEFI db list efi: EFI Runtime Services are disabled! integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get UEFI dbx list integrity: Couldn't get size: 0x8000000000000015 integrity: Couldn't get mokx list integrity: Couldn't get size: 0x80000000 De esta forma evitamos leer estas variables UEFI y, por lo tanto, evitamos el bloqueo.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49360)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en total_data_blocks Como informó Yanming en Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215916 El mensaje del kernel se muestra a continuación: ¡ERROR del kernel en fs/f2fs/segment.c:2560! Call Trace: allocate_segment_by_default+0x228/0x440 f2fs_allocate_data_block+0x13d1/0x31f0 do_write_page+0x18d/0x710 f2fs_outplace_write_data+0x151/0x250 f2fs_do_write_data_page+0xef9/0x1980 move_data_page+0x6af/0xbc0 do_garbage_collect+0x312f/0x46f0 f2fs_gc+0x6b0/0x3bc0 f2fs_balance_fs+0x921/0x2260 f2fs_write_single_data_page+0x16be/0x2370 f2fs_write_cache_pages+0x428/0xd00 f2fs_write_data_pages+0x96e/0xd50 do_writepages+0x168/0x550 __writeback_single_inode+0x9f/0x870 writeback_sb_inodes+0x47d/0xb20 __writeback_inodes_wb+0xb2/0x200 wb_writeback+0x4bd/0x660 wb_workfn+0x5f3/0xab0 process_one_work+0x79f/0x13e0 worker_thread+0x89/0xf60 kthread+0x26a/0x300 ret_from_fork+0x22/0x30 RIP: 0010:new_curseg+0xe8d/0x15f0 La causa raíz es: ckpt.valid_block_count es inconsistente con la tabla SIT, la información estadística indica que el sistema de archivos tiene bloques libres, pero la tabla SIT indica que el sistema de archivos no tiene segmentos libres. Por lo tanto, durante la recolección de basura, se genera un pánico cuando el asignador LFS no encuentra un segmento libre. Este parche intenta solucionar este problema al verificar la coherencia entre ckpt.valid_block_count y el bloque contabilizado desde SIT.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49361)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura para el inodo en línea Yanming informó de un error del kernel en el kernel de Bugzilla [1], que se puede reproducir. El mensaje del error es: El mensaje del kernel se muestra a continuación: kernel BUG at fs/inode.c:611! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 dput+0x2dd/0x720 do_renameat2+0x596/0x970 __x64_sys_rename+0x78/0x90 do_syscall_64+0x3b/0x90 [1] https://bugzilla.kernel.org/show_bug.cgi?id=215895 El error se debe a que el inodo fuzzed tiene indicadores inline_data y cifrados. Durante f2fs_evict_inode(), como el inodo fue eliminado por rename(), esto provocará una conversión de datos en línea debido a indicadores conflictivos. La caché de la página se contaminará y se activará el pánico en clear_inode(). Intente corregir el error realizando más comprobaciones de integridad para el inodo de datos en línea en sanity_check_inode().
-
Vulnerabilidad en kernel de Linux (CVE-2022-49363)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar una comprobación de cordura en la dirección de bloque en f2fs_do_zero_range() Como informó Yanming en bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215894 He encontrado un error en el sistema de archivos F2FS en el kernel v5.17. He subido la secuencia de llamada del sistema como case.c, y se puede encontrar una imagen difusa en google net disk El kernel debe habilitar CONFIG_KASAN=y y CONFIG_KASAN_INLINE=y. Puede reproducir el error ejecutando los siguientes comandos: kernel BUG at fs/f2fs/segment.c:2291! Rastreo de llamadas: f2fs_invalidate_blocks+0x193/0x2d0 f2fs_fallocate+0x2593/0x4a70 vfs_fallocate+0x2a5/0xac0 ksys_fallocate+0x35/0x70 __x64_sys_fallocate+0x8e/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae La causa raíz es que, después de que se realizó el análisis difuso de la imagen, la información de mapeo de bloques en el inodo será inconsistente con la tabla SIT, por lo que en f2fs_fallocate(), causará pánico al actualizar SIT con blkaddr no válido. Solucionemos el problema agregando una verificación de cordura en la dirección del bloque antes de actualizar la tabla SIT con ella.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49364)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para borrar el inodo sucio en f2fs_evict_inode() Como informó Yanming en Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215904 El mensaje del kernel se muestra a continuación: ¡ERROR del kernel en fs/f2fs/inode.c:825! Call Trace: evict+0x282/0x4e0 __dentry_kill+0x2b2/0x4d0 shrink_dentry_list+0x17c/0x4f0 shrink_dcache_parent+0x143/0x1e0 do_one_tree+0x9/0x30 shrink_dcache_for_umount+0x51/0x120 generic_shutdown_super+0x5c/0x3a0 kill_block_super+0x90/0xd0 kill_f2fs_super+0x225/0x310 deactivate_locked_super+0x78/0xc0 cleanup_mnt+0x2b7/0x480 task_work_run+0xc8/0x150 exit_to_user_mode_prepare+0x14a/0x150 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0x90 The root cause is: inode node and dnode node share the same nid, so during f2fs_evict_inode(), dnode node truncation will invalidate its NAT entry, so when truncating inode node, it fails due to invalid NAT entry, result in inode is still marked as dirty, fix this issue by clearing dirty for inode and setting SBI_NEED_FSCK flag in filesystem. output from dump.f2fs: [print_node_info: 354] Node ID [0xf:15] is inode i_nid[0] [0x f : 15]
-
Vulnerabilidad en kernel de Linux (CVE-2022-49372)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: tcp_rtx_synack() puede ser llamado desde el contexto del proceso Laurent reportó el informe adjunto [1] Este error se activa con las siguientes condiciones: 0) Kernel construido con CONFIG_DEBUG_PREEMPT=y 1) Se crea un nuevo socket TCP FastOpen pasivo. Este socket FO espera un ACK proveniente del cliente para ser un ACK ESTABLISHED completo. 2) Una operación de socket en este socket pasa por el baile lock_sock() release_sock(). 3) Mientras el socket es propiedad del usuario en el paso 2), se recibe una retransmisión del SYN y se almacena en el backlog del socket. 4) En el momento release_sock(), el backlog del socket se procesa mientras está en el contexto del proceso. 5) Se cocina un paquete SYNACK en respuesta a la retransmisión de SYN. 6) -> tcp_rtx_synack() se llama en el contexto del proceso. Antes de el commit con culpa, tcp_rtx_synack() siempre se llamaba desde el controlador BH, desde un controlador de temporizador. Corrija esto usando TCP_INC_STATS() y NET_INC_STATS() que no asumen que el llamador está en un contexto no preemptible. [1] BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180 caller is tcp_rtx_synack.part.0+0x36/0xc0 CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1 Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021 Call Trace: dump_stack_lvl+0x48/0x5e check_preemption_disabled+0xde/0xe0 tcp_rtx_synack.part.0+0x36/0xc0 tcp_rtx_synack+0x8d/0xa0 ? kmem_cache_alloc+0x2e0/0x3e0 ? apparmor_file_alloc_security+0x3b/0x1f0 inet_rtx_syn_ack+0x16/0x30 tcp_check_req+0x367/0x610 tcp_rcv_state_process+0x91/0xf60 ? get_nohz_timer_target+0x18/0x1a0 ? lock_timer_base+0x61/0x80 ? preempt_count_add+0x68/0xa0 tcp_v4_do_rcv+0xbd/0x270 __release_sock+0x6d/0xb0 release_sock+0x2b/0x90 sock_setsockopt+0x138/0x1140 ? __sys_getsockname+0x7e/0xc0 ? aa_sk_perm+0x3e/0x1a0 __sys_setsockopt+0x198/0x1e0 __x64_sys_setsockopt+0x21/0x30 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae
-
Vulnerabilidad en kernel de Linux (CVE-2022-49378)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sfc: corrección considerando que todos los canales tienen colas TX Normalmente, todos los canales tienen colas RX y TX, pero esto no es cierto si se usa el modparam efx_separate_tx_channels=1. En esos casos, algunos canales solo tienen colas RX y otros solo colas TX (o más precisamente, las tienen asignadas, pero no inicializadas). Arregla efx_channel_has_tx_queues para que devuelva el valor correcto para este caso también. Mensajes mostrados en el momento de la prueba antes de la corrección: sfc 0000:03:00.0 ens6f0np0: Falló el comando MC 0x82 inlen 544 rc=-22 (raw=0) arg=0 ------------[ cortar aquí ]------------ netdevice: ens6f0np0: failed to initialise TXQ -1 WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc] [...] stripped Call Trace: efx_init_tx_queue+0xaa/0xf0 [sfc] efx_start_channels+0x49/0x120 [sfc] efx_start_all+0x1f8/0x430 [sfc] efx_net_open+0x5a/0xe0 [sfc] __dev_open+0xd0/0x190 __dev_change_flags+0x1b3/0x220 dev_change_flags+0x21/0x60 [...] stripped Messages shown at remove time before the fix: sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues sfc 0000:03:00.0 ens6f0np0: failed to flush queues
-
Vulnerabilidad en kernel de Linux (CVE-2022-49380)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar f2fs_bug_on() en dec_valid_node_count() Como informó Yanming en bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215897 He encontrado un error en el sistema de archivos F2FS en el kernel v5.17. El kernel debería habilitar CONFIG_KASAN=y y CONFIG_KASAN_INLINE=y. Puede reproducir el error ejecutando los siguientes comandos: El mensaje del kernel se muestra a continuación: kernel BUG at fs/f2fs/f2fs.h:2511! Call Trace: f2fs_remove_inode_page+0x2a2/0x830 f2fs_evict_inode+0x9b7/0x1510 evict+0x282/0x4e0 do_unlinkat+0x33a/0x540 __x64_sys_unlinkat+0x8e/0xd0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The root cause is: .total_valid_block_count or .total_valid_node_count could fuzzed to zero, then once dec_valid_node_count() was called, it will cause BUG_ON(), este parche corrige la impresión de información de advertencia y la configuración de SBI_NEED_FSCK en CP en lugar de pánico.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49383)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watchdog: rzg2l_wdt: Fix 'BUG: Invalid wait context' Este parche corrige el problema 'BUG: Invalid wait context' durante la devolución de llamada restart() al usar clk_prepare_enable() en lugar de pm_runtime_get_sync() para encender los relojes durante el reinicio. Este problema se detecta al realizar pruebas con renesas_defconfig. [ 42.213802] reiniciar: Reiniciando el sistema [ 42.217860] [ 42.219364] ============================== [ 42.223368] [ BUG: Invalid wait context ] [ 42.227372] 5.17.0-rc5-arm64-renesas-00002-g10393723e35e #522 Not tainted [ 42.234153] ----------------------------- [ 42.238155] systemd-shutdow/1 is trying to lock: [ 42.242766] ffff00000a650828 (&genpd->mlock){+.+.}-{3:3}, at: genpd_lock_mtx+0x14/0x20 [ 42.250709] other info that might help us debug this: [ 42.255753] context-{4:4} [ 42.258368] 2 locks held by systemd-shutdow/1: [ 42.262806] #0: ffff80000944e1c8 (system_transition_mutex#2){+.+.}-{3:3}, at: __do_sys_reboot+0xd0/0x250 [ 42.272388] #1: ffff8000094c4e40 (rcu_read_lock){....}-{1:2}, at: atomic_notifier_call_chain+0x0/0x150 [ 42.281795] stack backtrace: [ 42.284672] CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.17.0-rc5-arm64-renesas-00002-g10393723e35e #522 [ 42.294577] Hardware name: Renesas SMARC EVK based on r9a07g044c2 (DT) [ 42.301096] Call trace: [ 42.303538] dump_backtrace+0xcc/0xd8 [ 42.307203] show_stack+0x14/0x30 [ 42.310517] dump_stack_lvl+0x88/0xb0 [ 42.314180] dump_stack+0x14/0x2c [ 42.317492] __lock_acquire+0x1b24/0x1b50 [ 42.321502] lock_acquire+0x120/0x3a8 [ 42.325162] __mutex_lock+0x84/0x8f8 [ 42.328737] mutex_lock_nested+0x30/0x58 [ 42.332658] genpd_lock_mtx+0x14/0x20 [ 42.336319] genpd_runtime_resume+0xc4/0x228 [ 42.340587] __rpm_callback+0x44/0x170 [ 42.344337] rpm_callback+0x64/0x70 [ 42.347824] rpm_resume+0x4e0/0x6b8 [ 42.351310] __pm_runtime_resume+0x50/0x78 [ 42.355404] rzg2l_wdt_restart+0x28/0x68 [ 42.359329] watchdog_restart_notifier+0x1c/0x30 [ 42.363943] atomic_notifier_call_chain+0x94/0x150 [ 42.368732] do_kernel_restart+0x24/0x30 [ 42.372652] machine_restart+0x44/0x70 [ 42.376399] kernel_restart+0x3c/0x60 [ 42.380058] __do_sys_reboot+0x228/0x250 [ 42.383977] __arm64_sys_reboot+0x20/0x28 [ 42.387983] invoke_syscall+0x40/0xf8
-
Vulnerabilidad en kernel de Linux (CVE-2022-49394)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-iolatency: corrige los desequilibrios de recuento en vuelo y los bloqueos de IO en modo sin conexión iolatency necesita rastrear la cantidad de IO en vuelo por cgroup. Como este seguimiento puede ser costoso, se deshabilita cuando ningún cgroup tiene iolatency configurado para el dispositivo. Para garantizar que los contadores en vuelo se mantengan equilibrados, iolatency_set_limit() congela la request_queue mientras manipula el contador habilitado, lo que garantiza que no haya IO en vuelo y, por lo tanto, todos los contadores sean cero. Desafortunadamente, iolatency_set_limit() no es el único lugar donde se manipula el contador habilitado. iolatency_pd_offline() también puede dec el contador y activar la desactivación. Como esta desactivación ocurre sin congelar el q, esto puede suceder fácilmente mientras algunas IO están en vuelo y, por lo tanto, filtrar los recuentos. Esto se puede demostrar fácilmente activando iolatency en un cgroup vacío mientras los IO están en tránsito en otros cgroups y luego eliminando el cgroup. Tenga en cuenta que iolatency no debería haberse habilitado en ninguna otra parte del sistema para garantizar que la eliminación del cgroup deshabilite iolatency para todo el dispositivo. Lo siguiente sigue activando y desactivando iolatency on sda: echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do mkdir -p /sys/fs/cgroup/test echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1 rmdir /sys/fs/cgroup/test sleep 1 done and there's concurrent fio generating direct rand reads: fio --name test --filename=/dev/sda --direct=1 --rw=randread \ --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k while monitoring with the following drgn script: while True: for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list): blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node') pd = blkg.pd[prog['blkcg_policy_iolatency'].plid] if pd.value_() == 0: continue iolat = container_of(pd, 'struct iolatency_grp', 'pd') inflight = iolat.rq_wait.inflight.counter.value_() if inflight: print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} ' f'{cgroup_path(css.cgroup).decode("utf-8")}') time.sleep(1) The monitoring output looks like the following: inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /user.slice inflight=13 sda /user.slice inflight=17 sda /user.slice inflight=15 sda /user.slice inflight=18 sda /user.slice inflight=17 sda /user.slice inflight=20 sda /user.slice inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice inflight=19 sda /user.slice Si un cgroup con inflight atascado termina siendo limitado, las IO limitadas nunca se emitirán ya que no hay un evento de finalización para despertarlo, lo que genera un bloqueo indefinido. Este parche corrige el error al unificar la gestión de habilitación en un elemento de trabajo que se inicia automáticamente desde iolatency_set_min_lat_nsec(), que se llama desde las rutas iolatency_set_limit() y iolatency_pd_offline(). Es necesario apuntar a un elemento de trabajo ya que iolatency_pd_offline() se llama bajo bloqueos de giro, mientras que congelar una cola de solicitudes requiere un contexto que se pueda suspender. Esto también simplifica el código, lo que reduce el LOC sin los comentarios y evita los bloqueos innecesarios que ocurrían cada vez que se configuraba o borraba el objetivo de latencia de un cgroup.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49398)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: gadget: Reemplazar list_for_each_entry_safe() si se usa giveback La macro list_for_each_entry_safe() guarda el elemento actual (n) y el elemento posterior (n+1), de modo que n se pueda eliminar de forma segura sin dañar la lista. Sin embargo, al recorrer la lista y eliminar elementos usando gadget giveback, el bloqueo DWC3 se libera brevemente, lo que permite que se ejecuten otras rutinas. Existe una situación en la que, mientras se eliminan elementos de la lista cancelada usando dwc3_gadget_ep_cleanup_cancelled_requests(), la rutina de desactivación de pullup se ejecuta en paralelo (debido a la desvinculación de UDC). A medida que la rutina de limpieza elimina n, y la desactivación de pullup elimina n+1, una vez que la limpieza retoma el bloqueo DWC3, hace referencia a una solicitud que ya fue eliminada/gestionada. Con la depuración de lista habilitada, esto genera un pánico. Asegúrese de que todas las instancias de la macro se reemplacen donde se use la devolución de gadgets. Ejemplo de pila de llamadas: Thread#1: __dwc3_gadget_ep_set_halt() - CLEAR HALT -> dwc3_gadget_ep_cleanup_cancelled_requests() ->list_for_each_entry_safe() ->dwc3_gadget_giveback(n) ->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list] ->spin_unlock ->Thread#2 executes ... ->dwc3_gadget_giveback(n+1) ->Already removed! Thread#2: dwc3_gadget_pullup() ->waiting for dwc3 spin_lock ... ->Thread#1 released lock ->dwc3_stop_active_transfers() ->dwc3_remove_requests() ->fetches n+1 item from cancelled_list (n removed by Thread#1) ->dwc3_gadget_giveback() ->dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list] ->spin_unlock
-
Vulnerabilidad en kernel de Linux (CVE-2022-49399)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: goldfish: Use tty_port_destroy() para destruir el puerto En goldfish_tty_probe(), el puerto inicializado a través de tty_port_init() debe destruirse en las rutas de error. En goldfish_tty_remove(), qtty->port también debe destruirse o, de lo contrario, podría perder recursos. Corrija lo anterior llamando a tty_port_destroy().
-
Vulnerabilidad en kernel de Linux (CVE-2022-49402)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ftrace: Limpiar hash direct_functions en caso de fallos de registro Vemos el siguiente GPF cuando falla register_ftrace_direct: [ ] fallo de protección general, probablemente para dirección no canónica \ 0x200000000000010: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [...] [ ] RIP: 0010:ftrace_find_rec_direct+0x53/0x70 [ ] Code: 48 c1 e0 03 48 03 42 08 48 8b 10 31 c0 48 85 d2 74 [...] [ ] RSP: 0018:ffffc9000138bc10 EFLAGS: 00010206 [ ] RAX: 0000000000000000 RBX: ffffffff813e0df0 RCX: 000000000000003b [ ] RDX: 0200000000000000 RSI: 000000000000000c RDI: ffffffff813e0df0 [ ] RBP: ffffffffa00a3000 R08: ffffffff81180ce0 R09: 0000000000000001 [ ] R10: ffffc9000138bc18 R11: 0000000000000001 R12: ffffffff813e0df0 [ ] R13: ffffffff813e0df0 R14: ffff888171b56400 R15: 0000000000000000 [ ] FS: 00007fa9420c7780(0000) GS:ffff888ff6a00000(0000) knlGS:000000000 [ ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ ] CR2: 000000000770d000 CR3: 0000000107d50003 CR4: 0000000000370ee0 [ ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ ] Call Trace: [ ] [ ] register_ftrace_direct+0x54/0x290 [ ] ? render_sigset_t+0xa0/0xa0 [ ] bpf_trampoline_update+0x3f5/0x4a0 [ ] ? 0xffffffffa00a3000 [ ] bpf_trampoline_link_prog+0xa9/0x140 [ ] bpf_tracing_prog_attach+0x1dc/0x450 [ ] bpf_raw_tracepoint_open+0x9a/0x1e0 [ ] ? find_held_lock+0x2d/0x90 [ ] ? lock_release+0x150/0x430 [ ] __sys_bpf+0xbd6/0x2700 [ ] ? lock_is_held_type+0xd8/0x130 [ ] __x64_sys_bpf+0x1c/0x20 [ ] do_syscall_64+0x3a/0x80 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xae [ ] RIP: 0033:0x7fa9421defa9 [ ] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 9 f8 [...] [ ] RSP: 002b:00007ffed743bd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 [ ] RAX: ffffffffffffffda RBX: 00000000069d2480 RCX: 00007fa9421defa9 [ ] RDX: 0000000000000078 RSI: 00007ffed743bd80 RDI: 0000000000000011 [ ] RBP: 00007ffed743be00 R08: 0000000000bb7270 R09: 0000000000000000 [ ] R10: 00000000069da210 R11: 0000000000000246 R12: 0000000000000001 [ ] R13: 00007ffed743c4b0 R14: 00000000069d2480 R15: 0000000000000001 [ ] [ ] Modules linked in: klp_vm(OK) [ ] ---[ end trace 0000000000000000 ]--- One way to trigger this is: 1. load a livepatch that patches kernel function xxx; 2. run bpftrace -e 'kfunc:xxx {}', esto fallará (esperado por ahora); 3. repetir #2 => gpf. Esto se debe a que la entrada se agrega a direct_functions, pero no se elimina. Solucione esto eliminando la entrada de direct_functions cuando register_ftrace_direct falle. También elimine el último espacio final de ftrace.c, para que ya no tengamos que preocuparnos por eso.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49405)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: r8188eu: prevenir ->Ssid overflow en rtw_wx_set_scan() Este código tiene una verificación para prevenir el desbordamiento de lectura, pero necesita otra verificación para prevenir la escritura más allá del final de la matriz ->Ssid[].
-
Vulnerabilidad en kernel de Linux (CVE-2022-49420)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: annotate races around sk->sk_bound_dev_if UDP sendmsg() is lockless, and reads sk->sk_bound_dev_if while this field can be changed by another thread. Añade anotaciones mínimas para evitar splats de KCSAN para UDP. Los siguientes parches añadirán más anotaciones a posibles lectores sin bloqueo. ERROR: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsg write to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0: __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221 ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1: udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2413 ___sys_sendmsg net/socket.c:2467 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00000000 -> 0xffffff9b Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Elegí no agregar la etiqueta Correcciones: porque la ejecución tiene consecuencias menores y los equipos estables están suficientemente ocupados.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49503)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath9k_htc: se corrige el posible acceso fuera de los límites con rxstatus->rs_keyix no válido. "rxstatus->rs_keyix" finalmente se pasa a test_bit(), por lo que debemos asegurarnos de que esté dentro del mapa de bits. drivers/net/wireless/ath/ath9k/common.c:46 Error ath9k_cmn_rx_accept(): se pasan datos no confiables 'rx_stats->rs_keyix' a 'test_bit()'
-
Vulnerabilidad en kernel de Linux (CVE-2022-49504)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Inhibit aborta si se inserta un enchufe de loopback externo Después de ejecutar una prueba de loopback externa corta, cuando se quita el loopback externo y se inserta un cable normal que está conectado directamente a un dispositivo de destino, el sistema falla en la rutina llpfc_set_rrq_active(). Cuando se insertó el loopback, se transmitió un FLOGI. Mientras estamos en loopback, recibimos la solicitud FLOGI. El FLOGI se ABTS ya que reconocemos el mismo wppn, por lo que entendemos que es un loopback. Sin embargo, como el ABTS envía información de dirección, el puerto no está configurado en (fffffe), el ABTS se descarta en el cable. Se ejecuta una prueba de loopback corta de 1 trama y se completa antes de que el ABTS se agote. El looback se desconecta y el nuevo cable se enchufa, y se produce un FLOGI al nuevo dispositivo y se completa. Debido a una confusión en el recuento de referencias, la finalización del nuevo FLOGI libera el ndlp de la estructura. Luego, el ABTS original se completa y hace referencia al ndlp liberado, lo que genera el error. Se corrige no operando el ABTS cuando está en modo de bucle invertido (se descartará de todos modos). Se agregó una bandera para rastrear el modo para reconocer cuándo se debe no operar.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49506)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mediatek: Agregar funciones de devolución de llamada de registro/cancelación de vblank Encontramos un problema de pánico del kernel que indicaba que los datos de devolución de llamada serían NULL cuando se usaban en el controlador de irq de ovl. Hay un problema de sincronización entre mtk_disp_ovl_irq_handler() y mtk_ovl_disable_vblank(). Para resolver este problema, usamos el flujo para registrar/cancelar el cb de vblank: - Registrar la función de devolución de llamada y los datos de devolución de llamada cuando se crea crtc. - Cancelar la función de devolución de llamada y los datos de devolución de llamada cuando se destruye crtc. Con esta solución, podemos asegurar que los datos de devolución de llamada no serían NULL cuando se deshabilita vblank.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49511)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: defio: corrige la corrupción de la lista de páginas. Fácilmente se llega a la siguiente corrupción de lista: == list_add corruption. prev->next should be next (ffffffffc0ceb090), but was ffffec604507edc8. (prev=ffffec604507edc8). WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26 __list_add_valid+0x53/0x80 CPU: 65 PID: 3959 Comm: fbdev Tainted: G U RIP: 0010:__list_add_valid+0x53/0x80 Call Trace: fb_deferred_io_mkwrite+0xea/0x150 do_page_mkwrite+0x57/0xc0 do_wp_page+0x278/0x2f0 __handle_mm_fault+0xdc2/0x1590 handle_mm_fault+0xdd/0x2c0 do_user_addr_fault+0x1d3/0x650 exc_page_fault+0x77/0x180 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x7fd98fc8fad1 == Averigüe que la ejecución ocurre cuando un proceso agrega &page->lru a la cola de la lista de páginas en fb_deferred_io_mkwrite(), otro proceso está reinicializando la misma &page->lru en fb_deferred_io_fault(), que no está protegida por el bloqueo. Esta solución consiste en inicializar todas las listas de páginas una vez durante la inicialización, no solo corrige la corrupción de la lista, sino que también evita que INIT_LIST_HEAD() se ejecute de manera redundante. V2: cambie "int i" por "unsigned int i" (Geert Uytterhoeven)
-
Vulnerabilidad en kernel de Linux (CVE-2022-49512)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: rawnand: denali: Usar recursos de dispositivo administrados Todos los recursos utilizados por este controlador tienen interfaces administradas, así que úselas. De lo contrario, obtendremos el siguiente splat: [ 4.472703] denali-nand-pci 0000:00:05.0: timeout while waiting for irq 0x1000 [ 4.474071] denali-nand-pci: probe of 0000:00:05.0 failed with error -5 [ 4.473538] nand: No NAND device found [ 4.474068] BUG: unable to handle page fault for address: ffffc90005000410 [ 4.475169] #PF: supervisor write access in kernel mode [ 4.475579] #PF: error_code(0x0002) - not-present page [ 4.478362] RIP: 0010:iowrite32+0x9/0x50 [ 4.486068] Call Trace: [ 4.486269] [ 4.486443] denali_isr+0x15b/0x300 [denali] [ 4.486788] ? denali_direct_write+0x50/0x50 [denali] [ 4.487189] __handle_irq_event_percpu+0x161/0x3b0 [ 4.487571] handle_irq_event+0x7d/0x1b0 [ 4.487884] handle_fasteoi_irq+0x2b0/0x770 [ 4.488219] __common_interrupt+0xc8/0x1b0 [ 4.488549] common_interrupt+0x9a/0xc0
-
Vulnerabilidad en kernel de Linux (CVE-2022-49513)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: governor: Use el método kobject release() para liberar dbs_data La estructura dbs_data incorpora una estructura gov_attr_set y la estructura gov_attr_set incorpora un kobject. Dado que cada kobject debe tener un método release() y no podemos usar kfree() para liberarlo directamente, introduzca cpufreq_dbs_data_release() para liberar dbs_data a través del método kobject::release(). Esto corrige el seguimiento de llamadas como se muestra a continuación: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [] __irq_exit_rcu+0x108/0x1a4 [ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreq_dbs_data_release() function. ]
-
Vulnerabilidad en kernel de Linux (CVE-2022-49515)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: cs35l41: Se corrige un acceso fuera de los límites en otp_packed_element_t. CS35L41_NUM_OTP_ELEM es 100, pero solo se definen 99 entradas en la matriz otp_map_1/2[CS35L41_NUM_OTP_ELEM], esto hará que UBSAN informe una advertencia de cambio fuera de los límites en cs35l41_otp_unpack() ya que la última entrada en la matriz dará como resultado GENMASK(-1, 0). UBSAN informa este problema: UBSAN: cambio fuera de los límites en /home/hwang4/build/jammy/jammy/sound/soc/codecs/cs35l41-lib.c:836:8 El exponente de cambio 64 es demasiado grande para el tipo de 64 bits 'long unsigned int' CPU: 10 PID: 595 Comm: systemd-udevd No contaminado 5.15.0-23-generic #23 Nombre del hardware: LENOVO \x02MFG_IN_GO/\x02MFG_IN_GO, BIOS N3GET19W (1.00) 03/11/2022 Seguimiento de llamadas: show_stack+0x52/0x58 dump_stack_lvl+0x4a/0x5f dump_stack+0x10/0x12 cs35l41_hda_i2c_probe+0x65/0x90 [snd_hda_scodec_cs35l41_i2c] ? cs35l41_hda_i2c_remove+0x20/0x20 [snd_hda_scodec_cs35l41_i2c] sonda de dispositivo i2c+0x252/0x2b0
-
Vulnerabilidad en kernel de Linux (CVE-2022-49518)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: ipc3-topology: get_control_data correcto para payload que no sea de bytes Es posible crear una topología donde sof_get_control_data() haría acceso fuera de los límites porque espera que solo se llame cuando el payload sea de tipo bytes. Confusamente también maneja otros tipos de controles, pero la implementación del análisis del payload solo es válida para bytes. Corrija el código para contar los controles que no sean de bytes y en lugar de almacenar un puntero a sof_abi_hdr en sof_widget_data (que solo es válido para bytes), almacene el puntero a los datos en sí y agregue un nuevo miembro para guardar el tamaño de los datos. En el caso de controles que no sean de bytes, almacenamos el puntero al chanv en sí, que es solo una matriz de valores al final. En el caso del control de bytes, elimine la comprobación incorrecta cdata->data (wdata[i].pdata) contra NULL ya que es incorrecta e inválida en este contexto. Los datos apuntan al final de la estructura cdata, por lo que nunca deben ser nulos.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49519)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath10k: omitir ath10k_halt durante la suspensión para el estado del controlador REINICIO Se observa un doble bloqueo libre cuando la recuperación de FW (causada por el tiempo de espera/bloqueo de wmi) es seguida por un evento de suspensión inmediata. La recuperación de FW es activada por ath10k_core_restart() que llama a la limpieza del controlador a través de ath10k_halt(). Cuando el evento de suspensión ocurre entre la recuperación de FW, el hilo de trabajo de reinicio se pone en estado congelado hasta que se completa la suspensión. El evento de suspensión activa ath10k_stop() que nuevamente activa ath10k_halt() La doble invocación de ath10k_halt() hace que ath10k_htt_rx_free() se llame dos veces (Nota: ath10k_htt_rx_alloc no fue llamado por el hilo de trabajo de reinicio debido a su estado congelado), lo que causa el bloqueo. Para solucionar esto, durante el flujo de suspensión, omite la llamada a ath10k_halt() en ath10k_stop() cuando el estado actual del controlador sea ATH10K_STATE_RESTARTING. Además, para el estado del controlador ATH10K_STATE_RESTARTING, llama a ath10k_wait_for_suspend() en ath10k_stop(). Esto se debe a que la llamada a ath10k_wait_for_suspend() se omite más adelante en [ath10k_halt() > ath10k_core_stop()] para el estado del controlador ATH10K_STATE_RESTARTING. El hilo de trabajo de reinicio congelado se cancelará durante la reanudación cuando el dispositivo salga de la suspensión. A continuación se muestra la pila de fallas como referencia: [ 428.469167] ------------[ cortar aquí ]------------ [ 428.469180] kernel BUG at mm/slub.c:4150! [ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 428.469219] Workqueue: events_unbound async_run_entry_fn [ 428.469230] RIP: 0010:kfree+0x319/0x31b [ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246 [ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000 [ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000 [ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000 [ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 428.469285] Call Trace: [ 428.469295] ? dma_free_attrs+0x5f/0x7d [ 428.469320] ath10k_core_stop+0x5b/0x6f [ 428.469336] ath10k_halt+0x126/0x177 [ 428.469352] ath10k_stop+0x41/0x7e [ 428.469387] drv_stop+0x88/0x10e [ 428.469410] __ieee80211_suspend+0x297/0x411 [ 428.469441] rdev_suspend+0x6e/0xd0 [ 428.469462] wiphy_suspend+0xb1/0x105 [ 428.469483] ? name_show+0x2d/0x2d [ 428.469490] dpm_run_callback+0x8c/0x126 [ 428.469511] ? name_show+0x2d/0x2d [ 428.469517] __device_suspend+0x2e7/0x41b [ 428.469523] async_suspend+0x1f/0x93 [ 428.469529] async_run_entry_fn+0x3d/0xd1 [ 428.469535] process_one_work+0x1b1/0x329 [ 428.469541] worker_thread+0x213/0x372 [ 428.469547] kthread+0x150/0x15f [ 428.469552] ? pr_cont_work+0x58/0x58 [ 428.469558] ? kthread_blkcg+0x31/0x31 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
-
Vulnerabilidad en kernel de Linux (CVE-2022-49520)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: compat: No trate el número de llamada al sistema como ESR_ELx para una llamada al sistema incorrecta Si un proceso compat intenta ejecutar una llamada al sistema desconocida por encima del número __ARM_NR_COMPAT_END, el kernel envía una señal SIGILL al proceso infractor. La información sobre el error se imprime en dmesg en compat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() -> arm64_show_signal(). arm64_show_signal() interpreta un valor distinto de cero para current->thread.fault_code como un síndrome de excepción y muestra el mensaje asociado con el campo ESR_ELx.EC (bits 31:26). current->thread.fault_code se configura en compat_arm_syscall() -> arm64_notify_die() con el número de llamada al sistema incorrecto en lugar de un valor ESR_ELx válido. Esto significa que el campo ESR_ELx.EC tiene el valor que el usuario configuró para el número de llamada al sistema y el núcleo puede terminar imprimiendo mensajes de excepción falsos*. Por ejemplo, para el número de llamada al sistema 0x68000000, que evalúa al valor ESR_ELx.EC 0x1A (ESR_ELx_EC_FPAC), el núcleo imprime este error: [ 18.349161] syscall[300]: excepción no controlada: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - mala compatibilidad syscall(2) en syscall[10000+50000] [ 18.350639] CPU: 2 PID: 300 Comm: syscall No contaminado 5.18.0-rc1 #79 [ 18.351249] Nombre del hardware: Pine64 RockPro64 v2.0 (DT) [..] lo cual es engañoso, ya que la llamada al sistema de compatibilidad incorrecta no tiene nada que ver con la autenticación de puntero. Evite que arm64_show_signal() imprima información sobre el síndrome de excepción haciendo que compat_arm_syscall() establezca el valor ESR_ELx en 0, ya que no tiene significado para un número de llamada de sistema no válido. El ejemplo anterior ahora se convierte en: [ 19.935275] syscall[301]: excepción no controlada: Oops - bad compat syscall(2) in syscall[10000+50000] [ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80 [ 19.936894] Nombre del hardware: Pine64 RockPro64 v2.0 (DT) [..] que aunque muestra menos información porque falta el número de syscall, anunciado erróneamente como el valor ESR, es mejor que mostrar información claramente errónea. El número de syscall se puede obtener fácilmente con strace. *Un valor de 32 bits mayor o igual a 0x8000_0000 se interpreta como un entero negativo en compat_arm_syscal() y la condición scno < __ARM_NR_COMPAT_END se evalúa como verdadera; la llamada al sistema saldrá al espacio de usuario en este caso con el código de error ENOSYS en lugar de llamar a arm64_notify_die().
-
Vulnerabilidad en kernel de Linux (CVE-2022-49521)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Se corrige la pérdida de recursos en lpfc_sli4_send_seq_to_ulp() Si no se encuentra ningún controlador en lpfc_complete_unsol_iocb() que coincida con el rctl de una trama recibida, la trama se descarta y se pierden recursos. Se soluciona devolviendo recursos al descartar un tipo de trama no controlada. Se actualiza la gestión de lpfc_fc_frame_check() del servicio de enlace básico NOP.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49522)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: jz4740: Aplicar límites del motor DMA al tamaño máximo de segmento. Haga lo que se hace en otros controladores de host MMC habilitados para DMA (cf. host/mmci.c) y limite el tamaño máximo de segmento en función de las capacidades del motor DMA. Esto es necesario para evitar advertencias como la siguiente con CONFIG_DMA_API_DEBUG=y. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 21 at kernel/dma/debug.c:1162 debug_dma_map_sg+0x2f4/0x39c DMA-API: jz4780-dma 13420000.dma-controller: mapping sg segment longer than device claims to support [len=98304] [max=65536] CPU: 0 PID: 21 Comm: kworker/0:1H Not tainted 5.18.0-rc1 #19 Workqueue: kblockd blk_mq_run_work_fn Stack : 81575aec 00000004 80620000 80620000 80620000 805e7358 00000009 801537ac 814c832c 806276e3 806e34b4 80620000 81575aec 00000001 81575ab8 09291444 00000000 00000000 805e7358 81575958 ffffffea 8157596c 00000000 636f6c62 6220646b 80387a70 0000000f 6d5f6b6c 80620000 00000000 81575ba4 00000009 805e170c 80896640 00000001 00010000 00000000 00000000 00006098 806e0000 ... Call Trace: [<80107670>] show_stack+0x84/0x120 [<80528cd8>] __warn+0xb8/0xec [<80528d78>] warn_slowpath_fmt+0x6c/0xb8 [<8016f1d4>] debug_dma_map_sg+0x2f4/0x39c [<80169d4c>] __dma_map_sg_attrs+0xf0/0x118 [<8016a27c>] dma_map_sg_attrs+0x14/0x28 [<804f66b4>] jz4740_mmc_prepare_dma_data+0x74/0xa4 [<804f6714>] jz4740_mmc_pre_request+0x30/0x54 [<804f4ff4>] mmc_blk_mq_issue_rq+0x6e0/0x7bc [<804f5590>] mmc_mq_queue_rq+0x220/0x2d4 [<8038b2c0>] blk_mq_dispatch_rq_list+0x480/0x664 [<80391040>] blk_mq_do_dispatch_sched+0x2dc/0x370 [<80391468>] __blk_mq_sched_dispatch_requests+0xec/0x164 [<80391540>] blk_mq_sched_dispatch_requests+0x44/0x94 [<80387900>] __blk_mq_run_hw_queue+0xb0/0xcc [<80134c14>] process_one_work+0x1b8/0x264 [<80134ff8>] worker_thread+0x2ec/0x3b8 [<8013b13c>] kthread+0x104/0x10c [<80101dcc>] ret_from_kernel_thread+0x14/0x1c ---[ end trace 0000000000000000 ]---
-
Vulnerabilidad en kernel de Linux (CVE-2022-49525)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: cx25821: Arreglar la advertencia al eliminar el módulo Al eliminar el módulo, obtendremos la siguiente advertencia: [ 14.746697] remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'cx25821[1]' [ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0 [ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0 [ 14.759589] Call Trace: [ 14.759792] [ 14.759975] unregister_irq_proc+0x14c/0x170 [ 14.760340] irq_free_descs+0x94/0xe0 [ 14.760640] mp_unmap_irq+0xb6/0x100 [ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40 [ 14.761334] acpi_pci_irq_disable+0x1d3/0x320 [ 14.761688] pci_disable_device+0x1ad/0x380 [ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60 [ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821] [ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821] [ 14.763242] pci_device_remove+0x92/0x240 Solucione esto liberando el irq antes de llamar a pci_disable_device().
-
Vulnerabilidad en kernel de Linux (CVE-2022-49526)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md/bitmap: no establezca valores sb si no puede pasar la comprobación de cordura. Si el área de mapa de bits contiene datos no válidos, el kernel se bloqueará y mdadm activará "Error de segmentación". Este es un error especial de cluster-md. En un entorno no agrupado, mdadm gestionará el caso de metadatos dañados. En una matriz agrupada, solo el espacio del kernel getiona la información de la ranura de mapa de bits. Pero incluso este error solo ocurrió en un entorno agrupado, la comprobación de cordura actual es incorrecta, el código debe cambiarse. Cómo activar: (inyección defectuosa) dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb mdadm -Ss echo aaa > magic.txt == below modifying slot 2 bitmap data == dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3 <== destroy magic dd if=/dev/zero of=/dev/sda seek=16436 bs=1 count=4 <== ZERO chunksize mdadm -A /dev/md0 /dev/sda /dev/sdb == kernel crashes. mdadm outputs "Segmentation fault" == Reason of kernel crash: In md_bitmap_read_sb (called by md_bitmap_create), bad bitmap magic didn't block chunksize assignment, and zero value made DIV_ROUND_UP_SECTOR_T() trigger "divide error". Crash log: kernel: md: md0 stopped. kernel: md/raid1:md0: not clean -- starting background reconstruction kernel: md/raid1:md0: active with 2 out of 2 mirrors kernel: dlm: ... ... kernel: md-cluster: Joined cluster 44810aba-38bb-e6b8-daca-bc97a0b254aa slot 1 kernel: md0: invalid bitmap file superblock: bad magic kernel: md_bitmap_copy_from_slot can't get bitmap from slot 2 kernel: md-cluster: Could not gather bitmaps from slot 2 kernel: divide error: 0000 [#1] SMP NOPTI kernel: CPU: 0 PID: 1603 Comm: mdadm Not tainted 5.14.6-1-default kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod] kernel: RSP: 0018:ffffc22ac0843ba0 EFLAGS: 00010246 kernel: ... ... kernel: Call Trace: kernel: ? dlm_lock_sync+0xd0/0xd0 [md_cluster 77fe..7a0] kernel: md_bitmap_copy_from_slot+0x2c/0x290 [md_mod 24ea..d3a] kernel: load_bitmaps+0xec/0x210 [md_cluster 77fe..7a0] kernel: md_bitmap_load+0x81/0x1e0 [md_mod 24ea..d3a] kernel: do_md_run+0x30/0x100 [md_mod 24ea..d3a] kernel: md_ioctl+0x1290/0x15a0 [md_mod 24ea....d3a] kernel: ? mddev_unlock+0xaa/0x130 [md_mod 24ea..d3a] kernel: ? blkdev_ioctl+0xb1/0x2b0 kernel: block_ioctl+0x3b/0x40 kernel: __x64_sys_ioctl+0x7f/0xb0 kernel: do_syscall_64+0x59/0x80 kernel: ? exit_to_user_mode_prepare+0x1ab/0x230 kernel: ? syscall_exit_to_user_mode+0x18/0x40 kernel: ? do_syscall_64+0x69/0x80 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xae kernel: RIP: 0033:0x7f4a15fa722b kernel: ... ... kernel: ---[ end trace 8afa7612f559c868 ]--- kernel: RIP: 0010:md_bitmap_create+0x1d1/0x850 [md_mod]
-
Vulnerabilidad en kernel de Linux (CVE-2022-49528)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: i2c: dw9714: Deshabilitar el regulador cuando el controlador no realiza la prueba Cuando el controlador no realiza la prueba, obtendremos el siguiente splat: [ 59.305988] ------------[ cut here ]------------ [ 59.306417] WARNING: CPU: 2 PID: 395 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0 [ 59.310345] RIP: 0010:_regulator_put+0x3ec/0x4e0 [ 59.318362] Call Trace: [ 59.318582] [ 59.318765] regulator_put+0x1f/0x30 [ 59.319058] devres_release_group+0x319/0x3d0 [ 59.319420] i2c_device_probe+0x766/0x940 Solucione esto deshabilitando el regulador en la gestión de errores.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49533)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath11k: Cambiar el número máximo de SSID y BSSID de sonda activa a capacidad fw El número máximo de SSID en un para solicitudes de sonda activas se informa actualmente como 16 (WLAN_SCAN_PARAMS_MAX_SSID) al registrar el controlador. La estructura scan_req_params solo tiene la capacidad de contener 10 SSID. Esto conduce a un desbordamiento de búfer que puede activarse desde wpa_supplicant en el espacio de usuario. Al copiar los SSID en la estructura scan_req_params en la ruta ath11k_mac_op_hw_scan, puede sobrescribir el puntero extraie. El firmware admite 16 ssid * 4 bssid, para cada ssid se enviarán 4 solicitudes de sonda combinadas bssid, por lo que se admiten 64 solicitudes de sonda en total. Por lo tanto, configure tanto el ssid máximo como el bssid en 16 y 4 respectivamente. Elimine las macros redundantes de ssid y bssid. Probado en: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01300-QCAHKSWPL_SILICONZ-1
-
Vulnerabilidad en kernel de Linux (CVE-2022-49537)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Se ha corregido el seguimiento de llamadas observado durante la E/S con CMF habilitado Se observó lo siguiente con CMF habilitado: ERROR: using smp_processor_id() in preemptible code: systemd-udevd/31711 kernel: caller is lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: CPU: 12 PID: 31711 Comm: systemd-udevd kernel: Call Trace: kernel: kernel: dump_stack_lvl+0x44/0x57 kernel: check_preemption_disabled+0xbf/0xe0 kernel: lpfc_update_cmf_cmd+0x214/0x420 [lpfc] kernel: lpfc_nvme_fcp_io_submit+0x23b4/0x4df0 [lpfc] this_cpu_ptr() calls smp_processor_id() in a preemptible context. Fix by using per_cpu_ptr() with raw_smp_processor_id() instead.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49539)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtw89: ser: corrige las fugas de CAM que ocurren en el reinicio de L2 El CAM, es decir, la dirección CAM y el bssid CAM aquí, tendrán fugas durante el proceso de reinicio de L2 de SER (recuperación de error del sistema) y ieee80211_restart_hw() que es llamado por el proceso de reinicio de L2 eventualmente. El flujo normal sería como -> agregar interfaz (adquirir 1) -> ingresar ips (liberar 1) -> dejar ips (adquirir 1) -> conexión (ocupar 1) <(A) 1 fuga después del reinicio de L2 si la conexión no es segura> El flujo ieee80211_restart_hw() (bajo conexión) -> ieee80211 reconfig -> agregar interfaz (adquirir 1) -> dejar ips (adquirir 1) -> conexión (ocupar (A) + 2) <(B) 1 fuga más> Originalmente, CAM se libera antes del reinicio de HW solo si la conexión está bajo seguridad. Ahora, libere la CAM de cualquier conexión para reparar la fuga en (A). Por otra parte, verifique si la CAM ya es válida para evitar realizar múltiples adquisiciones para reparar (B). Además, si está en modo AP, libere la dirección CAM de todas las estaciones antes de reiniciar el hardware.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49540)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 21/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rcu-tasks: corrige la ejecución en el trabajo de programación y vaciado. Al iniciar las CPU secundarias, cpus_read_[lock/unlock] no mantiene estable la máscara de CPU en línea. La máscara en línea transitoria da como resultado el siguiente seguimiento de llamadas. [ 0.324121] CPU1: Procesador secundario iniciado 0x0000000001 [0x410fd083] [ 0.346652] Caché PIPT I detectado en CPU2 [ 0.347212] CPU2: Procesador secundario iniciado 0x0000000002 [0x410fd083] [ 0.377255] Caché PIPT I detectado en CPU3 [ 0.377823] CPU3: Procesador secundario iniciado 0x0000000003 [0x410fd083] [ 0.379040] ------------[ cortar aquí ]------------ [ 0.383662] WARNING: CPU: 0 PID: 10 at kernel/workqueue.c:3084 __flush_work+0x12c/0x138 [ 0.384850] Modules linked in: [ 0.385403] CPU: 0 PID: 10 Comm: rcu_tasks_rude_ Not tainted 5.17.0-rc3-v8+ #13 [ 0.386473] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 0.387289] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.388308] pc : __flush_work+0x12c/0x138 [ 0.388970] lr : __flush_work+0x80/0x138 [ 0.389620] sp : ffffffc00aaf3c60 [ 0.390139] x29: ffffffc00aaf3d20 x28: ffffffc009c16af0 x27: ffffff80f761df48 [ 0.391316] x26: 0000000000000004 x25: 0000000000000003 x24: 0000000000000100 [ 0.392493] x23: ffffffffffffffff x22: ffffffc009c16b10 x21: ffffffc009c16b28 [ 0.393668] x20: ffffffc009e53861 x19: ffffff80f77fbf40 x18: 00000000d744fcc9 [ 0.394842] x17: 000000000000000b x16: 00000000000001c2 x15: ffffffc009e57550 [ 0.396016] x14: 0000000000000000 x13: ffffffffffffffff x12: 0000000100000000 [ 0.397190] x11: 0000000000000462 x10: ffffff8040258008 x9 : 0000000100000000 [ 0.398364] x8 : 0000000000000000 x7 : ffffffc0093c8bf4 x6 : 0000000000000000 [ 0.399538] x5 : 0000000000000000 x4 : ffffffc00a976e40 x3 : ffffffc00810444c [ 0.400711] x2 : 0000000000000004 x1 : 0000000000000000 x0 : 0000000000000000 [ 0.401886] Call trace: [ 0.402309] __flush_work+0x12c/0x138 [ 0.402941] schedule_on_each_cpu+0x228/0x278 [ 0.403693] rcu_tasks_rude_wait_gp+0x130/0x144 [ 0.404502] rcu_tasks_kthread+0x220/0x254 [ 0.405264] kthread+0x174/0x1ac [ 0.405837] ret_from_fork+0x10/0x20 [ 0.406456] irq event stamp: 102 [ 0.406966] hardirqs last enabled at (101): [] _raw_spin_unlock_irq+0x78/0xb4 [ 0.408304] hardirqs last disabled at (102): [] el1_dbg+0x24/0x5c [ 0.409410] softirqs last enabled at (54): [] local_bh_enable+0xc/0x2c [ 0.410645] softirqs last disabled at (50): [] local_bh_disable+0xc/0x2c [ 0.411890] ---[ end trace 0000000000000000 ]--- [ 0.413000] smp: Brought up 1 node, 4 CPUs [ 0.413762] SMP: Total of 4 processors activated. [ 0.414566] CPU features: detected: 32-bit EL0 Support [ 0.415414] CPU features: detected: 32-bit EL1 Support [ 0.416278] CPU features: detected: CRC32 instructions [ 0.447021] Callback from call_rcu_tasks_rude() invoked. [ 0.506693] Callback from call_rcu_tasks() invoked. Por lo tanto, esta confirmación corrige este problema al aplicar una optimización de CPU única al proceso de período de gracia de RCU Tasks Rude. El punto clave aquí es que el propósito de esta variante de RCU es forzar una programación en cada CPU en línea desde algún evento pasado. Pero la función rcu_tasks_rude_wait_gp() se ejecuta en el contexto del kthread del período de gracia de RCU Tasks Rude, por lo que ya debe haber habido un cambio de contexto en la CPU actual desde la llamada asynchronous_rcu_tasks_rude() o call_rcu_tasks_rude(). Por lo tanto, si solo hay una CPU en línea, el kthread del período de gracia de RCU Tasks Rude no necesita hacer nada en absoluto. Resulta que la llamada de la función rcu_tasks_rude_wait_gp() a schedule_on_each_cpu() causa problemas durante el arranque temprano. Durante ese tiempo, solo hay una CPU en línea, es decir, la CPU de arranque. Por lo tanto, la aplicación de esta optimización de CPU única corrige las instancias de arranque temprano de este problema.
-
Vulnerabilidad en pihome-shc PiHome 2.0 (CVE-2025-1742)
Severidad: MEDIA
Fecha de publicación: 27/02/2025
Fecha de última actualización: 21/10/2025
Se ha encontrado una vulnerabilidad, que se ha clasificado como problemática, en pihome-shc PiHome 2.0. Este problema afecta a algunas funciones desconocidas del archivo /home.php. La manipulación del argumento page_name provoca cross-site scripting. El ataque puede ejecutarse de forma remota. El exploit se ha hecho público y puede utilizarse. Se contactó al proveedor con anticipación sobre esta revelación, pero no respondió de ninguna manera.
-
Vulnerabilidad en 274056675 springboot-openai-chatgpt e84f6f5 (CVE-2025-2334)
Severidad: MEDIA
Fecha de publicación: 15/03/2025
Fecha de última actualización: 21/10/2025
Se ha encontrado una vulnerabilidad clasificada como problemática en 274056675 springboot-openai-chatgpt e84f6f5. Esta vulnerabilidad afecta a la función deleteChat del archivo /api/mjkj-chat/chat/ai/delete/chat del componente Chat History Handler. La manipulación del argumento chatListId genera controles de acceso inadecuados. Es posible iniciar el ataque de forma remota. Se ha hecho público el exploit y puede que sea utilizado.
-
Vulnerabilidad en Softdial Contact Center de Sytel Ltd (CVE-2025-2493)
Severidad: ALTA
Fecha de publicación: 18/03/2025
Fecha de última actualización: 21/10/2025
Vulnerabilidad de Path Traversal en Softdial Contact Center de Sytel Ltd. Esta vulnerabilidad permite a un atacante manipular el parámetro 'id' del endpoint '/softdial/scheduler/load.php' para navegar más allá del directorio previsto. Esto puede permitir el acceso no autorizado a archivos confidenciales fuera del alcance previsto, lo que supone un riesgo de seguridad.
-
Vulnerabilidad en Centro de Contacto Softdial de Sytel Ltd (CVE-2025-2494)
Severidad: ALTA
Fecha de publicación: 18/03/2025
Fecha de última actualización: 21/10/2025
Subida de archivos sin restricciones al Centro de Contacto Softdial de Sytel Ltd. Esta vulnerabilidad podría permitir a un atacante subir archivos al servidor a través del endpoint '/softdial/phpconsole/upload.php', protegido por autenticación HTTP básica. Los archivos se suben a un directorio expuesto por la aplicación web, lo que podría provocar la ejecución de código, otorgando al atacante control total sobre el servidor.
-
Vulnerabilidad en Softdial Contact Center de Sytel Ltd (CVE-2025-2495)
Severidad: MEDIA
Fecha de publicación: 18/03/2025
Fecha de última actualización: 21/10/2025
Cross-Site Scripting (XSS) almacenado en Softdial Contact Center de Sytel Ltd. Esta vulnerabilidad permite a un atacante cargar archivos XML al servidor con código JavaScript inyectado mediante el recurso '/softdial/scheduler/save.php'. El código inyectado se ejecutará al cargar el archivo mediante el recurso '/softdial/scheduler/load.php' y puede redirigir a la víctima a sitios maliciosos o robar su información de inicio de sesión para suplantar su identidad.
-
Vulnerabilidad en haotian-liu/llava (CVE-2024-12065)
Severidad: ALTA
Fecha de publicación: 20/03/2025
Fecha de última actualización: 21/10/2025
Existe una vulnerabilidad de inclusión de archivos locales en haotian-liu/llava en el commit c121f04. Esta vulnerabilidad permite a un atacante acceder a cualquier archivo del sistema mediante el envío de múltiples solicitudes manipuladas al servidor. El problema se debe a una validación de entrada incorrecta en el componente de interfaz web de gradio.
-
Vulnerabilidad en haotian-liu/llava (CVE-2024-12068)
Severidad: ALTA
Fecha de publicación: 20/03/2025
Fecha de última actualización: 21/10/2025
Se descubrió una vulnerabilidad de Server-Side Request Forgery (SSRF) en haotian-liu/llava, que afecta a la versión git c121f04. Esta vulnerabilidad permite a un atacante obligar al servidor a realizar solicitudes HTTP a URL arbitrarias, lo que podría permitir el acceso a datos confidenciales a los que solo se puede acceder desde el servidor, como las credenciales de metadatos de AWS.
-
Vulnerabilidad en fig2dev (CVE-2025-31162)
Severidad: MEDIA
Fecha de publicación: 28/03/2025
Fecha de última actualización: 21/10/2025
La excepción de punto flotante en fig2dev en la versión 3.2.9a permite a un atacante obtener disponibilidad mediante la manipulación de entrada local mediante la función get_slope.
-
Vulnerabilidad en fig2dev (CVE-2025-31163)
Severidad: MEDIA
Fecha de publicación: 28/03/2025
Fecha de última actualización: 21/10/2025
Una falla de segmentación en fig2dev en la versión 3.2.9a permite que un atacante acceda a la información mediante la manipulación de entrada local mediante la función put_patternarc.
-
Vulnerabilidad en fig2dev (CVE-2025-31164)
Severidad: MEDIA
Fecha de publicación: 28/03/2025
Fecha de última actualización: 21/10/2025
El desbordamiento del búfer de montón en fig2dev en la versión 3.2.9a permite a un atacante obtener disponibilidad mediante la manipulación de entrada local mediante create_line_with_spline.
-
Vulnerabilidad en tarteaucitron.js (CVE-2025-31138)
Severidad: MEDIA
Fecha de publicación: 07/04/2025
Fecha de última actualización: 21/10/2025
tarteaucitron.js es un banner de cookies compatible y accesible. Se identificó una vulnerabilidad en tarteaucitron.js antes de la versión 1.20.1, donde las entradas controladas por el usuario para las dimensiones de los elementos (ancho y alto) no se validaban correctamente. Esto permitía a un atacante con acceso directo al código fuente del sitio o a un complemento de CMS establecer valores como 100%;height:100%;position:fixed;, lo que podría cubrir toda la ventana gráfica y facilitar ataques de clickjacking. Un atacante con privilegios elevados podría explotar esta vulnerabilidad para superponer elementos maliciosos de la interfaz de usuario sobre contenido legítimo, engañar a los usuarios para que interactúen con elementos ocultos (clickjacking) o interrumpir la funcionalidad y la accesibilidad previstas del sitio web. Esta vulnerabilidad se corrigió en la versión 1.20.1.
-
Vulnerabilidad en tarteaucitron.js (CVE-2025-31475)
Severidad: MEDIA
Fecha de publicación: 07/04/2025
Fecha de última actualización: 21/10/2025
tarteaucitron.js es un banner de cookies compatible y accesible. Se identificó una vulnerabilidad en tarteaucitron.js antes de la versión 1.20.1, donde la función addOrUpdate, utilizada para aplicar textos personalizados, no validaba correctamente la entrada. Esto permitía a un atacante con acceso directo al código fuente del sitio o a un complemento de CMS manipular prototipos de objetos JavaScript, lo que conllevaba posibles riesgos de seguridad, como corrupción de datos o ejecución de código no intencionada. Un atacante con privilegios elevados podría explotar esta vulnerabilidad para modificar prototipos de objetos, lo que afectaría el comportamiento principal de JavaScript, provocaría fallos en la aplicación o comportamientos inesperados, o incluso introduciría vulnerabilidades de seguridad adicionales según la arquitectura de la aplicación. Esta vulnerabilidad se corrigió en la versión 1.20.1.
-
Vulnerabilidad en http-proxy-middleware (CVE-2025-32996)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 21/10/2025
En http-proxy-middleware anterior a 2.0.8 y 3.x anterior a 3.0.4, writeBody se puede llamar dos veces porque no se utiliza "else if".
-
Vulnerabilidad en http-proxy-middleware (CVE-2025-32997)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 21/10/2025
En http-proxy-middleware anterior a 2.0.9 y 3.x anterior a 3.0.5, fixRequestBody continúa incluso si bodyParser ha fallado.
-
Vulnerabilidad en PeerTube (CVE-2025-32944)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 21/10/2025
La vulnerabilidad permite que cualquier usuario autenticado provoque el bloqueo persistente del servidor de PeerTube. Si la importación de usuarios está habilitada (configuración predeterminada), cualquier usuario registrado puede cargar un archivo para su importación. El código utiliza la librería yauzl para leer el archivo. Si la librería yauzl encuentra un nombre de archivo considerado ilegal, genera una excepción que PeerTube no detecta, lo que provoca un bloqueo que se repite indefinidamente al iniciar.
-
Vulnerabilidad en PeerTube (CVE-2025-32945)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 21/10/2025
La vulnerabilidad permite que un usuario existente añada listas de reproducción al canal de otro usuario mediante la API REST de PeerTube. El código vulnerable establece que el propietario de la nueva lista de reproducción sea el usuario que realizó la solicitud y, a continuación, establece el canal asociado con el ID de canal proporcionado por la solicitud, sin comprobar si pertenece al usuario.
-
Vulnerabilidad en ActivityPub (CVE-2025-32946)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 21/10/2025
Esta vulnerabilidad permite a cualquier atacante añadir listas de reproducción al canal de otro usuario mediante el protocolo ActivityPub. El código vulnerable establece que el propietario de la nueva lista de reproducción sea el usuario que realizó la solicitud y, a continuación, establece el canal asociado con el ID de canal proporcionado por la solicitud, sin comprobar si pertenece al usuario.
-
Vulnerabilidad en PeerTube (CVE-2025-32947)
Severidad: ALTA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 21/10/2025
Esta vulnerabilidad permite a cualquier atacante hacer que el servidor PeerTube deje de responder a las solicitudes debido a un bucle infinito en el endpoint de "bandeja de entrada" cuando recibe actividades de ActivityPub manipuladas.
-
Vulnerabilidad en PeerTube (CVE-2025-32948)
Severidad: ALTA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 21/10/2025
La vulnerabilidad permite a cualquier atacante provocar la interrupción del funcionamiento del servidor de PeerTube o, en casos especiales, enviar solicitudes a URL arbitrarias (SSRF ciega). Los atacantes pueden enviar actividades de ActivityPub al endpoint de "inbox" de PeerTube. Al abusar de la función "Create Activity", es posible crear listas de reproducción manipuladas que provocarán una denegación de servicio o una SSRF ciega controlada por el atacante.
-
Vulnerabilidad en Zip Bomb (CVE-2025-32949)
Severidad: MEDIA
Fecha de publicación: 15/04/2025
Fecha de última actualización: 21/10/2025
Esta vulnerabilidad permite que cualquier usuario autenticado haga que el servidor consuma grandes cantidades de espacio en disco al extraer Zip Bomb. Si la importación de usuarios está habilitada (configuración predeterminada), cualquier usuario registrado puede cargar un archivo para su importación. El código utiliza la librería yauzl para leer el archivo. Esta librería no contiene ningún mecanismo para detectar o prevenir la extracción de Zip Bomb (https://en.wikipedia.org/wiki/Zip_bomb). Por lo tanto, al usar la función de importación de usuarios con Zip Bomb, PeerTube intentará extraer el archivo, lo que agotará el espacio en disco.
-
Vulnerabilidad en fig2dev (CVE-2025-46397)
Severidad: MEDIA
Fecha de publicación: 23/04/2025
Fecha de última actualización: 21/10/2025
El desbordamiento de pila en fig2dev en la versión 3.2.9a permite a un atacante la posible ejecución de código mediante la manipulación de entrada local mediante la función bezier_spline.
-
Vulnerabilidad en jeeweb-mybatis-springboot v0.0.1.RELEASE (CVE-2025-45618)
Severidad: MEDIA
Fecha de publicación: 05/05/2025
Fecha de última actualización: 21/10/2025
El control de acceso incorrecto en el componente /admin/sys/datasource/ajaxList de jeeweb-mybatis-springboot v0.0.1.RELEASE permite a los atacantes acceder a información confidencial a través de un payload manipulado.
-
Vulnerabilidad en JRuby-OpenSSL (CVE-2025-46551)
Severidad: MEDIA
Fecha de publicación: 07/05/2025
Fecha de última actualización: 21/10/2025
JRuby-OpenSSL es una gema complementaria para JRuby que emula la librería nativa Ruby OpenSSL. A partir de la versión 0.12.1 de JRuby-OpenSSL y anteriores a la 0.15.4 (correspondientes a las versiones de JRuby 9.3.4.0 anteriores a la 9.4.12.1 y 10.0.0.0 anteriores a la 10.0.0.1), al verificar certificados SSL, JRuby-OpenSSL no verifica que el nombre de host presentado en el certificado coincida con el del usuario al que intenta conectarse. Esto significa que un intermediario podría presentar cualquier certificado válido para un dominio completamente diferente al suyo, y JRuby lo aceptaría. Cualquiera que use JRuby para realizar solicitudes a API externas o para rastrear datos web que dependan de https para conectarse de forma segura. La versión 0.15.4 de JRuby-OpenSSL contiene una solución para este problema. Esta corrección está incluida en las versiones 10.0.0.1 y 9.4.12.1 de JRuby.
-
Vulnerabilidad en PointCloudLibrary (CVE-2025-4638)
Severidad: CRÍTICA
Fecha de publicación: 14/05/2025
Fecha de última actualización: 21/10/2025
Existe una vulnerabilidad en el componente inftrees.c de la librería zlib, que se incluye en PointCloudLibrary (PCL). Este problema podría permitir que atacantes dependientes del contexto provoquen un comportamiento indefinido al explotar una aritmética de punteros incorrecta. Desde la versión 1.14.0, PCL utiliza de forma predeterminada una instalación de zlib desde el sistema, a menos que el usuario configure WITH_SYSTEM_ZLIB=FALSE. Por lo tanto, esta posible vulnerabilidad solo es relevante si la versión de PCL es anterior a la 1.14.0 o si el usuario solicita específicamente no usar la zlib del sistema.
-
Vulnerabilidad en imaginationtech (CVE-2025-46710)
Severidad: MEDIA
Fecha de publicación: 16/06/2025
Fecha de última actualización: 21/10/2025
Posibles excepciones del kernel causadas por la lectura y escritura de datos del montón del kernel después de la liberación.
-
Vulnerabilidad en GPU DRIVER (CVE-2025-46707)
Severidad: MEDIA
Fecha de publicación: 27/06/2025
Fecha de última actualización: 21/10/2025
El software instalado y ejecutándose dentro de una máquina virtual invitada puede anular el estado del firmware y obtener acceso a la GPU.
-
Vulnerabilidad en GPU DRIVER (CVE-2025-46708)
Severidad: MEDIA
Fecha de publicación: 27/06/2025
Fecha de última actualización: 21/10/2025
El software instalado y ejecutándose dentro de una máquina virtual invitada puede realizar llamadas de sistema de GPU incorrectas para evitar que otros invitados ejecuten trabajos en la GPU.
-
Vulnerabilidad en tarteaucitron.js (CVE-2025-48939)
Severidad: MEDIA
Fecha de publicación: 03/07/2025
Fecha de última actualización: 21/10/2025
tarteaucitron.js es un banner de cookies compatible y accesible. Antes de la versión 1.22.0, se identificó una vulnerabilidad en tarteaucitron.js donde se accedía a document.currentScript sin verificar que hiciera referencia a un elemento
-
Vulnerabilidad en Tenda TX3 16.03.13.11_multi_TDE01 (CVE-2025-8958)
Severidad: ALTA
Fecha de publicación: 14/08/2025
Fecha de última actualización: 21/10/2025
Se identificó una vulnerabilidad en Tenda TX3 16.03.13.11_multi_TDE01. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo /goform/fast_setting_wifi_set. La manipulación del argumento ssid provoca un desbordamiento del búfer basado en la pila. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.
-
Vulnerabilidad en jonkastonka (CVE-2025-51529)
Severidad: MEDIA
Fecha de publicación: 19/08/2025
Fecha de última actualización: 21/10/2025
El control de acceso incorrecto en la funcionalidad del endpoint AJAX en el complemento de política de seguridad de contenido y cookies de jonkastonka hasta la versión 2.29 permite a atacantes remotos provocar una denegación de servicio (agotamiento de los recursos del servidor de base de datos) a través de operaciones de escritura de base de datos ilimitadas en el endpoint wp_ajax_nopriv_cacsp_insert_consent_data.
-
Vulnerabilidad en Reolink Smart 2K+ Plug-in Wi-Fi Video Doorbell with Chime (CVE-2025-55630)
Severidad: ALTA
Fecha de publicación: 22/08/2025
Fecha de última actualización: 21/10/2025
Una discrepancia en el mensaje de error devuelto por la función de inicio de sesión del Reolink Smart 2K+ Plug-in Wi-Fi Video Doorbell with Chime - firmware v3.0.0.4662_2503122283 al ingresar un nombre de usuario y una contraseña incorrectos permite a los atacantes enumerar las cuentas existentes.
-
Vulnerabilidad en Reolink Smart 2K+ Plug-in Wi-Fi Video Doorbell with Chime (CVE-2025-55634)
Severidad: ALTA
Fecha de publicación: 22/08/2025
Fecha de última actualización: 21/10/2025
El control de acceso incorrecto en la configuración del servidor RTMP de Reolink Smart 2K+ Plug-in Wi-Fi Video Doorbell with Chime - firmware v3.0.0.4662_2503122283 permite que atacantes no autorizados provoquen una denegación de servicio (DoS) al iniciar una gran cantidad de envíos simultáneos de transmisiones basadas en ffmpeg.
-
Vulnerabilidad en Reolink Smart 2K+ Plug-in Wi-Fi Video Doorbell with Chime (CVE-2025-55637)
Severidad: CRÍTICA
Fecha de publicación: 22/08/2025
Fecha de última actualización: 21/10/2025
Se descubrió que Reolink Smart 2K+ Plug-in Wi-Fi Video Doorbell with Chime - firmware v3.0.0.4662_2503122283 contenía una vulnerabilidad de inyección de comandos a través de la función setddns_pip_system().
-
Vulnerabilidad en System PDV v1.0 (CVE-2025-45968)
Severidad: CRÍTICA
Fecha de publicación: 25/08/2025
Fecha de última actualización: 21/10/2025
Un problema en System PDV v1.0 permite a un atacante remoto obtener información confidencial mediante el parámetro hash de una URL. La aplicación contiene una vulnerabilidad de Referencia Directa a Objetos Insegura (IDOR), que se produce debido a la falta de comprobaciones de autorización adecuadas al acceder a los objetos referenciados por este parámetro. Esto permite el acceso directo a los datos o recursos internos de otros usuarios sin el permiso correspondiente. La explotación exitosa de esta vulnerabilidad puede resultar en la exposición de información confidencial.



