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 vuelidate (CVE-2021-3794)
Severidad: ALTA
Fecha de publicación: 15/09/2021
Fecha de última actualización: 24/09/2025
vuelidate es vulnerable a una Complejidad de Expresiones Regulares Ineficientes
-
Vulnerabilidad en Saphira Saphira Connect (CVE-2023-4662)
Severidad: CRÍTICA
Fecha de publicación: 15/09/2023
Fecha de última actualización: 24/09/2025
Vulnerabilidad de Ejecución con Privilegios Innecesarios en Saphira Saphira Connect permite la Inclusión de Código Remota. Este problema afecta a Saphira Connect: antes de la versión 9.
-
Vulnerabilidad en Saphira Saphira Connect (CVE-2023-4664)
Severidad: ALTA
Fecha de publicación: 15/09/2023
Fecha de última actualización: 24/09/2025
Vulnerabilidad de Permisos Predeterminados Incorrectos en Saphira Saphira Connect permite la Escalación de Privilegios. Este problema afecta a Saphira Connect: antes de la versión 9.
-
Vulnerabilidad en Saphira Saphira Connect (CVE-2023-4665)
Severidad: ALTA
Fecha de publicación: 15/09/2023
Fecha de última actualización: 24/09/2025
Vulnerabilidad de ejecución incorrecta de permisos asignados en Saphira Saphira Connect permite la Escalación de Privilegios. Este problema afecta a Saphira Connect: antes de la versión 9.
-
Vulnerabilidad en Saphira Saphira Connect (CVE-2023-4661)
Severidad: CRÍTICA
Fecha de publicación: 15/09/2023
Fecha de última actualización: 24/09/2025
Neutralización Inadecuada de Elementos Especiales utilizados en una vulnerabilidad de comando SQL ("Inyección SQL") en Saphira Saphira Connect permite la inyección SQL. Este problema afecta a Saphira Connect: antes de la versión 9.
-
Vulnerabilidad en Saphira Saphira Connect (CVE-2023-4663)
Severidad: MEDIA
Fecha de publicación: 15/09/2023
Fecha de última actualización: 24/09/2025
Neutralización inadecuada de etiquetas HTML relacionadas con secuencias de comandos en una vulnerabilidad de página web (XSS básico) en Saphira Saphira Connect permite Cross-Site Scripting (XSS) reflejado. Este problema afecta a Saphira Connect: antes de la versión 9.
-
Vulnerabilidad en QuFirewall (CVE-2023-41290)
Severidad: MEDIA
Fecha de publicación: 26/04/2024
Fecha de última actualización: 24/09/2025
Se ha informado que una vulnerabilidad de path traversal afecta a QuFirewall. Si se explota, la vulnerabilidad podría permitir a los administradores autenticados leer el contenido de archivos inesperados y exponer datos confidenciales a través de una red. Ya hemos solucionado la vulnerabilidad en la siguiente versión: QuFirewall 2.4.1 (2024/02/01) y posteriores
-
Vulnerabilidad en QuFirewall (CVE-2023-41291)
Severidad: MEDIA
Fecha de publicación: 26/04/2024
Fecha de última actualización: 24/09/2025
Se ha informado que una vulnerabilidad de path traversal afecta a QuFirewall. Si se explota, la vulnerabilidad podría permitir a los administradores autenticados leer el contenido de archivos inesperados y exponer datos confidenciales a través de una red. Ya hemos solucionado la vulnerabilidad en la siguiente versión: QuFirewall 2.4.1 (2024/02/01) y posteriores
-
Vulnerabilidad en kernel de Linux (CVE-2024-35832)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcachefs: kvfree bch_fs::snapshots en bch2_fs_snapshots_exit bch_fs::snapshots es asignado por kvzalloc en __snapshot_t_mut. Debería ser liberado por kvfree, no por kfree. O desmontar activará: [406.829178] ERROR: no se puede manejar el error de página para la dirección: ffffe7b487148008 [406.830676] #PF: acceso de lectura del supervisor en modo kernel [406.831643] #PF: error_code(0x0000) - página no presente [406.832487] PGD 0 P4D 0 [ 406.832898 ] Vaya: 0000 [#1] PREEMPT SMP PTI [ 406.833512 ] CPU: 2 PID: 1754 Comunicaciones: desmontar Kdump: cargado Contaminado: G OE 6.7.0-rc7-custom+ #90 [ 406.834746 ] Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 01/04/2014 [ 406.835796 ] RIP: 0010:kfree+0x62/0x140 [ 406.836197 ] Código: 80 48 01 d8 0f 82 e9 00 00 00 48 c7 c2 00 00 00 80 48 2b 15 78 9f 1f 01 48 01 d0 48 c1 e8 0c 48 c1 e0 06 48 03 05 56 9f 1f 01 <48> 8b 50 08 48 89 c7 f6 01 0f 85b0 00 00 00 66 90 48 8b 07 f6 [ 406.837810 ] RSP: 0018:ffffb9d641607e48 EFLAGS: 00010286 [ 406.838213 ] RAX: ffffe7b487148000 RBX: 0000 RCX: ffffb9d641607dc4 [ 406.838738 ] RDX: 000065bb00000000 RSI: ffffffffc0d88b84 RDI: ffffb9d645200000 [ 406.839217 ] RBP: ffff9a4625d00068 R08: 0000000000000001 R09: 00000000000000001 [ 406.839650 ] R10: 0000000000000001 R11: 000000000000001f R12: ffff9a4625d4da80 [ 406.8 40055 ] R13: ffff9a4625d00000 R14: ffffffffc0e2eb20 R15: 0000000000000000 [ 406.840451 ] FS: 00007f0a264ffb80(0000) GS:ffff9a4e2d500000(0000) knlGS:0000000000000000 [ 406.840851 ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 406.841125 ] CR2: ffffe7b487148008 CR3: 000000018c4d2000 CR4: 00000000000006f0 [ 406.841 464 ] Seguimiento de llamadas: [ 406.841583 ] [ 406.841682 ] ? __die+0x1f/0x70 [ 406.841828 ] ? page_fault_oops+0x159/0x470 [406.842014]? fixup_exception+0x22/0x310 [406.842198]? exc_page_fault+0x1ed/0x200 [406.842382]? asm_exc_page_fault+0x22/0x30 [406.842574]? bch2_fs_release+0x54/0x280 [bcachefs] [406.842842]? kfree+0x62/0x140 [ 406.842988 ] ? kfree+0x104/0x140 [ 406.843138 ] bch2_fs_release+0x54/0x280 [bcachefs] [ 406.843390 ] kobject_put+0xb7/0x170 [ 406.843552 ] desactivar_locked_super+0x2f/0xa0 [ 406.843 756 ] cleanup_mnt+0xba/0x150 [ 406.843917 ] task_work_run+0x59/0xa0 [ 406.844083 ] exit_to_user_mode_prepare+0x197/0x1a0 [ 406.844302 ] syscall_exit_to_user_mode+0x16/0x40 [ 406.844510 ] do_syscall_64+0x4e/0xf0 [ 406.844675 entrada_SYSCALL_64_after_hwframe +0x6e/0x76 [ 406.844907 ] RIP: 0033:0x7f0a2664e4fb
-
Vulnerabilidad en kernel de Linux (CVE-2024-35839)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: bridge: reemplace physindev con physinif en nf_bridge_info. Se puede agregar un skb a neigh->arp_queue mientras se espera una respuesta de arp. Donde skb->dev del skb original puede ser diferente al neigh->dev de neigh. Por ejemplo, en el caso de unir un skb designado de un veth a otro, el skb se agregaría a un vecino->arp_queue del puente. Como skb->dev se puede restablecer a nf_bridge->physindev y usarse, y como no existe un mecanismo explícito que impida que este physindev se libere bajo nuestra responsabilidad (por ejemplo, neigh_flush_dev no limpia skbs de la cola vecina de diferentes dispositivos), podemos crashear, por ejemplo, en esta pila: arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finish Usemos ifindex simple en lugar de enlace net_device. Para echar un vistazo al net_device original usaremos dev_get_by_index_rcu(). Por lo tanto, o obtenemos el dispositivo y podemos usarlo con seguridad o no lo obtenemos y eliminamos skb.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35840)
Severidad: MEDIA
Fecha de publicación: 17/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: use OPTION_MPTCP_MPJ_SYNACK en subflow_finish_connect() subflow_finish_connect() usa cuatro campos (backup, join_id, thmac, none) que pueden contener basura a menos que se haya configurado OPTION_MPTCP_MPJ_SYNACK en mptcp_parse_option()
-
Vulnerabilidad en kernel de Linux (CVE-2024-35872)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/secretmem: corrige el éxito rápido de GUP en folios secretmem folio_is_secretmem() actualmente depende de que los folios secretmem sean folios LRU, para guardar algunos ciclos. Sin embargo, las publicaciones pueden residir en un lote de publicaciones sin el indicador LRU establecido o tener su indicador LRU borrado temporalmente. En consecuencia, la bandera LRU no es fiable para este fin. En particular, este es el caso cuando secretmem_fault() asigna una página nueva y llama a filemap_add_folio()->folio_add_lru(). La publicación podría agregarse al lote de publicaciones por CPU y no se establecerá el indicador LRU hasta que el lote se drene usando, por ejemplo, lru_add_drain(). En consecuencia, es posible que folio_is_secretmem() no detecte folios secretmem y GUP-fast puede lograr capturar un folio secretmem, bloqueando el kernel cuando más tarde intentemos leer/escribir en el folio, porque el folio no se ha desasignado del mapa directo. Solucionarlo eliminando ese cheque poco confiable.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35873)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: corrige la restauración del estado del vector en rt_sigreturn() La especificación del vector RISC-V indica en el "Apéndice D: Llamando convención por el estado del vector" [1] que "La ejecución de una llamada al sistema causa todos los registros vectoriales guardados por la persona que llama (v0-v31, vl, vtype) y vstart quedarán sin especificar". En el kernel RISC-V, esto se denomina "descartar el vstate". Al regresar de un controlador de señales a través de la llamada al sistema rt_sigreturn(), también se realiza el descarte de vectores. Sin embargo, esto no es un problema ya que el estado del vector debe restaurarse desde el contexto de señal y, por lo tanto, no preocuparse por el descarte del vector. El "estado en vivo" es el registro vectorial real en el contexto de ejecución, y el "vstate" es el estado vectorial de la tarea. Un estado en vivo sucio significa que el vstate y el estado en vivo no están sincronizados. Cuando se introdujo user_from_copy() vectorizado, se coló un error en el código de restauración, relacionado con el descarte del estado activo. Un ejemplo de cuando esto sale mal: 1. Una aplicación de usuario está ejecutando código vectorial. 2. La aplicación recibe una señal y se ingresa el controlador de señales. 3. La aplicación regresa del controlador de señales, utilizando la llamada al sistema rt_sigreturn(). 4. El estado del vector en vivo se descarta al ingresar a rt_sigreturn() y el estado en vivo se marca como "sucio", lo que indica que el estado en vivo debe sincronizarse con el vstate actual. 5. rt_sigreturn() restaura el vstate, excepto los registros Vector, desde el sigcontext 6. rt_sigreturn() restaura los registros Vector, desde el sigcontext, y ahora se usa el user_from_copy() vectorizado. El estado activo sucio del descarte se guarda en el vstate, lo que hace que el vstate sea corrupto. 7. rt_sigreturn() regresa a la aplicación, que falla debido a un vstate dañado. Tenga en cuenta que el usuario_from_copy() vectorizado se invoca dependiendo del valor de CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD. El valor predeterminado es 768, lo que significa que vlen debe ser mayor que 128b para que se active este error. La solución es simplemente marcar el estado activo como no sucio/limpio antes de realizar la restauración de vstate.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35875)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/coco: requiere inicialización de RNG con RDRAND en sistemas CoCo. Hay pocos usos de CoCo que no dependan de una criptografía funcional y, por lo tanto, de un RNG funcional. Desafortunadamente, el modelo de amenaza CoCo significa que no se puede confiar en el host de la VM y puede trabajar activamente contra los invitados para extraer secretos o manipular los cálculos. Dado que un host malicioso puede modificar u observar casi todas las entradas de los invitados, la única fuente de entropía restante para los invitados CoCo es RDRAND. Si RDRAND se rompe (debido a una falla del hardware de la CPU), el RNG en su conjunto debe continuar recopilando entropía de otras fuentes, pero como no hay otras fuentes en CoCo, esto es catastrófico. Esto es principalmente una preocupación en el momento del arranque cuando se siembra inicialmente el RNG, ya que después de eso las consecuencias de un RDRAND roto son mucho más teóricas. Entonces, intente en el arranque inicializar el RNG usando 256 bits de salida RDRAND. Si esto falla, entra en pánico(). Esto también se activará si el sistema se inicia sin RDRAND, ya que RDRAND es esencial para un inicio CoCo seguro. Agregue esto deliberadamente para que sea "solo una característica del controlador CoCo x86" y no parte del RNG en sí. Muchos controladores de dispositivos y plataformas desean contribuir con algo al RNG, y add_device_randomness() está diseñado específicamente para este propósito. Cualquier conductor puede llamarlo con datos semilla de cualquier calidad, o incluso calidad basura, y solo puede mejorar la calidad del RNG o no tener ningún efecto, pero nunca puede empeorarlo. En lugar de intentar construir algo en el núcleo del RNG, considere el problema particular de CoCo solo como un problema de CoCo y, por lo tanto, sepárelo todo en código de controlador (bueno, arco/plataforma).
-
Vulnerabilidad en kernel de Linux (CVE-2024-35880)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/kbuf: mantiene la referencia io_buffer_list sobre mmap. Si buscamos el kbuf, nos aseguramos de que no se cancele el registro hasta que hayamos terminado con él. Como estamos dentro de mmap, no podemos usar de forma segura el bloqueo io_uring. Confíe en el hecho de que ahora podemos buscar la lista de búfer en RCU y obtener una referencia a ella, evitando que se cancele el registro hasta que hayamos terminado. La búsqueda devuelve io_buffer_list directamente con su referencia.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35890)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gro: corrige la transferencia de propiedad. Si los paquetes se agrupan con fraglist, es posible que se segmenten más adelante y continúen su viaje en la pila. En skb_segment_list esos skbs se pueden reutilizar tal cual. Esto es un problema ya que su destructor se eliminó en skb_gro_receive_list pero no la referencia a su socket, y luego no pueden quedar huérfanos. Solucione este problema eliminando también la referencia al socket. Por ejemplo, esto se podría observar, ¡BUG del kernel en include/linux/skbuff.h:3131! (skb_orphan) RIP: 0010:ip6_rcv_core+0x11bc/0x19a0 Seguimiento de llamadas: ipv6_list_rcv+0x250/0x3f0 __netif_receive_skb_list_core+0x49d/0x8f0 netif_receive_skb_list_internal+0x634/0xd40 napi_complete_done+0x1 d2/0x7d0 gro_cell_poll+0x118/0x1f0 Se encuentra una construcción similar en skb_gro_receive, aplique el mismo cambio allí.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35903)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/bpf: corrige la IP después de emitir la contabilidad de profundidad de llamadas. Ajuste la IP pasada a `emit_patch` para que calcule el desplazamiento correcto para la instrucción CALL si `x86_call_ Depth_emit_accounting` emite código. De lo contrario, nos saltaremos algunas instrucciones y lo más probable es que fallemos.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35908)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tls: obtenga referencia de psock después de tomar rxlock para evitar fugas. Al inicio de tls_sw_recvmsg, tomamos una referencia en psock y luego llamamos a tls_rx_reader_lock. Si eso falla, volvemos directamente sin liberar la referencia. En lugar de agregar una nueva etiqueta, simplemente tome la referencia después de que el bloqueo se haya realizado correctamente, ya que no la necesitamos antes.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35909)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net: wwan: t7xx: Accesos divididos de 64 bits para solucionar problemas de alineación Algunos de los registros están alineados en un límite de 32 bits, provocando fallos de alineación en plataformas de 64 bits. No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffffffc084a1d004 Información de cancelación de memoria: ESR = 0x0000000096000061 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alineación falla Información de cancelación de datos: ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 tabla de intercambio: 4k páginas, VA de 39 bits, pgdp=0000000046ad6000 [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711 Error interno: Vaya: 0000000096000061 [#1] Módulos SMP vinculados en: mtk_t7xx(+) qcserial pppoe ppp_async opción nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 n ft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm c_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv md5 des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys CPU confiable: 3 PID: 5266 Comm: kworker/u9:1 ted: GO 6.6.22 #0 Nombre del hardware: Bananapi BPI -R4 (DT) Cola de trabajo: md_hk_wq t7xx_fsm_uninit [mtk_t7xx] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx] lr: _cldma_start+0xac/0x13c [mtk_t7xx] sp: ffffffc085d63d30 x29: ffffffc085d63d30 x28: 0000000000000000 x27: 00000000000000000 x26: 0000000000000000 x25: ffffff80c804f2c 0 x24: ffffff80ca196c05 x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128 x20: 00000000000000001 x19: ffffff80c814b080 x18: 00000000014 x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68 x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001 x11: 00000000000000000 x10: 0000000000000000 x9: 000 0000000000000 x8: ffffff80ca1ef6b4 x7: ffffff80c814b818 x6: 0000000000000018 x5: 0000000000000870 x4: 0000000000000000 x3: 0000000000000000 0 x2: 000000010a947000 x1: ffffffc084a1d004 x0: ffffffc084a1d004 Rastreo de llamadas: t7xx_cldma_hw_set_start_addr +0x1c/0x3c [mtk_t7xx] t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx] Process_one_work+0x154/0x2a0 Workers_thread+0x2ac/0x488 kthread+0xe0/0xec ret_from_fork+0x10/0x20 Código: f9400800 9 1001000 8b214001 d50332bf (f9000022) ---[ final de seguimiento 0000000000000000 ]--- La inclusión de io-64-nonatomic-lo-hi.h indica que todos los accesos de 64 bits pueden ser reemplazados por pares de accesos no atómicos de 32 bits. Corrija la alineación obligando a que todos los accesos sean de 32 bits en plataformas de 64 bits.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35913)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: elige la versión de SESSION_PROTECTION_NOTIF Cuando queremos saber si debemos buscar el mac_id o el link_id en la estructura iwl_mvm_session_prot_notif, debemos mirar la versión de SESSION_PROTECTION_NOTIF . Esto provoca ADVERTENCIAS: ADVERTENCIA: CPU: 0 PID: 11403 en drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:959 iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] RIP:iwl_mvm_rx_session_protect_notif+0x 333/0x340 [ iwlmvm] Código: 00 49 c7 84 24 48 07 00 00 00 00 00 00 41 c6 84 24 78 07 00 00 ff 4c 89 f7 e8 e9 71 54 d9 e9 7d fd ff ff 0f 0b e9 23 fe ff ff <0f> 0b e9 1c fe ff ff 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffb4bb00003d40 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff9ae63a 361000 RCX: ffff9ae4a98b60d4 RDX: ffff9ae4588499c0 RSI: 0000000000000305 RDI: ffff9ae4a98b6358 RBP: ffffb4bb00003d68 R08 : 0000000000000003 R09: 0000000000000010 R10: ffffb4bb00003d00 R11: 000000000000000f R12: ffff9ae441399050 R13: ffff9ae4761329e8 R14: 000000000001 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9ae7af400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 0000000080050033 CR2: 000055fb75680018 CR3: 00000003dae32006 CR4: 0000000000f70ef0 PKRU: 55555554 Seguimiento de llamadas: ? show_regs+0x69/0x80? __advertir+0x8d/0x150 ? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] ? report_bug+0x196/0x1c0? handle_bug+0x45/0x80? exc_invalid_op+0x1c/0xb0? asm_exc_invalid_op+0x1f/0x30? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] iwl_mvm_rx_common+0x115/0x340 [iwlmvm] iwl_mvm_rx_mq+0xa6/0x100 [iwlmvm] iwl_pcie_rx_handle+0x263/0xa10 wifi] iwl_pcie_napi_poll_msix+0x32/0xd0 [iwlwifi]
-
Vulnerabilidad en kernel de Linux (CVE-2024-35924)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: typec: ucsi: Limitar el tamaño de lectura en v1.2 Entre UCSI 1.2 y UCSI 2.0, el tamaño de la región MESSAGE_IN se incrementó de 16 a 256. Para evitar el desbordamiento lecturas para sistemas más antiguos, agregue un mecanismo para usar la versión de lectura UCSI para truncar los tamaños de lectura en UCSI v1.2.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35927)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: Verifique el sondeo de salida inicializado antes de deshabilitarlo. En drm_kms_helper_poll_disable() verifique si el soporte de sondeo de salida está inicializado antes de deshabilitar el sondeo. Si no, marca esto como una advertencia. Además, en las llamadas drm_mode_config_helper_suspend() y drm_mode_config_helper_resume(), que son los llamadores de estas funciones, evite invocarlas si el sondeo no está inicializado. Para controladores como hyperv-drm, que no inicializan el sondeo del conector, si se llama a suspender sin esta verificación, se produce una falla de suspensión con la siguiente pila [770.719392] Congelando las tareas restantes que se pueden congelar... (transcurridos 0,001 segundos) realizadas. [770.720592] printk: Suspensión de consola(s) (use no_console_suspend para depurar) [770.948823] ------------[ cortar aquí ]------------ [ 770.948824] ADVERTENCIA: CPU: 1 PID: 17197 en kernel/workqueue.c:3162 __flush_work.isra.0+0x212/0x230 [770.948831] Módulos vinculados en: rfkill nft_counter xt_conntrack xt_owner udf nft_compat crc_itu_t nft_fib_inet v4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink vfat fat mlx5_ib ib_uverbs ib_core mlx5_core intel_rapl_msr intel_rapl_common kvm_amd ccp mlxfw kvm psample hyperv_drm tls drm_shmem_helper drm_kms _helper irqbypass pcspkr syscopyarea sysfillrect sysimgblt hv_balloon hv_utils joydev drm fuse xfs libcrc32c pci_hyperv pci_hyperv_intf sr_mod sd_mod cdrom t10_pi sg hv_storvsc scsi_transport_fc hv_netvsc serio_raw hyperv_keyboard hid_hyperv crct1 0dif_pclmul crc32_pclmul crc32c_intel hv_vmbus ghash_clmulni_intel dm_mirror dm_region_hash dm_log dm_mod [ 770.948863] CPU: 1 PID: 17197 Comm: systemd-sleep No contaminado 5.14.0-362.2.1.el9_3.x86_64 #1 [ 770.9488 65] Nombre del hardware: Máquina virtual/Máquina virtual de Microsoft Corporation, BIOS Hyper-V UEFI Versión v4.1 09/05/2022 [ 770.948866] RIP: 0010:__flush_work.isra.0+0x212/0x230 [ 770.948869] Código: 8b 4d 00 4c 8b 45 08 89 ca 48 c1 e9 04 83 e2 08 83 e1 0f 83 ca 02 89 c8 48 0f ba 6d 00 03 e9 25 ff ff ff 0f 0b e9 4e ff ff ff <0f> 0b 45 31 ed e9 44 ff ff ff e8 8f 89 b2 00 66 66 2e 0f 1f 4 00 [ 770.948870] RSP: 0018:ffffaf4ac213fb10 EFLAGS: 00010246 [ 770.948871] RAX: 00000000000000000 RBX: 0000000000000000 RCX: ffffffff8c992857 [ 770.948872] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff9aad82b00330 [ 770.948873] RBP: ffff9aad82b00330 R08: 0000000000000000 R09: ffff9aad87ee3d10 [ 770.948874 ] R10: 0000000000000200 R11: 00000000000000000 R12: ffff9aad82b00330 [ 770.948874] R13: 00000000000000001 R14: 0000000000000000 R15: 000000000000001 [ 770.948875] FS: 00007ff1b2f6bb40(0000) GS:ffff9aaf37d00000(0000) knlGS:00000000000000000 [ 770.948878] CS: 0010 DS: 0000 : 0000 CR0: 0000000080050033 [ 770.948878] CR2: 0000555f345cb666 CR3: 00000001462dc005 CR4: 0000000000370ee0 [ 770.948879] Seguimiento de llamadas: [ 770.9488 80] [770.948881] ? show_trace_log_lvl+0x1c4/0x2df [770.948884]? show_trace_log_lvl+0x1c4/0x2df [770.948886]? __cancel_work_timer+0x103/0x190 [770.948887]? __flush_work.isra.0+0x212/0x230 [770.948889]? __advertir+0x81/0x110 [ 770.948891] ? __flush_work.isra.0+0x212/0x230 [770.948892]? report_bug+0x10a/0x140 [770.948895]? handle_bug+0x3c/0x70 [770.948898]? exc_invalid_op+0x14/0x70 [770.948899]? asm_exc_invalid_op+0x16/0x20 [770.948903]? __flush_work.isra.0+0x212/0x230 [ 770.948905] __cancel_work_timer+0x103/0x190 [ 770.948907] ? _raw_spin_unlock_irqrestore+0xa/0x30 [ 770.948910] drm_kms_helper_poll_disable+0x1e/0x40 [drm_kms_helper] [ 770.948923] drm_mode_config_helper_suspend+0x1c/0x80 [drm_kms_helper] [ 770.94 8933] ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus] [ 770.948942] hyperv_vmbus_suspend+0x17/0x40 [hyperv_drm] [ 770.948944] ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus] [ 770.948951] dpm_run_callback+0x4c/0x140 [ 770.948954] __device_suspend_noir ---truncated---
-
Vulnerabilidad en kernel de Linux (CVE-2024-35931)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: Omitir el restablecimiento de la ranura de error PCI durante la recuperación de RAS Por qué: El restablecimiento de la ranura de error PCI puede activarse después de inyectar ue en UMC varias veces, lo que provocó que el sistema se bloqueara. [ 557.371857] amdgpu 0000:af:00.0: amdgpu: el reinicio de la GPU se realizó correctamente, intentando reanudar [ 557.373718] [drm] PCIE GART de 512M habilitado. [ 557.373722] [drm] PTB ubicado en 0x0000031FED700000 [ 557.373788] [drm] ¡La VRAM se pierde debido al reinicio de la GPU! [ 557.373789] [drm] PSP se está reanudando... [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Estado del dispositivo = 1 pci_status: 0. Salir, resultado = 3, es necesario restablecer [ 557.547067] [drm] Error de PCI: devolución de llamada detectada , estado(1)!! [ 557.547069] [drm] Aún no hay soporte para XGMI hive... [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Estado del dispositivo = 1 pci_status: 0. Ingrese [ 557.607763] mlx5_core 0000:55:00.0: espere el valor del contador vital 0x16b5b después de 1 iteración [557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Estado del dispositivo = 1 pci_status: 1. Salir, err = 0, resultado = 5, recuperado [557.610492] [drm] Error de PCI: ¡devolución de llamada de restablecimiento de ranura! ... [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: ¡El reinicio de GPU (2) se realizó correctamente! [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: ¡El reinicio de GPU (2) se realizó correctamente! [ 560.689562] falla de protección general, probablemente para dirección no canónica 0x5f080b54534f611f: 0000 [#1] SMP NOPTI [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic # 101-Ubuntu [ 560.712057] Nombre de hardware: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 08/11/2023 [ 560.720959] Cola de trabajo: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu] [ 87] QEPD: 0010: amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.736891] Código: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00 [ 560.757967] RSP: 0018:ffa0000032e53d80 00010202 [560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0 [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010 [ 560.779867] BP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08 [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 000 [560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000 [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000 [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0 [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.835433] DR3: 0000000000000000 DR6: 00000000ffe07f0 DR7: 0000000000000400 [ 560.843444] PKRU: 55555554 [ 560.846480] Seguimiento de llamadas: [ 560.849225] [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea [560.856488]? show_trace_log_lvl+0x1d6/0x2ea [560.861379]? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.867778] ? show_regs.part.0+0x23/0x29 [560.872293]? __die_body.cold+0x8/0xd [ 560.876502] ? die_addr+0x3e/0x60 [ 560.880238] ? exc_general_protection+0x1c5/0x410 [560.885532]? asm_exc_general_protection+0x27/0x30 [560.891025]? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.904520] Process_one_work+0x228/0x3d0 Cómo: En la recuperación de RAS, el restablecimiento del modo 1 se emite desde RAS fatal manejo de errores y esperaba todos los nodos en una colmena que se van a restablecer. no es necesario emitir otro modo-1 durante este procedimiento.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35938)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath11k: reduce la longitud del búfer del canal MHI a 8 KB Actualmente, el campo buf_len de ath11k_mhi_config_qca6390 está asignado con 0, lo que hace que MHI use un tamaño predeterminado, 64 KB, para asignar búferes de canal. Es probable que esto falle en algunos escenarios donde la memoria del sistema está muy fragmentada y no se permite la compactación o recuperación de memoria. Hay un informe de error causado por esto: kworker/u32:45: error de asignación de página: orden:4, modo:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 19318 Comm: kworker/u32:45 No contaminado 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (inédito) 493b6d5b382c603654d7a81fc3c144d59a1dfceb Cola de trabajo: events_unbound async_run_entry_fn Seguimiento de llamadas: dump_stack_lvl+0x47/0x60 warn_alloc+0x13a/ 0x1b0? srso_alias_return_thunk+0x5/0xfbef5? __alloc_pages_direct_compact+0xab/0x210 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0 __alloc_pages+0x32d/0x350 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __kmalloc_large_node+0x72/0x110 __kmalloc+0x37c/0x480 ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a78 14] __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] device_for_each_child+0x5c/0xa0 ? __pfx_pci_pm_resume+0x10/0x10 ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e]? srso_alias_return_thunk+0x5/0xfbef5 ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec]? srso_alias_return_thunk+0x5/0xfbef5 dpm_run_callback+0x8c/0x1e0 device_resume+0x104/0x340? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x32/0x120 Process_one_work+0x168/0x330 Workers_thread+0x2f5/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe8/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 En realidad, esos buffers son utilizados solo por la comunicación QMI destino -> host. Y para WCN6855 y QCA6390, el tamaño de paquete más grande es inferior a 6 KB. Entonces cambie el campo buf_len a 8 KB, lo que da como resultado una asignación de orden 1 si el tamaño de la página es 4 KB. De esta manera, al menos podemos ahorrar algo de memoria y también disminuir la posibilidad de que se produzca un error en la asignación en esos escenarios. Probado en: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
-
Vulnerabilidad en kernel de Linux (CVE-2024-35939)
Severidad: ALTA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-direct: páginas filtradas en el fallo de dma_set_decrypted() En TDX es posible que el host que no es de confianza provoque que set_memory_encrypted() o set_memory_decrypted() falle de modo que se devuelva un error y la memoria resultante se comparte. Las personas que llaman deben tener cuidado al manejar estos errores para evitar devolver memoria descifrada (compartida) al asignador de páginas, lo que podría provocar problemas funcionales o de seguridad. DMA podría liberar páginas descifradas/compartidas si dma_set_decrypted() falla. Este debería ser un caso raro. En este caso, simplemente filtre las páginas en lugar de liberarlas.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35942)
Severidad: MEDIA
Fecha de publicación: 19/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Agregar reloj fdcc al dominio hdmimix Según i.MX8MP RM y HDMI ADD, el reloj fdcc es parte de la IP de verificación hdmi rx que debería no está habilitado para HDMI TX. Pero, en realidad, si el reloj está desactivado antes de la sonda HDMI/LCDIF, LCDIF no obtendrá el reloj de píxeles de HDMI PHY e imprimirá los registros de errores: [CRTC:39:crtc-2] Se agotó el tiempo de espera de vblank ADVERTENCIA: CPU: 2 PID: 9 en drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260 Agregue el reloj fdcc a los dominios de alimentación LCDIF y HDMI TX para solucionar el problema.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35951)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panfrost: corrige la ruta de error en panfrost_mmu_map_fault_addr() Asunto: [PATCH] drm/panfrost: corrige la ruta de error en panfrost_mmu_map_fault_addr() Si algunas páginas o la asignación de sgt fallaron, No deberíamos publicar la referencia de páginas que obtuvimos anteriormente, de lo contrario terminaremos con llamadas get/put_pages() desequilibradas. En su lugar, deberíamos dejar todo en su lugar y dejar que la función de liberación de BO se encargue de una limpieza adicional cuando se destruya el objeto, o dejar que el controlador de fallos lo intente nuevamente la próxima vez que se llame.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35961)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5: registre devlink primero bajo el bloqueo devlink. En caso de que el dispositivo tenga un error de firmware no fatal durante la prueba, el controlador informará el error al usuario a través de devlink. Esto activará un WARN_ON, ya que mlx5 llama a devlink_register() en último lugar. Para evitar WARN_ON[1], cambie mlx5 para invocar primero a devl_register() bajo el bloqueo devlink. [1] ADVERTENCIA: CPU: 5 PID: 227 en net/devlink/health.c:483 devlink_recover_notify.constprop.0+0xb8/0xc0 CPU: 5 PID: 227 Comm: kworker/u16:3 No contaminado 6.4.0-rc5_for_upstream_min_debug_2023_06_12_12_38 #1 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Cola de trabajo: mlx5_health0000:08:00.0 mlx5_fw_reporter_err_work [mlx5_core] RIP: 0010:devlink_recover_notify.constprop.0+0xb8/0xc0 Seguimiento de llamadas: ? __warn+0x79/0x120 ? devlink_recover_notify.constprop.0+0xb8/0xc0? report_bug+0x17c/0x190? handle_bug+0x3c/0x60? exc_invalid_op+0x14/0x70? asm_exc_invalid_op+0x16/0x20? devlink_recover_notify.constprop.0+0xb8/0xc0 devlink_health_report+0x4a/0x1c0 mlx5_fw_reporter_err_work+0xa4/0xd0 [mlx5_core] Process_one_work+0x1bb/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x4d/0x3c0 ? process_one_work+0x3c0/0x3c0 kthread+0xc6/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30
-
Vulnerabilidad en kernel de Linux (CVE-2024-35963)
Severidad: ALTA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: hci_sock: solución que no valida la entrada del usuario setsockopt. Verifique la longitud de la entrada del usuario antes de copiar datos.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35964)
Severidad: ALTA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: ISO: Corrección al no validar la entrada del usuario setsockopt. Verifique la longitud de la entrada del usuario antes de copiar datos.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35965)
Severidad: ALTA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: L2CAP: solución que no valida la entrada del usuario de setsockopt. Verifique la longitud de la entrada del usuario antes de copiar datos.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35971)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ks8851: maneja softirqs al final del subproceso IRQ para corregir el bloqueo. El subproceso ks8851_irq() puede llamar a ks8851_rx_pkts() en caso de que haya paquetes en MAC FIFO, que llama netif_rx(). Esta implementación de netif_rx() está protegida por local_bh_disable() y local_bh_enable(). local_bh_enable() puede llamar a do_softirq() para ejecutar softirqs en caso de que haya alguno pendiente. Uno de los softirqs es net_rx_action, que finalmente llega a la devolución de llamada .start_xmit del controlador. Si eso sucede, el sistema se bloquea. La cadena de llamadas completa está a continuación: ks8851_start_xmit_par de netdev_start_xmit netdev_start_xmit de dev_hard_start_xmit dev_hard_start_xmit de sch_direct_xmit sch_direct_xmit de __dev_queue_xmit __dev_queue_xmit de __neigh_update __neigh_update de neigh_update neigh_update de .constprop.0 arp_process.constprop.0 de __netif_receive_skb_one_core __netif_receive_skb_one_core de Process_backlog Process_backlog de __napi_poll.constprop.0 __napi_poll .constprop.0 de net_rx_action net_rx_action de __do_softirq __do_softirq de call_with_stack call_with_stack de do_softirq do_softirq de __local_bh_enable_ip __local_bh_enable_ip de netif_rx netif_rx de ks8851_irq ks8851_irq de irq_thread_fn _thread_fn de irq_thread irq_thread de kthread kthread de ret_from_fork El bloqueo ocurre porque ks8851_irq() primero bloquea un spinlock en ks8851_par. c ks8851_lock_par() spin_lock_irqsave(&ksp->lock, ...) y con ese spinlock bloqueado, llama a netif_rx(). Una vez que la ejecución llega a ks8851_start_xmit_par(), llama nuevamente a ks8851_lock_par(), lo que intenta reclamar el spinlock ya bloqueado nuevamente y se bloquea. Mueva la llamada do_softirq() fuera de la sección protegida por spinlock de ks8851_irq() deshabilitando los BH alrededor de toda la sección protegida por spinlock del controlador ks8851_irq(). Coloque local_bh_enable() fuera de la sección protegida de spinlock, para que pueda activar do_softirq() sin que se mantenga el spinlock ks8851_par.c ks8851_lock_par(), y llame de forma segura a ks8851_start_xmit_par() sin intentar bloquear el spinlock ya bloqueado. Dado que ks8851_irq() está protegido por local_bh_disable()/local_bh_enable() ahora, reemplace netif_rx() con __netif_rx() que no duplica las llamadas local_bh_disable()/local_bh_enable().
-
Vulnerabilidad en kernel de Linux (CVE-2024-35974)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: corrige la corrupción de q->blkg_list durante la revinculación del disco. Se pueden asignar/agregar múltiples instancias de gendisk para una única cola de solicitudes en caso de volver a vincular el disco. Es posible que blkg aún permanezca en q->blkg_list cuando se llama a blkcg_init_disk() para volver a vincular, entonces q->blkg_list se corrompe. Solucione el problema de corrupción de la lista: - agregue blkg_init_queue() para inicializar q->blkg_list & q->blkcg_mutex solamente - mueva la llamada a blkg_init_queue() a blk_alloc_queue() La corrupción de la lista debe iniciarse desde la confirmación f1c006f1c685 ("blk-cgroup: sincronizar pd_free_fn() de blkg_free_workfn() y blkcg_deactivate_policy()") que retrasa la eliminación de blkg de q->blkg_list en blkg_free_workfn().
-
Vulnerabilidad en kernel de Linux (CVE-2024-35987)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv: se corrigió la carga de kernels NOMMU de 64 bits después del inicio de la confirmación de RAM. 3335068f8721 ("riscv: use páginas PUD/P4D/PGD para el mapeo lineal") se agregó lógica para permitir el uso RAM debajo de la dirección de carga del kernel. Sin embargo, esto no funciona para NOMMU, donde PAGE_OFFSET está fijado a la dirección de carga del kernel. Dado que ese rango de memoria corresponde a los PFN por debajo de ARCH_PFN_OFFSET, la inicialización de mm se ejecuta desde el principio de mem_map y corrompe la memoria del kernel adyacente. Solucione este problema restaurando el comportamiento anterior de los núcleos NOMMU.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35991)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: idxd: convertir spinlock a mutex para bloquear evl workqueue. Drain_workqueue() no se puede llamar de forma segura en un contexto de spinlock debido a una posible reprogramación de tareas. En el escenario de tareas múltiples, llamar a queue_work() mientras Drain_workqueue() generará un seguimiento de llamadas, ya que no se permite enviar un trabajo a una cola de trabajo agotadora en un contexto de bloqueo por giro. Seguimiento de llamadas: ? __warn+0x7d/0x140 ? __queue_work+0x2b2/0x440? report_bug+0x1f8/0x200? handle_bug+0x3c/0x70? exc_invalid_op+0x18/0x70? asm_exc_invalid_op+0x1a/0x20? __queue_work+0x2b2/0x440 queue_work_on+0x28/0x30 idxd_misc_thread+0x303/0x5a0 [idxd] ? __schedule+0x369/0xb40? __pfx_irq_thread_fn+0x10/0x10 ? irq_thread+0xbc/0x1b0 irq_thread_fn+0x21/0x70 irq_thread+0x102/0x1b0 ? preempt_count_add+0x74/0xa0? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0x103/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 La implementación actual utiliza un bloqueo giratorio para proteger la cola de trabajo del registro de eventos y conducirá al seguimiento de llamadas debido a una posible reprogramación de tareas. Para solucionar el problema de bloqueo, convierta el spinlock a mutex, lo que permite llamar a Drain_workqueue() en un contexto seguro con bloqueo mutex. Este cambio garantiza una sincronización adecuada al acceder a la cola de trabajo del registro de eventos, lo que evita un posible seguimiento de llamadas y mejora la solidez general del código.
-
Vulnerabilidad en kernel de Linux (CVE-2024-35993)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: convierte folio_test_hugetlb en un PageType. El folio_test_hugetlb() actual puede ser engañado por una división de folio concurrente y devuelve verdadero para un folio que nunca ha pertenecido a hugetlbfs. Esto no puede suceder si la persona que llama tiene un recuento sobre él, pero tenemos algunos lugares (fallo de memoria, compactación, procfs) que no toman ni deben tomar una referencia especulativa. Dado que las páginas de Hugetlb no usan recuentos de mapas de páginas individuales (siempre están completamente asignadas y usan el campo Whole_mapcount para registrar el número de asignaciones), el campo PageType está disponible ahora que page_mapcount() ignora el valor en este campo. En compactación y con CONFIG_DEBUG_VM habilitado, la implementación actual puede resultar en un error, según lo informado por Luis. Esto sucede desde que 9c5ccf2db04b ("mm: eliminar HUGETLB_PAGE_DTOR") agregó efectivamente algunas comprobaciones de VM_BUG_ON() en la ruta de prueba de PageHuge(). [willy@infradead.org: actualizar vmcoreinfo] Enlace: https://lkml.kernel.org/r/ZgGZUvsdhaT1Va-T@casper.infradead.org
-
Vulnerabilidad en kernel de Linux (CVE-2024-35995)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: CPPC: use access_width sobre bit_width para accesos a la memoria del sistema. Para alinearse con ACPI 6.3+, dado que bit_width puede ser cualquier valor de 8 bits, no se puede depender de que esté siempre encendido. un límite limpio de 8b. Esto fue descubierto en la plataforma Cobalt 100. Interrupción de error en CPU26, código 0xbe000011 - CPU de SError: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1 Nombre de hardware: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION pstate: 62400009 (nZCv daif +PAN -UAO + TCO -DIT -SSBS BTYPE=--) pc: cppc_get_perf_caps+0xec/0x410 lr: cppc_get_perf_caps+0xe8/0x410 sp: ffff8000155ab730 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: 0080139d0078 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff x17: 0000000000000000 x16: d04 x15: ffff00802b251008 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006 x11: ffffdc7e128f4420 x10: 0000000000000000 x9: ffffdc7 e111badec x8: ffff00802b251980 x7: 0000000000000000 x6: ffff0080139d0028 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000 Pánico del kernel - no se sincroniza: SError asíncrono Interrupción CPU: 26 PID: 1510 Comunicación: systemd-udevd No contaminado 5.15.2.1-13 #1 Nombre de hardware: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION Rastreo de llamadas: dump_backtrace+0x0/0x1e0 show_stack+0x24/0x30 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 panic+0x16c/0x384 add_taint+0x0/0xc0 arm64_serror_panic+0x7c/0x9 0 arm64_is_fatal_ras_serror+0x34/0xa4 do_serror+ 0x50/0x6c el1h_64_error_handler+0x40/0x74 el1h_64_error+0x7c/0x80 cppc_get_perf_caps+0xec/0x410 cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq] cpufreq_add_dev+0xc0/0xd4 subsys_interface_register+0x134/0x14c cpufreq_register_driver+0x1b0/0x354 cppc_cpufreq_init+0x1a8/ 0x1000 [cppc_cpufreq] do_one_initcall+0x50/0x250 do_init_module+0x60/0x27c load_module+0x2300/0x2570 __do_sys_finit_module+0xa8/0x114 __arm64_sys_finit_module+0x2c/0x3c invoke_ llamada al sistema+0x78/0x100 el0_svc_common.constprop.0+0x180/0x1a0 do_el0_svc+0x84/0xa0 el0_svc+ 0x2c/0xc0 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 En su lugar, use access_width para determinar el tamaño y use el desplazamiento y el ancho para desplazar y enmascarar los bits para leer/escribir. Asegúrese de agregar una verificación de la memoria del sistema, ya que pcc redefine el ancho de acceso al ID del subespacio. Si access_width no está configurado, vuelva a utilizar bit_width. [rjw: ediciones de asunto y registro de cambios, ajustes de comentarios]
-
Vulnerabilidad en kernel de Linux (CVE-2024-36002)
Severidad: MEDIA
Fecha de publicación: 20/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dpll: corrige dpll_pin_on_pin_register() para múltiples pines principales En un escenario donde el pin se registra con múltiples pines principales a través de dpll_pin_on_pin_register(..), todos pertenecientes al mismo dispositivo dpll. Una segunda llamada a dpll_pin_on_pin_unregister(..) provocaría un seguimiento de la llamada, ya que intenta utilizar recursos de registro ya liberados (debido a la solución introducida en b446631f355e). En este escenario, el pin se registró dos veces, por lo que aún no se espera que se liberen recursos hasta que se cancele el registro de cada pin/par de pines registrado. Actualmente, se produce el siguiente seguimiento de fallas/llamadas cuando se elimina el controlador Ice en el sistema con la NIC E810T instalada que incluye el dispositivo dpll: ADVERTENCIA: CPU: 51 PID: 9155 en drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30 RIP: 0010:dpll_pin_ops+0x20/0x30 Seguimiento de llamadas:? __warn+0x7f/0x130 ? dpll_pin_ops+0x20/0x30 dpll_msg_add_pin_freq+0x37/0x1d0 dpll_cmd_pin_get_one+0x1c0/0x400 ? __nlmsg_put+0x63/0x80 dpll_pin_event_send+0x93/0x140 dpll_pin_on_pin_unregister+0x3f/0x100 ice_dpll_deinit_pins+0xa1/0x230 [ice] ice_remove+0xf1/0x210 [ice] Se soluciona agregando un puntero principal como cookie al crear un registro. también al buscarlo . Para los pines normales pasan NULL, esto permite crear un registro separado para cada padre con el que está registrado el pin.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47446)
Severidad: MEDIA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/a4xx: corrige el manejo de errores en a4xx_gpu_init() Este código devuelve 1 en caso de error en lugar de un error negativo. Conduce a un Ups en la persona que llama. Un segundo problema es que la verificación de "if (ret! = -ENODATA)" no puede ser verdadera porque "ret" está establecido en 1.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47465)
Severidad: MEDIA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: PPC: Book3S HV: Arreglar el manejo de la pila en idle_kvm_start_guest() En el commit 10d91611f426 ("powerpc/64s: Reimplementar el código inactivo de book3s en C") kvm_start_guest() se convirtió en idle_kvm_start_guest() . El código antiguo asignaba un marco de pila en la pila de emergencia, pero no usaba el marco para almacenar nada y tampoco almacenaba nada en el marco de la persona que llama. idle_kvm_start_guest(), por otro lado, se escribe más como una función C normal, crea un marco al ingresar y también almacena CR/LR en el marco de la persona que llama (según la ABI). El problema es que no hay ningún marco de llamada en la pila de emergencia. La pila de emergencia para una CPU determinada se asigna con: paca_ptrs[i]->emergency_sp = alloc_stack(limit, i) + THREAD_SIZE; Entonces, Emergency_sp en realidad apunta a la primera dirección encima de la asignación de pila de emergencia para una CPU determinada; no debemos almacenar encima de ella sin primero disminuirla para crear un marco. Esto es diferente a la pila normal del kernel, paca->kstack, que se inicializa para apuntar a un marco inicial que está listo para usar. idle_kvm_start_guest() almacena la cadena posterior, CR y LR, todos los cuales escriben fuera de la asignación para la pila de emergencia. Luego crea un marco de pila y guarda los registros no volátiles. Desafortunadamente, el marco que crea no es lo suficientemente grande para acomodar los registros no volátiles, por lo que guardar los registros no volátiles también escribe fuera de la asignación de pila de emergencia. El resultado final es que corrompemos todo lo que esté entre 0 y 24 bytes y entre 112 y 248 bytes por encima de la asignación de pila de emergencia. En la práctica, esto ha pasado desapercibido porque la memoria inmediatamente encima de la pila de emergencia se usa para otras asignaciones de pila, ya sea otra CPU mc_emergency_sp o una pila IRQ. Vea el orden de las llamadas a irqstack_early_init() y Emergency_stack_init(). Las direcciones bajas de otra pila están en la parte superior de esa pila, por lo que solo se usan si esa pila está bajo una presión extrema, lo que esencialmente nunca sucede en la práctica, y si así fuera, existe una alta probabilidad de que fallemos debido a que esa pila se desborde. . Aún así, no deberíamos estar corrompiendo la pila de otra persona, y es pura suerte que no estemos corrompiendo algo más. Para solucionarlo, guardamos CR/LR en el marco de la persona que llama usando el r1 existente en la entrada, luego creamos un marco SWITCH_FRAME_SIZE (que tiene espacio para pt_regs) en la pila de emergencia con la cadena posterior apuntando a la pila existente, y finalmente cambiamos al nuevo marco en la pila de emergencia.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47468)
Severidad: MEDIA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: isdn: mISDN: corrige la función de suspensión llamada desde un contexto no válido. El controlador puede llamar a la función card->isac.release() desde un contexto atómico. Solucione este problema llamando a esta función después de liberar el bloqueo. El siguiente registro lo revela: [44.168226] ERROR: función inactiva llamada desde un contexto no válido en kernel/workqueue.c:3018 [44.168941] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, nombre: modprobe [44.169574] INFORMACIÓN: lockdep está desactivado. [ 44.169899 ] sello de evento irq: 0 [ 44.170160 ] hardirqs habilitado por última vez en (0): [<0000000000000000>] 0x0 [ 44.170627 ] hardirqs deshabilitado por última vez en (0): [] copy_process+0x132d/0x3e00 [ 44.171240 ] softirqs habilitado por última vez en (0): [] copy_process+0x135a/0x3e00 [ 44.171852 ] softirqs deshabilitado por última vez en (0): [<00000000000000000>] 0x0 [ 44.172318 ] Preferencia deshabilitada en: [ 44.172320 ] ffa009b0a9>] nj_release +0x69/0x500 [netjet] [ 44.174441 ] Seguimiento de llamadas: [ 44.174630 ] dump_stack_lvl+0xa8/0xd1 [ 44.174912 ] dump_stack+0x15/0x17 [ 44.175166 ] ___might_sleep+0x3a2/0x510 [ 44.175459 ] ? nj_release+0x69/0x500 [netjet] [ 44.175791 ] __might_sleep+0x82/0xe0 [ 44.176063 ] ? start_flush_work+0x20/0x7b0 [ 44.176375 ] start_flush_work+0x33/0x7b0 [ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170 [44.177034]? kasan_quarantine_put+0xaa/0x1f0 [ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177711 ] __flush_work+0x11a/0x1a0 [ 44.177991 ] ? Flush_work+0x20/0x20 [44.178257]? lock_release+0x13c/0x8f0 [44.178550]? __kasan_check_write+0x14/0x20 [44.178872]? do_raw_spin_lock+0x148/0x360 [44.179187]? read_lock_is_recursive+0x20/0x20 [44.179530]? __kasan_check_read+0x11/0x20 [44.179846]? do_raw_spin_unlock+0x55/0x900 [44.180168]? ____kasan_slab_free+0x116/0x140 [44.180505]? _raw_spin_unlock_irqrestore+0x41/0x60 [44.180878]? skb_queue_purge+0x1a3/0x1c0 [44.181189]? kfree+0x13e/0x290 [ 44.181438 ] Flush_work+0x17/0x20 [ 44.181695 ] mISDN_freedchannel+0xe8/0x100 [ 44.182006 ] isac_release+0x210/0x260 [mISDNipac] [ 44.182366 nj _release+0xf6/0x500 [netjet] [ 44.182685 ] nj_remove+0x48/ 0x70 [netjet] [44.182989] pci_device_remove+0xa9/0x250
-
Vulnerabilidad en kernel de Linux (CVE-2021-47474)
Severidad: ALTA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: comedi: vmk80xx: corrige el desbordamiento masivo del búfer El controlador utiliza búferes del tamaño de un endpoint, pero no debe asumir que los búferes tx y rx son del mismo tamaño o un dispositivo malicioso podría desbordar el búfer de recepción asignado por losa al realizar transferencias masivas.
-
Vulnerabilidad en kernel de Linux, (CVE-2021-47475)
Severidad: ALTA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: comedi: vmk80xx: corrige desbordamientos del búfer de transferencia El controlador utiliza búferes de transferencia USB del tamaño de un terminal, pero hasta hace poco no tenía controles de cordura sobre los tamaños. el commit e1f13c879a7c ("staging: comedi: verificar la validez de wMaxPacketSize de los endpoints USB encontrados") corrigió inadvertidamente las desreferencias de puntero NULL al acceder a los buffers de transferencia en caso de que un dispositivo malicioso tenga un wMaxPacketSize cero. Asegúrese de asignar buffers lo suficientemente grandes para manejar también los otros accesos que se realizan sin una verificación de tamaño (por ejemplo, el byte 18 en vmk80xx_cnt_insn_read() para VMK8061_MODEL) para evitar escribir más allá de los buffers, por ejemplo, cuando se realiza una confusión de descriptores. El controlador original era para un dispositivo de baja velocidad con buffers de 8 bytes. Posteriormente se agregó soporte para un dispositivo que utiliza transferencias masivas y presumiblemente es un dispositivo de velocidad completa con un wMaxPacketSize máximo de 64 bytes.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47477)
Severidad: ALTA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: comedi: dt9812: corrige los búferes DMA en la pila Los búferes de transferencia USB generalmente están asignados para DMA y no deben asignarse en la pila o las transferencias fallarán. Asigne búferes de transferencia adecuados en los distintos asistentes de comando y devuelva un error en transferencias cortas en lugar de actuar sobre datos de pila aleatorios. Tenga en cuenta que esto también soluciona una fuga de información de la pila en sistemas donde no se usa DMA, ya que siempre se envían 32 bytes al dispositivo, independientemente de cuán corto sea el comando.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47479)
Severidad: ALTA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: staging: rtl8712: corrige el use-after-free en rtl8712_dl_fw Syzbot informó el use-after-free en rtl8712_dl_fw(). El problema estaba en la condición de ejecución entre la devolución de llamada r871xu_dev_remove() ->ndo_open(). Es fácil ver en el registro de fallos que el controlador accede al firmware lanzado en la devolución de llamada ->ndo_open(). Puede suceder, ya que el controlador estaba lanzando el firmware _antes_ de cancelar el registro de netdev. Solucionarlo moviendo unregister_netdev() antes de limpiar los recursos. Traza de llamada: ... RTL871X_OPEN_FW : 330 [ inline] rtl871x_hal_init+0xae/0x180 drivers/staging/rtl8712/hal_init.c:394 netdev_open+0xe6/0x6c0 drivers/staging/rtl8712/os_intfs.c:380 __dev_open+0x2bc/0x4d0 net/core/dev.c:1484 Liberado por tarea 1306: ... release_firmware+0x1b/0x30 drivers/base/firmware_loader/main.c:1053 r871xu_dev_remove+0xcc/0x2c0 drivers/staging/rtl8712/usb_intf.c:599 usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver .c:458
-
Vulnerabilidad en kernel de Linux (CVE-2021-47493)
Severidad: MEDIA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige la ejecución entre fragmentos de búsqueda y libera journal_head de buffer_head Se encontró una ejecución entre ocfs2_test_bg_bit_allocatable() y jbd2_journal_put_journal_head() que resultó en el siguiente vmcore. PID: 106879 TAREA: ffff880244ba9c00 CPU: 2 COMANDO: "loop3" Rastreo de llamadas: pánico oops_end no_context __bad_area_nosemaphore bad_area_nosemaphore __do_page_fault do_page_fault page_fault [excepción RIP: ocfs2_block_group_find_clear_bits+316] 2_block_group_find_clear_bits [ocfs2] ocfs2_cluster_group_search [ocfs2] ocfs2_search_chain [ocfs2] ocfs2_claim_suballoc_bits [ocfs2] __ocfs2_claim_clusters [ocfs2] ocfs2_claim_clusters [ocfs2] ocfs2_local_alloc_slide_window [ocfs2] ocfs2_reserve_local_alloc_bits [ocfs2] ocfs2_reserve_clusters_with_limit [ocfs2] ocfs2_reserve_clusters [ocfs2] ocfs2_lock_refcount_allocators [ocfs2] 2_make_clusters_writable [ocfs2] ocfs2_replace_cow [ocfs2] ocfs2_refcount_cow [ocfs2] ocfs2_file_write_iter [ocfs2] lo_rw_aio loop_queue_work kthread_worker_fn kthread ret_from_fork Cuando ocfs2_test_bg_bit_allocatable () llamado bh2jh(bg_bh), el bg_bh->b_private NULL como jbd2_journal_put_journal_head() corrió y liberó el encabezado del diario del encabezado del búfer. Era necesario bloquear el bit 'BH_JournalHead' para solucionar esta ejecución.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47494)
Severidad: MEDIA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cfg80211: corrige el bloqueo de registros de administración. El bloqueo de registros de administración estaba roto, la lista estaba bloqueada para cada wdev, pero cfg80211_mgmt_registrations_update() la repitió sin mantener todos los spinlocks correctos, lo que provocó corrupción en la lista. En lugar de intentar solucionarlo con un bloqueo detallado, simplemente mueva el bloqueo a wiphy/rdev (aún necesitamos la lista en cada wdev), ya necesitamos mantener presionado el bloqueo wdev para cambiarlo, por lo que no hay contención en el bloqueo. En todo caso. Esto soluciona trivialmente el error ya que ya tenemos un bloqueo de wdev y ahora mantendremos el bloqueo que protege todas las listas.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47496)
Severidad: ALTA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/tls: corrige las llamadas invertidas de tls_err_abort() sk->sk_err parece esperar un valor positivo, una convención que ktls no siempre sigue y que conduce a daños en la memoria en otro código. Por ejemplo, [kworker] tls_encrypt_done(..., err=) tls_err_abort(.., err) sk->sk_err = err; [tarea] splice_from_pipe_feed ... tls_sw_do_sendpage if (sk->sk_err) { ret = -sk->sk_err; // ret es positivo splice_from_pipe_feed (continuación) ret = actor(...) // ret sigue siendo positivo y se interpreta como bytes // escritos, lo que resulta en un desbordamiento insuficiente de buf->len y // sd->len, lo que genera enormes buf->offset y bogus // direcciones calculadas en llamadas posteriores a actor(). Repare todas las llamadas tls_err_abort() para que pasen un código de error negativo de manera consistente y centralice el cambio de señal propenso a errores allí, lanzando una advertencia para detectar futuros usos indebidos y eliminación de líneas. la función por lo que realmente solo advierte una vez.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47497)
Severidad: ALTA
Fecha de publicación: 22/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvmem: corrige el desplazamiento fuera de los límites (UBSAN) con celdas de tamaño de bytes. Si una celda tiene 'nbits' iguales a un múltiplo de BITS_PER_BYTE, la lógica *p &= GENMASK( (celda->nbits%BITS_PER_BYTE) - 1, 0); se convertirá en un comportamiento indefinido porque el módulo de nbits BITS_PER_BYTE es 0, y restamos uno de eso, lo que genera un número grande que luego se desplaza más que el número de bits que caben en un largo sin signo. UBSAN informa este problema: UBSAN: desplazamiento fuera de los límites en drivers/nvmem/core.c:1386:8 el exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'largo sin firmar' CPU: 6 PID: 7 Comm: kworker /u16:0 Not tainted 5.15.0-rc3+ #9 Nombre del hardware: Google Lazor (rev3+) con KB Backlight (DT) Cola de trabajo: events_unbound deferred_probe_work_func Rastreo de llamadas: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack +0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 mem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 componente_bind_all+0xf0/0x264 msm_drm_bind +0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c componente_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 very_probe+0x110/0x304 _device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv +0x90/0xdc __device_attach+0xc8/0x174 dispositivo_inicial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 diferido_probe_work_func+0x7c/0xb8 proceso_one_work+0x128/0x21c proceso_scheduled_works+0x40/0x54 trabajador_hilo+0 x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Arreglar asegurándose de que haya partes que enmascarar.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47507)
Severidad: MEDIA
Fecha de publicación: 24/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrige la ejecución de inicio de nsfd (nuevamente) El commit bd5ae9288d64 ("nfsd: registre las operaciones de pernet al final, anule el registro primero") ha reabierto la ejecución de rpc_pipefs_event() contra el registro de nfsd_net_id (register_pernet_subsys( )) que se ha solucionado mediante el commit bb7ffbf29e76 ("nfsd: arreglar la ejecución de inicio de nsfd que activa BUG_ON"). Restaure el orden de Register_pernet_subsys() frente a Register_cld_notifier(). Agregue WARN_ON() para evitar una regresión futura. Información de falla: no se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000012 CPU: 8 PID: 345 Comm: mount Not tainted 5.4.144-... #1 pc: rpc_pipefs_event+0x54/0x120 [nfsd] lr: rpc_pipefs_event+0x48/ 0x120 [nfsd] Rastreo de llamadas: rpc_pipefs_event+0x54/0x120 [nfsd] blocking_notifier_call_chain rpc_fill_super get_tree_keyed rpc_fs_get_tree vfs_get_tree do_mount ksys_mount __arm64_sys_mount el0_svc_handler el0_svc
-
Vulnerabilidad en kernel de Linux (CVE-2021-47508)
Severidad: MEDIA
Fecha de publicación: 24/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: conjunto de cambios de intercambio gratuito en caso de fallas. Las ejecuciones de Fstests en mis VM han mostrado varios informes de kmemleak como el siguiente. objeto sin referencia 0xffff88811ae59080 (tamaño 64): comm "xfs_io", pid 12124, jiffies 4294987392 (edad 6,368 s) volcado hexadecimal (primeros 32 bytes): 00 c0 1c 00 00 00 00 00 ff cf 1c 00 00 00 00... ............. 90 97 e5 1a 81 88 ff ff 90 97 e5 1a 81 88 ff ff ................ retroceso: [<00000000ac0176d2 >] ulist_add_merge+0x60/0x150 [btrfs] [<0000000076e9f312>] set_state_bits+0x86/0xc0 [btrfs] [<0000000014fe73d6>] set_extent_bit+0x270/0x690 [btrfs] [<000000004f 675208>] set_record_extent_bits+0x19/0x20 [btrfs] [ <00000000b96137b1>] qgroup_reserve_data+0x274/0x310 [btrfs] [<0000000057e9dcbb>] btrfs_check_data_free_space+0x5c/0xa0 [btrfs] [<0000000019c4511d>] +0x1b/0xa0 [btrfs] [<000000006d37e007>] btrfs_dio_iomap_begin+0x415/0x970 [btrfs ] [<00000000fb8a74b8>] iomap_iter+0x161/0x1e0 [<0000000071dff6ff>] __iomap_dio_rw+0x1df/0x700 [<000000002567ba53>] iomap_dio_rw+0x5/0x20 [<000000 0072e555f8>] btrfs_file_write_iter+0x290/0x530 [btrfs] [<000000005eb3d845>] new_sync_write +0x106/0x180 [<000000003fb505bf>] vfs_write+0x24d/0x2f0 [<000000009bb57d37>] __x64_sys_pwrite64+0x69/0xa0 [<000000003eba3fdf>] 3/0x90 En caso de que brtfs_qgroup_reserve_data() o btrfs_delalloc_reserve_metadata() fallen, el conjunto de cambios asignado no será liberado. Entonces, en btrfs_check_data_free_space() y btrfs_delalloc_reserve_space() libera el extend_changeset asignado para deshacerte de la memoria asignada. Actualmente, el problema solo ocurre en la ruta de escritura de IO directa, pero solo después de 65b3c08606e5 ("btrfs: corrige la falla de ENOSPC al intentar escribir IO directa en el rango NOCOW"), y también en defrag_one_locked_target(). Todos los demás lugares siempre llaman a extend_changeset_free() incluso si su llamada a btrfs_delalloc_reserve_space() o btrfs_check_data_free_space() ha fallado.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47515)
Severidad: MEDIA
Fecha de publicación: 24/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: seg6: corrige el iif en el bloque de control del socket IPv6 Cuando se recibe un paquete IPv4, ip_rcv_core(...) establece el índice de la interfaz de recepción en el bloque de control del socket IPv4 (v5 .16-rc4, net/ipv4/ip_input.c línea 510): IPCB(skb)->iif = skb->skb_iif; Si ese paquete IPv4 debe encapsularse en un encabezado IPv6+SRH externo, seg6_do_srh_encap(...) realiza la encapsulación requerida. En este caso, la función seg6_do_srh_encap borra el bloque de control del socket IPv6 (v5.16-rc4 net/ipv6/seg6_iptunnel.c línea 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); El memset(...) se introdujo en El commit ef489749aae5 ("ipv6: sr: clear IP6CB(skb) en la encapsulación SRH ip4ip6") hace mucho tiempo (29 de enero de 2019). Dado que el bloque de control del socket IPv6 y el bloque de control del socket IPv4 comparten la misma área de memoria (skb->cb), la información del índice de la interfaz de recepción se pierde (IP6CB(skb)->iif se establece en cero). Como efecto secundario, esa condición desencadena una desreferencia del puntero NULL si se aplica el commit 0857d6f8c759 ("ipv6: al reenviar estadísticas de recuento de rx en el netdev original"). Para solucionar ese problema, configuramos IP6CB(skb)->iif con el índice de la interfaz de recepción una vez más.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47523)
Severidad: MEDIA
Fecha de publicación: 24/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/hfi1: Corrección de fuga de rcvhdrtail_dummy_kvaddr. Este búfer está actualmente asignado en hfi1_init(): if (reinit) ret = init_after_reset(dd); de lo contrario ret = loadtime_init(dd); si (ret) ir a hecho; /* asigna memoria de cola ficticia para todos los contextos de recepción */ dd->rcvhdrtail_dummy_kvaddr = dma_alloc_coherent(&dd->pcidev->dev, sizeof(u64), &dd->rcvhdrtail_dummy_dma, GFP_KERNEL); if (!dd->rcvhdrtail_dummy_kvaddr) { dd_dev_err(dd, "no se puede asignar memoria de cola ficticia\n"); ret = -ENOMEM; ir a hacer; } La ruta activada por reinicio sobrescribirá la asignación anterior y la filtrará. Para solucionarlo, mueva la asignación a hfi1_alloc_devdata() y la desasignación a hfi1_free_devdata().
-
Vulnerabilidad en kernel de Linux (CVE-2021-47524)
Severidad: MEDIA
Fecha de publicación: 24/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: serial: liteuart: corrige la fuga de números menores en errores de sonda. Asegúrese de liberar el número menor asignado antes de regresar por errores de sonda.
-
Vulnerabilidad en kernel de Linux (CVE-2021-47527)
Severidad: MEDIA
Fecha de publicación: 24/05/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: serial: core: fix transmit-buffer reset y memleak commit 761ed4a94582 ("tty: serial_core: convert uart_close to use tty_port_close") núcleo serial convertido para usar tty_port_close() pero no se dio cuenta que el búfer de transmisión todavía necesita ser liberado en el cierre final. No liberar el búfer de transmisión significa que el búfer ya no se borra en la próxima apertura, por lo que cualquier ioctl() que espere a que se drene el búfer podría esperar indefinidamente (por ejemplo, en cambios de termios) o que los datos obsoletos pueden terminar transmitiéndose en caso de que tx sea reiniciado. Además, el búfer de cualquier puerto que se haya abierto se filtraría al desvincular el controlador. Tenga en cuenta que el bloqueo del puerto se mantiene al borrar el puntero del búfer debido a la ejecución de ldisc solucionada mediante el commit a5ba1d95e46e ("uart: corrige la ejecución entre uart_put_char() y uart_shutdown()"). También tenga en cuenta que la devolución de llamada tty-portshutdown() no se llama para los puertos de consola, por lo que no es estrictamente necesario liberar la página del búfer después de liberar el bloqueo (cf. d72402145ace ("tty/serial: no liberar la página del búfer de transmisión en el puerto cerrar con llave")).
-
Vulnerabilidad en kernel de Linux (CVE-2022-48774)
Severidad: MEDIA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: ptdma: corrige la ruta de manejo de errores en pt_core_init() Para liberar recursos correctamente en la ruta de manejo de errores de pt_core_init(), se deben cambiar 2 goto. De lo contrario, algunos recursos se filtrarán e intentaremos liberar cosas que aún no se han asignado. También mueva un dev_err() a un lugar donde sea más significativo.
-
Vulnerabilidad en kernel de Linux (CVE-2022-48776)
Severidad: MEDIA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: parsers: qcom: Corrige la falta de espacio libre para pparts en la limpieza Mtdpart no libera pparts cuando se declara una función de limpieza. Agregue piezas libres faltantes en la función de limpieza para que smem arregle la fuga.
-
Vulnerabilidad en kernel de Linux (CVE-2022-48794)
Severidad: MEDIA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ieee802154: at86rf230: Detener la fuga de skb. En caso de error, no se llama al asistente ieee802154_xmit_complete(). Solo se llama manualmente a ieee802154_wake_queue(). En el caso de Tx, filtramos la estructura skb. Libere la estructura skb en caso de error antes de regresar cuando sea apropiado. Como 'is_tx = 0' no se puede mover en el controlador completo debido a una posible ejecución entre el retraso en el cambio a STATE_RX_AACK_ON y una nueva interrupción, introducimos un booleano intermedio 'was_tx' solo para este propósito. No se aplica ninguna etiqueta de Correcciones aquí, se han realizado muchos cambios en esta área y el problema siempre existió.
-
Vulnerabilidad en kernel de Linux (CVE-2022-48801)
Severidad: ALTA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: buffer: corrige el manejo de errores relacionados con archivos en IIO_BUFFER_GET_FD_IOCTL Si no logramos copiar el descriptor de archivo recién creado en la zona de usuario, intentamos limpiar colocando de nuevo 'fd' y liberando ' ib'. El código usa put_unused_fd() para el primero, lo cual es incorrecto, ya que el descriptor de archivo ya fue publicado por fd_install(), que es llamado internamente por anon_inode_getfd(). Esto hace que el código de manejo de errores deje una tabla de descriptores de archivos medio limpia y un objeto 'archivo' parcialmente destruido, lo que permite que Userland nos juegue trucos de use-after-free, abusando del fd aún utilizable y haciendo que el código funcione en un puntero 'archivo->datos_privados' colgando. En lugar de dejar el kernel en un estado parcialmente dañado, no intente limpiar explícitamente y dejar esto en la ruta de salida del proceso que liberará cualquier fds aún válido, incluido el creado por la llamada anterior a anon_inode_getfd(). Simplemente devuelva -EFAULT para indicar el error.
-
Vulnerabilidad en kernel de Linux (CVE-2022-48803)
Severidad: MEDIA
Fecha de publicación: 16/07/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: phy: ti: corrige el centinela faltante para clk_div_table _get_table_maxdiv() intenta acceder a la matriz "clk_div_table" fuera del límite definido en phy-j721e-wiz.c. Agregue una entrada centinela para evitar el siguiente error global fuera de los límites informado al habilitar KASAN. [9.552392] ERROR: KASAN: global fuera de los límites en _get_maxdiv+0xc0/0x148 [9.558948] Lectura de tamaño 4 en la dirección ffff8000095b25a4 por tarea kworker/u4:1/38 [9.565926] [9.567441] CPU: 1 PID: 38 Comm: kworker/u4:1 No contaminado 5.16.0-116492-gdaadb3bd0e8d-dirty #360 [ 9.576242] Nombre de hardware: Texas Instruments J721e EVM (DT) [ 9.581832] Cola de trabajo: events_unbound deferred_probe_work_func [ 9.587708] Seguimiento de llamadas: [ 9.590174] dump_backtrace+0x20c/0x218 [ 9.594038] show_stack+0x18/0x68 [ 9.597375] dump_stack_lvl+0x9c/0xd8 [ 9.601062] print_address_description.constprop.0+0x78/0x334 [ 9.606830] 0x1f0/0x260 [9.610517] __asan_load4+0x9c/0xd8 [ 9.614030] _get_maxdiv+0xc0/0x148 [ 9.617540] divider_determinate_rate+0x88/0x488 [ 9.622005] divider_round_rate_parent+0xc8/0x124 [ 9.626729] wiz_clk_div_round_rate+0x54/0x68 [ 9.6 31113] clk_core_determine_round_nolock+0x124/0x158 [ 9.636448] clk_core_round_rate_nolock+0x68/0x138 [ 9.641260] clk_core_set_rate_nolock+0x268/0x3a8 [ 9.645987] clk_set_rate+0x50/0xa8 [ 9.649499] cdns_sierra_phy_init+0x88/0x248 [ 9.653794] phy_init+0x98/0x108 [ 9.657046] cdns_pcie_enable_phy+0xa0/0x170 [ 9.661340] cdns_pcie_init_phy+0x250/0x2b0 [ 9.665546] j721e_pcie_probe+ 0x4b8/0x798 [ 9.669579] platform_probe+0x8c/0x108 [ 9.673350] very_probe+0x114/0x630 [ 9.677037] __driver_probe_device+0x18c/0x220 [ 9.681505] driver_probe_device+0xac/0x 150 [9.685712] __device_attach_driver+0xec/0x170 [9.690178] bus_for_each_drv+0xf0/ 0x158 [ 9.694124] __device_attach+0x184/0x210 [ 9.698070] device_initial_probe+0x14/0x20 [ 9.702277] bus_probe_device+0xec/0x100 [ 9.706223] deferred_probe_work_func+0x124/0x1 80 [ 9.710951] proceso_un_trabajo+0x4b0/0xbc0 [ 9.714983] hilo_trabajador+0x74/0x5d0 [ 9.718668] kthread+0x214/0x230 [ 9.721919] ret_from_fork+0x10/0x20 [ 9.725520] [ 9.727032] La dirección del error pertenece a la variable: [ 9.732183] clk_div_table+0x24/0x440
-
Vulnerabilidad en Weaver Ecology v9 (CVE-2024-48071)
Severidad: MEDIA
Fecha de publicación: 19/11/2024
Fecha de última actualización: 24/09/2025
Un problema en el componente /importmould/deletefolder de Weaver Ecology v9.* permite a atacantes autenticados ejecutar un directory traversal y eliminar archivos arbitrariamente.
-
Vulnerabilidad en MBed OS 6.16.0 (CVE-2024-48984)
Severidad: CRÍTICA
Fecha de publicación: 20/11/2024
Fecha de última actualización: 24/09/2025
Se descubrió un problema en MBed OS 6.16.0. Al analizar informes hci, el software de análisis hci determina dinámicamente la longitud de una lista de informes leyendo un byte de un flujo de entrada. Luego obtiene la longitud del primer informe, la utiliza para calcular el comienzo del segundo informe, etc. Al hacer esto, realiza un seguimiento del informe más grande para luego asignar un búfer que se ajuste a cada informe individual (pero solo uno a la vez). Sin embargo, no valida que todas estas direcciones estén contenidas dentro del búfer pasado a hciEvtProcessLeExtAdvReport. Entonces es posible, aunque poco probable, que el búfer designado para almacenar los informes se asigne de tal manera que uno de estos campos de longitud fuera de los límites esté contenido dentro del nuevo búfer. Cuando se copia el (n-1)º informe, sobrescribe el campo de longitud del nº informe. Este campo de longitud ahora dañado se utiliza luego para una memcpy en el nuevo búfer, lo que puede provocar un desbordamiento del búfer.
-
Vulnerabilidad en QuRouter (CVE-2024-48860)
Severidad: CRÍTICA
Fecha de publicación: 22/11/2024
Fecha de última actualización: 24/09/2025
Se ha informado de una vulnerabilidad de inyección de comandos en el sistema operativo que afecta a varias versiones del producto. Si se explota, la vulnerabilidad podría permitir a atacantes remotos ejecutar comandos. Ya hemos corregido la vulnerabilidad en la siguiente versión: QuRouter 2.4.3.103 y posteriores
-
Vulnerabilidad en QuRouter (CVE-2024-48861)
Severidad: ALTA
Fecha de publicación: 22/11/2024
Fecha de última actualización: 24/09/2025
Se ha informado de una vulnerabilidad de inyección de comandos en el sistema operativo que afecta a varias versiones del producto. Si se explota, la vulnerabilidad podría permitir a los atacantes de la red local ejecutar comandos. Ya hemos corregido la vulnerabilidad en las siguientes versiones: QuRouter 2.4.4.106 y posteriores
-
Vulnerabilidad en Sysax Multi Server 6.99 (CVE-2024-53459)
Severidad: MEDIA
Fecha de publicación: 02/12/2024
Fecha de última actualización: 24/09/2025
Sysax Multi Server 6.99 es vulnerable a Cross Site Scripting (XSS) a través del parámetro /scgi?sid.
-
Vulnerabilidad en Quick Share Agent Android (CVE-2024-49421)
Severidad: MEDIA
Fecha de publicación: 03/12/2024
Fecha de última actualización: 24/09/2025
El path traversal en Quick Share Agent anterior a la versión 3.5.14.47 en Android 12, 3.5.19.41 en Android 13 y 3.5.19.42 en Android 14 permite a atacantes adyacentes escribir archivos en una ubicación arbitraria.
-
Vulnerabilidad en QuRouter (CVE-2024-50389)
Severidad: CRÍTICA
Fecha de publicación: 06/12/2024
Fecha de última actualización: 24/09/2025
Se ha informado de una vulnerabilidad de inyección SQL que afecta a QuRouter. Si se explota, la vulnerabilidad podría permitir a atacantes remotos inyectar código malicioso. Ya hemos corregido la vulnerabilidad en la siguiente versión: QuRouter 2.4.5.032 y posteriores
-
Vulnerabilidad en Teamcenter Visualization y Tecnomatix Plant Simulation (CVE-2024-53041)
Severidad: ALTA
Fecha de publicación: 10/12/2024
Fecha de última actualización: 24/09/2025
Se ha identificado una vulnerabilidad en Teamcenter Visualization V14.2 (todas las versiones < V14.2.0.14), Teamcenter Visualization V14.3 (todas las versiones < V14.3.0.12), Teamcenter Visualization V2312 (todas las versiones < V2312.0008), Tecnomatix Plant Simulation V2302 (todas las versiones < V2302.0016), Tecnomatix Plant Simulation V2404 (todas las versiones < V2404.0005). Las aplicaciones afectadas contienen una vulnerabilidad de desbordamiento de pila al analizar archivos WRL especialmente manipulados. Esto podría permitir que un atacante ejecute código en el contexto del proceso actual. (ZDI-CAN-25000)
-
Vulnerabilidad en Teamcenter Visualization y Tecnomatix Plant Simulation (CVE-2024-53242)
Severidad: ALTA
Fecha de publicación: 10/12/2024
Fecha de última actualización: 24/09/2025
Se ha identificado una vulnerabilidad en Teamcenter Visualization V14.2 (todas las versiones < V14.2.0.14), Teamcenter Visualization V14.3 (todas las versiones < V14.3.0.12), Teamcenter Visualization V2312 (todas las versiones < V2312.0008), Tecnomatix Plant Simulation V2302 (todas las versiones < V2302.0016), Tecnomatix Plant Simulation V2404 (todas las versiones < V2404.0005). Las aplicaciones afectadas contienen una lectura fuera de los límites más allá del final de una estructura asignada mientras se analizan archivos WRL especialmente manipulados. Esto podría permitir que un atacante ejecute código en el contexto del proceso actual. (ZDI-CAN-25206)
-
Vulnerabilidad en Mattermost (CVE-2024-11358)
Severidad: MEDIA
Fecha de publicación: 16/12/2024
Fecha de última actualización: 24/09/2025
Las versiones <=2.21.0 de las aplicaciones móviles de Mattermost para Android no configuran correctamente los proveedores de archivos, lo que permite que un atacante con acceso local acceda a los archivos a través del proveedor de archivos.
-
Vulnerabilidad en QNAP (CVE-2023-23356)
Severidad: MEDIA
Fecha de publicación: 19/12/2024
Fecha de última actualización: 24/09/2025
Se ha informado de una vulnerabilidad de inyección de comandos que afecta a varias versiones del sistema operativo QNAP. Si se explota, la vulnerabilidad podría permitir que atacantes remotos que hayan obtenido acceso de administrador ejecuten comandos arbitrarios. Ya hemos corregido la vulnerabilidad en las siguientes versiones: QuFirewall 2.3.3 (2023/03/27) y posteriores.
-
Vulnerabilidad en kernel de Linux (CVE-2024-56616)
Severidad: ALTA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/dp_mst: Corregir la comprobación de longitud del cuerpo del mensaje de banda lateral MST Corrige la comprobación de longitud del cuerpo del mensaje de banda lateral MST, que debe ser de al menos 1 byte teniendo en cuenta el CRC del cuerpo del mensaje (también conocido como CRC de los datos del mensaje) al final del mensaje. Esto corrige un caso en el que un dispositivo de rama MST devuelve un encabezado con un CRC de encabezado correcto (que indica una longitud de cuerpo recibida correctamente), con la longitud del cuerpo configurada incorrectamente en 0. Esto luego provocará una corrupción de memoria en drm_dp_sideband_append_payload() y los siguientes errores en dmesg: UBSAN: array-index-out-of-bounds en drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Seguimiento de llamadas: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: se detectó una escritura que abarca el campo (tamaño 18446744073709551615) de un solo campo "&msg->msg[msg->curlen]" en drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (tamaño 256) Seguimiento de llamadas: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]
-
Vulnerabilidad en langhsu Mblog Blog System 3.5.0 (CVE-2024-13198)
Severidad: MEDIA
Fecha de publicación: 09/01/2025
Fecha de última actualización: 24/09/2025
Se ha encontrado una vulnerabilidad clasificada como problemática en langhsu Mblog Blog System 3.5.0. Se ve afectada una función desconocida del archivo /login. La manipulación provoca una discrepancia de respuesta observable. Es posible lanzar el ataque de forma remota. La complejidad de un ataque es bastante alta. Se dice que la explotabilidad es difícil. El exploit se ha revelado al público y puede usarse. Se contactó al proveedor con anticipación sobre esta revelación, pero no respondió de ninguna manera.
-
Vulnerabilidad en langhsu Mblog Blog System 3.5.0 (CVE-2024-13199)
Severidad: MEDIA
Fecha de publicación: 09/01/2025
Fecha de última actualización: 24/09/2025
Se ha encontrado una vulnerabilidad clasificada como problemática en langhsu Mblog Blog System 3.5.0. Esta vulnerabilidad afecta a una funcionalidad desconocida del archivo /search del componente Search Bar. La manipulación del argumento kw provoca cross site scripting. El ataque se puede ejecutar 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 kernel de Linux (CVE-2024-56788)
Severidad: MEDIA
Fecha de publicación: 11/01/2025
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: oa_tc6: arregla la condición de ejecución de tx skb entre punteros de referencia Hay dos punteros skb para administrar los tx skb en cola desde la pila n/w. El puntero waiting_tx_skb apunta al tx skb que necesita ser procesado y el puntero progress_tx_skb apunta al tx skb que está siendo procesado. El hilo SPI prepara los fragmentos de datos de tx desde el tx skb apuntado por el puntero progress_tx_skb. Cuando se procesa el tx skb apuntado por progress_tx_skb, el tx skb apuntado por progress_tx_skb se asigna a progress_tx_skb y el puntero waiting_tx_skb se asigna con NULL. Siempre que haya un nuevo skb tx de la pila n/w, se asignará al puntero waiting_tx_skb si es NULL. Puesta en cola y procesamiento de un skb tx gestionado en dos subprocesos diferentes. Considere un escenario donde el subproceso SPI procesó un going_tx_skb y mueve el siguiente skb tx del puntero waiting_tx_skb al puntero going_tx_skb sin hacer ninguna comprobación NULL. En este momento, si el puntero waiting_tx_skb es NULL, entonces el puntero going_tx_skb también se asigna con NULL. Después de eso, si un nuevo skb tx se asigna al puntero waiting_tx_skb por la pila n/w y existe la posibilidad de sobrescribir el puntero skb tx con NULL en el subproceso SPI. Finalmente, uno de los skb tx quedará como sin gestionar, lo que resultará en la pérdida de paquetes y pérdida de memoria. - Considere el siguiente escenario donde el TXC informado de la transferencia anterior es 10 y progress_tx_skb contiene una trama Ethernet de transmisión que se puede transportar en 20 TXC y waiting_tx_skb sigue siendo NULL. tx_credits = 10; /* 21 se completan en la transferencia anterior */ progress_tx_skb = 20; waiting_tx_skb = NULL; /* Sigue siendo NULL */ - Entonces, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) se vuelve verdadero. - Después de oa_tc6_prepare_spi_tx_buf_for_tx_skbs() progress_tx_skb = 10; waiting_tx_skb = NULL; /* Sigue siendo NULL */ - Realizar transferencia SPI. - Procesar el búfer de recepción SPI para obtener el TXC de los pies de página. - Ahora supongamos que los 21 TXC previamente completados se liberan, por lo que estamos listos para transportar los siguientes 10 fragmentos de tx restantes desde progress_tx_skb. tx_credits = 21; progress_tx_skb = 10; waiting_tx_skb = NULL; - Entonces, (tc6->ongoing_tx_skb || tc6->waiting_tx_skb) se vuelve verdadero nuevamente. - En oa_tc6_prepare_spi_tx_buf_for_tx_skbs() progress_tx_skb = NULL; waiting_tx_skb = NULL; - Ahora, el siguiente caso malo podría ocurrir, Thread1 (oa_tc6_start_xmit) Thread2 (oa_tc6_spi_thread_handler) --------------------------- ----------------------------------- - si waiting_tx_skb es NULL - si going_tx_skb es NULL - going_tx_skb = waiting_tx_skb - waiting_tx_skb = skb - waiting_tx_skb = NULL ... - going_tx_skb = NULL - si waiting_tx_skb es NULL - waiting_tx_skb = skb Para superar el problema anterior, proteja el movimiento de la referencia tx skb del puntero waiting_tx_skb al puntero going_tx_skb y asigne el nuevo tx skb al puntero waiting_tx_skb, de modo que el otro hilo no pueda acceder al puntero waiting_tx_skb hasta que el hilo actual complete el movimiento de la referencia tx skb de manera segura.
-
Vulnerabilidad en kernel de Linux (CVE-2024-57793)
Severidad: MEDIA
Fecha de publicación: 11/01/2025
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virt: tdx-guest: Just leak decrypted memory on unrecoverable errors En las máquinas virtuales CoCo, es posible que el host no confiable haga que set_memory_decrypted() falle de modo que se devuelva un error y se comparta la memoria resultante. Los llamadores deben tener cuidado de gestionar estos errores para evitar devolver memoria descifrada (compartida) al asignador de páginas, lo que podría provocar problemas funcionales o de seguridad. Filtra la memoria descifrada cuando set_memory_decrypted() falla y no necesitas imprimir un error ya que set_memory_decrypted() llamará a WARN_ONCE().
-
Vulnerabilidad en kernel de Linux (CVE-2024-57806)
Severidad: MEDIA
Fecha de publicación: 11/01/2025
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: se corrige el error de atomicidad de transacciones al habilitar cuotas simples. Establezca el bit de incompatibilidad de squota antes de confirmar la transacción que habilita la función. Con la configuración CONFIG_BTRFS_ASSERT habilitada, se produce un error de afirmación con respecto a la función de cuota simple. [5.596534] Error de afirmación: btrfs_fs_incompat(fs_info, SIMPLE_QUOTA), en fs/btrfs/qgroup.c:365 [5.597098] ------------[ corte aquí ]------------ [5.597371] ¡ERROR del kernel en fs/btrfs/qgroup.c:365! [5.597946] CPU: 1 UID: 0 PID: 268 Comm: montaje No contaminado 6.13.0-rc2-00031-gf92f4749861b #146 [5.598450] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 [5.599008] RIP: 0010:btrfs_read_qgroup_config+0x74d/0x7a0 [5.604303] [5.605230] ? btrfs_read_qgroup_config+0x74d/0x7a0 [5.605538] ? asm_exc_invalid_op+0x1f/0x30 [5.606441] ? btrfs_read_qgroup_config+0x74d/0x7a0 [5.606741] ? btrfs_read_qgroup_config+0x74d/0x7a0 [5.607038] ? intentar_activar+0x317/0x760 [5.607286] abrir_ctree+0xd9c/0x1710 [5.607509] btrfs_get_tree+0x58a/0x7e0 [5.608002] vfs_get_tree+0x2e/0x100 [5.608224] montaje_fc+0x16/0x60 [5.608420] btrfs_get_tree+0x2f8/0x7e0 [5.608897] vfs_get_tree+0x2e/0x100 [5.609121] montaje_ruta+0x4c8/0xbc0 [5.609538] __x64_sys_mount+0x10d/0x150 El problema se puede reproducir fácilmente utilizando el siguiente reproductor: root@q:linux# cat repro.sh set -e mkfs.btrfs -q -f /dev/sdb mount /dev/sdb /mnt/btrfs btrfs quota enable -s /mnt/btrfs umount /mnt/btrfs mount /dev/sdb /mnt/btrfs El problema es que al habilitar cuotas, en btrfs_quota_enable(), configuramos BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE en fs_info->qgroup_flags y lo persistimos en la raíz de cuotas en el elemento con la clave BTRFS_QGROUP_STATUS_KEY, pero solo configuramos el bit de incompatibilidad BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA después de que confirmamos la transacción utilizada para habilitar la cuota simple. Esto significa que si después de esa confirmación de transacción desmontamos el sistema de archivos sin iniciar y confirmar ninguna otra transacción, o tenemos un corte de energía, la próxima vez que montemos el sistema de archivos encontraremos el indicador BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE establecido en el elemento con la clave BTRFS_QGROUP_STATUS_KEY pero no encontraremos el bit de incompatibilidad BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA establecido en el superbloque, lo que desencadena un error de aserción en: btrfs_read_qgroup_config() -> qgroup_read_enable_gen() Para solucionar este problema, configure el indicador BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA inmediatamente después de configurar BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE. Esto garantiza que ambos indicadores se vacíen en el disco dentro de la misma transacción.
-
Vulnerabilidad en kernel de Linux (CVE-2024-57838)
Severidad: ALTA
Fecha de publicación: 11/01/2025
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/entry: Marcar entradas de IRQ para corregir advertencias del depósito de pila El depósito de pila filtra todo lo que esté fuera del contexto de interrupción superior como una parte poco interesante o irrelevante de los seguimientos de pila. Esto ayuda con la desduplicación del seguimiento de pila, evitando una explosión de seguimientos de pila guardados que comparten la misma ruta de código de contexto de IRQ pero que se originan en diferentes puntos interrumpidos aleatoriamente, agotando eventualmente el depósito de pila. El filtrado utiliza in_irqentry_text() para identificar funciones dentro de las secciones .irqentry.text y .softirqentry.text, que luego se convierten en las últimas entradas del seguimiento de pila que se guardan. Si bien __do_softirq() se coloca en la sección .softirqentry.text por código común, completar .irqentry.text es específico de la arquitectura. Actualmente, la sección .irqentry.text en s390 está vacía, lo que impide el filtrado y la deduplicación del depósito de pila y podría generar advertencias como: El depósito de pila alcanzó la capacidad límite ADVERTENCIA: CPU: 0 PID: 286113 en lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8 con PREEMPT y KASAN habilitados. Solucione esto moviendo los controladores de interrupción IO/EXT de .kprobes.text a la sección .irqentry.text y actualizando la lista negra de kprobes para incluir la sección .irqentry.text. Esto se hace solo para interrupciones asincrónicas y explícitamente no para verificaciones de programa, que son sincrónicas y donde es importante preservar el contexto más allá de la verificación de programa. A pesar de que las verificaciones de máquina están algo en el medio, son extremadamente raras y preservar el contexto cuando sea posible también es valioso. Los SVC y las interrupciones de reinicio no son relevantes, uno siempre se encuentra en el límite del espacio del usuario y el otro es algo que ocurre una sola vez. El filtrado de entradas IRQ también se utiliza de manera opcional en el gráfico de funciones ftrace, donde se aplica la misma lógica.
-
Vulnerabilidad en kernel de Linux (CVE-2024-57843)
Severidad: MEDIA
Fecha de publicación: 11/01/2025
Fecha de última actualización: 24/09/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio-net: se corrige el desbordamiento dentro de virtnet_rq_alloc Cuando el fragmento acaba de obtener una página, puede provocar una regresión en la máquina virtual. Especialmente si el valor de sysctl net.core.high_order_alloc_disable es 1, entonces el fragmento siempre obtiene una página cuando se rellena. Lo que podría provocar fallos fiables o fallos de SCP (enviar un archivo de 100 M de tamaño a la máquina virtual). El problema es que virtnet_rq_dma ocupa 16 bytes al principio de un nuevo fragmento. Cuando el tamaño del fragmento es mayor que PAGE_SIZE, todo está bien. Sin embargo, si el fragmento es solo una página y el tamaño total del búfer y virtnet_rq_dma es mayor que una página, puede producirse un desbordamiento. El commit f9dac92ba908 ("virtio_ring: habilitar el modo premapeado sea cual sea el uso de_dma_api") introdujo este problema. Y revertimos algunas confirmaciones para solucionar este problema en la última versión de Linux. Ahora intentamos habilitarlo y solucionar este error directamente. Aquí, cuando el tamaño del fragmento no es suficiente, reducimos la longitud del búfer para solucionar este problema.
-
Vulnerabilidad en D-Link DIR-823X 240126/240802 (CVE-2025-0492)
Severidad: ALTA
Fecha de publicación: 15/01/2025
Fecha de última actualización: 24/09/2025
Se ha encontrado una vulnerabilidad en D-Link DIR-823X 240126/240802 y se ha clasificado como crítica. Esta vulnerabilidad afecta a la función FUN_00412244. La manipulación provoca la desreferenciación de puntero null. El ataque se puede ejecutar de forma remota. El exploit se ha hecho público y puede utilizarse.
-
Vulnerabilidad en QHora (CVE-2024-50390)
Severidad: ALTA
Fecha de publicación: 07/03/2025
Fecha de última actualización: 24/09/2025
Se ha informado de una vulnerabilidad de inyección de comandos que afecta a QHora. Si se explota, la vulnerabilidad podría permitir a atacantes remotos ejecutar comandos arbitrarios. Ya hemos corregido la vulnerabilidad en la siguiente versión: QuRouter 2.4.5.032 y posteriores
-
Vulnerabilidad en QHora (CVE-2024-53700)
Severidad: MEDIA
Fecha de publicación: 07/03/2025
Fecha de última actualización: 24/09/2025
Se ha informado de una vulnerabilidad de inyección de comandos que afecta a QHora. Si se explota, la vulnerabilidad podría permitir que atacantes remotos que hayan obtenido acceso de administrador ejecuten comandos arbitrarios. Ya hemos corregido la vulnerabilidad en la siguiente versión: QuRouter 2.4.6.028 y posteriores
-
Vulnerabilidad en QHora (CVE-2024-13087)
Severidad: BAJA
Fecha de publicación: 06/06/2025
Fecha de última actualización: 24/09/2025
Se ha reportado una vulnerabilidad de inyección de comandos que afecta a QHora. Si un atacante obtiene acceso a la red local y también ha obtenido una cuenta de administrador, puede explotar la vulnerabilidad para ejecutar comandos arbitrarios. Ya hemos corregido la vulnerabilidad en la siguiente versión: QuRouter 2.4.6.028 y posteriores.
-
Vulnerabilidad en QHora (CVE-2024-13088)
Severidad: MEDIA
Fecha de publicación: 06/06/2025
Fecha de última actualización: 24/09/2025
Se ha reportado una vulnerabilidad de autenticación incorrecta que afecta a QHora. Si un atacante obtiene acceso a la red local, puede explotar la vulnerabilidad para comprometer la seguridad del sistema. Ya hemos corregido la vulnerabilidad en la siguiente versión: QuRouter 2.5.0.140 y posteriores.
-
Vulnerabilidad en Adobe Connect (CVE-2025-27203)
Severidad: CRÍTICA
Fecha de publicación: 08/07/2025
Fecha de última actualización: 24/09/2025
Las versiones 24.0 y anteriores de Adobe Connect se ven afectadas por una vulnerabilidad de deserialización de datos no confiables que podría provocar la ejecución de código arbitrario por parte de un atacante. La explotación de este problema requiere la interacción del usuario y se modifica el alcance.
-
Vulnerabilidad en Mattermost Confluence (CVE-2025-49221)
Severidad: BAJA
Fecha de publicación: 11/08/2025
Fecha de última actualización: 24/09/2025
La versión <1.5.0 del complemento Mattermost Confluence no logra imponer la autenticación del usuario en la instancia de Mattermost, lo que permite que atacantes no autenticados accedan a los detalles de suscripción sin realizar una llamada API al endpoint de suscripción GET.
-
Vulnerabilidad en Nginx Proxy Manager v2.12.3 (CVE-2025-50579)
Severidad: MEDIA
Fecha de publicación: 19/08/2025
Fecha de última actualización: 24/09/2025
Una configuración incorrecta de CORS en Nginx Proxy Manager v2.12.3 permite que dominios no autorizados accedan a datos confidenciales, en particular tokens JWT, debido a una validación incorrecta del encabezado Origin. Esta configuración incorrecta permite a los atacantes interceptar tokens mediante un simple script del navegador y exfiltrarlos a un servidor remoto controlado por el atacante, lo que podría provocar acciones no autorizadas dentro de la aplicación.
-
Vulnerabilidad en Easy Hosting Control Panel EHCP v20.04.1.b (CVE-2025-50926)
Severidad: MEDIA
Fecha de publicación: 19/08/2025
Fecha de última actualización: 24/09/2025
Se descubrió que Easy Hosting Control Panel EHCP v20.04.1.b contenía una vulnerabilidad de inyección SQL a través del parámetro id en la función Listar todas las direcciones de correo electrónico.
-
Vulnerabilidad en official ProFTPD 1.3.3c source tarball (CVE-2010-20103)
Severidad: CRÍTICA
Fecha de publicación: 20/08/2025
Fecha de última actualización: 24/09/2025
Una puerta trasera maliciosa se integró en official ProFTPD 1.3.3c source tarball, distribuido entre el 28 de noviembre y el 2 de diciembre de 2010. Esta puerta trasera implementa un disparador de comandos FTP oculto que, al ser invocado, provoca que el servidor ejecute comandos de shell arbitrarios con privilegios de root. Esto permite a atacantes remotos no autenticados ejecutar cualquier comando del sistema operativo en el host del servidor FTP.
-
Vulnerabilidad en Easy Hosting Control Panel (EHCP) 20.04.1.b (CVE-2025-50860)
Severidad: MEDIA
Fecha de publicación: 21/08/2025
Fecha de última actualización: 24/09/2025
La inyección SQL en la función listdomains en Easy Hosting Control Panel (EHCP) 20.04.1.b permite a atacantes autenticados acceder o manipular el contenido de la base de datos a través del parámetro POST arananalan.
-
Vulnerabilidad en Easy Hosting Control Panel 20.04.1.b (CVE-2025-50858)
Severidad: MEDIA
Fecha de publicación: 22/08/2025
Fecha de última actualización: 24/09/2025
La ejecución de cross-site scripting reflejado en la función Listar bases de datos MySQL en Easy Hosting Control Panel (EHCP) 20.04.1.b permite a atacantes autenticados ejecutar JavaScript arbitrario a través del parámetro de acción.
-
Vulnerabilidad en Easy Hosting Control Panel 20.04.1.b (CVE-2025-50859)
Severidad: MEDIA
Fecha de publicación: 22/08/2025
Fecha de última actualización: 24/09/2025
La ejecución de cross-site scripting reflejado en la función Cambiar plantilla en Easy Hosting Control Panel (EHCP) 20.04.1.b permite a atacantes autenticados ejecutar JavaScript arbitrario a través del parámetro de plantilla.