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 Net::Dropbox::API (CVE-2024-58036)
Severidad: MEDIA
Fecha de publicación: 05/04/2025
Fecha de última actualización: 10/04/2025
Net::Dropbox::API 1.9 y versiones anteriores para Perl utilizan la función rand() como fuente predeterminada de entropía, la cual no es criptográficamente segura para las funciones criptográficas. En concreto, Net::Dropbox::API utiliza la librería Data::Random, que indica específicamente que es útil principalmente para programas de prueba. Data::Random utiliza la función rand().
-
Vulnerabilidad en WebService::Xero (CVE-2024-52322)
Severidad: MEDIA
Fecha de publicación: 05/04/2025
Fecha de última actualización: 10/04/2025
WebService::Xero 0.11 y versiones anteriores para Perl utilizan la función rand() como fuente predeterminada de entropía, la cual no es criptográficamente segura para funciones criptográficas. Específicamente, WebService::Xero utiliza la librería Data::Random, que indica específicamente que es útil principalmente para programas de prueba. Data::Random utiliza la función rand().
-
Vulnerabilidad en kernel de Linux (CVE-2025-22009)
Severidad: MEDIA
Fecha de publicación: 08/04/2025
Fecha de última actualización: 10/04/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulator: dummy: force synchronous sondeo a veces obtengo una desreferencia de puntero NULL en el momento del arranque en kobject_get() con la siguiente pila de llamadas: anatop_regulator_probe() devm_regulator_register() regulator_register() regulator_resolve_supply() kobject_get() Colocando algunas sentencias BUG_ON() adicionales pude verificar que esto se genera porque el sondeo del controlador del regulador 'dummy' no se completa ('dummy_regulator_rdev' sigue siendo NULL). En el depurador JTAG puedo ver que dummy_regulator_probe() y anatop_regulator_probe() pueden ser ejecutados por diferentes subprocesos del kernel (kworker/u4:*). No he investigado más si esto se puede cambiar o si hay otras posibilidades de forzar la sincronización entre estas dos rutinas de sondeo. Por otro lado, no espero mucha penalización en el tiempo de arranque al sondear el regulador 'dummy' sincrónicamente.
-
Vulnerabilidad en kernel de Linux (CVE-2025-22010)
Severidad: MEDIA
Fecha de publicación: 08/04/2025
Fecha de última actualización: 10/04/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/hns: Se corrige el bloqueo suave durante el bucle de páginas bt. El controlador ejecuta un bucle for al asignar páginas bt y mapearlas con páginas de búfer. Al asignar un búfer grande (por ejemplo, un MR de más de 100 GB), puede requerirse un número considerable de bucles. Esto provocará un bloqueo suave: watchdog: BUG: bloqueo suave - ¡CPU n.º 27 bloqueada durante 22 s! ... Rastreo de llamadas: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 perro guardián: ERROR: bloqueo suave - ¡CPU n.º 35 bloqueada durante 23 s! ... Seguimiento de llamadas: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bc Agregue un cond_resched() para corregir el bloqueo suave durante estos bucles. Para no afectar el rendimiento de asignación de un búfer de tamaño normal, establezca el recuento de bucles de un MR de 100 GB como el umbral para llamar a cond_resched().
-
Vulnerabilidad en kernel de Linux (CVE-2025-22011)
Severidad: MEDIA
Fecha de publicación: 08/04/2025
Fecha de última actualización: 10/04/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: dts: bcm2711: Reparar xHCI power-domain Durante las pruebas s2idle en Raspberry CM4, el firmware de la VPU siempre falla en xHCI power-domain resume: root@raspberrypi:/sys/power# echo freeze > state [ 70.724347] xhci_suspend finished [ 70.727730] xhci_plat_suspend finished [ 70.755624] bcm2835-power bcm2835-power: Apagar grafx [ 70.761127] USB: Establecer la energía en 0 [ 74.653040] USB: No se pudo establecer la energía en 1 (-110) Esto parece deberse al uso mixto de raspberrypi-power y bcm2835-power al mismo tiempo. Por lo tanto, evite el uso del controlador de dominio de energía del firmware VPU, lo que evita el bloqueo de la VPU.
-
Vulnerabilidad en kernel de Linux (CVE-2025-22012)
Severidad: MEDIA
Fecha de publicación: 08/04/2025
Fecha de última actualización: 10/04/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW en apps_smmu". Hay informes de que la coherencia de la caché del pagetable walker no es constante en todos los dispositivos SDM845/850, lo que provoca bloqueos y reinicios. Funciona correctamente en algunos dispositivos (como el Dragonboard 845c, pero no tanto en el Lenovo Yoga C630). Lamentablemente, esto parece ser un fallo en el desarrollo del firmware, ya que, probablemente en algún lugar de la vasta pila de hipervisores, se introdujo un cambio para adaptarlo después del lanzamiento inicial del software (que suele servir como base para los productos). Revertir el cambio para evitar conjeturas adicionales sobre fallos. Esto revierte el commit 6b31a9744b8726c69bb0af290f8475a368a4b805.
-
Vulnerabilidad en kernel de Linux (CVE-2025-22014)
Severidad: MEDIA
Fecha de publicación: 08/04/2025
Fecha de última actualización: 10/04/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: pdr: Corrige el posible bloqueo cuando algún proceso de cliente A llama a pdr_add_lookup() para agregar la búsqueda para el servicio y realiza el trabajo del localizador de programación, más tarde un proceso B obtiene un nuevo paquete de servidor que indica que el localizador está activo y llama a pdr_locator_new_server() que finalmente establece pdr->locator_init_complete en verdadero, lo que hace que el proceso A vea y tome el bloqueo de lista y consulte la lista de dominios, pero se agotará el tiempo de espera debido al bloqueo, ya que la respuesta se pondrá en cola en el mismo qmi->wq y se ordenará workqueue y el proceso B no puede completar el nuevo trabajo de solicitud del servidor debido al bloqueo en el bloqueo de lista. Arréglelo eliminando la iteración de lista innecesaria, ya que la iteración de lista ya se está realizando dentro del trabajo del localizador, así que evítelo aquí y simplemente llame a schedule_work() aquí. Proceso A Proceso B process_scheduled_works() pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s error en la espera de la transacción para obtener la lista de dominios: %d\n", req->service_name, ret); Registro de errores de tiempo de espera debido a un bloqueo: "PDR: tms/servreg get domain list txn wait fallo: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110" Gracias a Bjorn y Johan por informarme que esta confirmación también corrige una regresión de audio al usar el pd-mapper dentro del kernel, ya que eso hace que sea más fácil alcanzar esta ejecución. [1]