Boletín de vulnerabilidades
Vulnerabilidades con productos recientemente documentados:
No hay vulnerabilidades nuevas para los productos a los que está suscrito.
Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:
-
Vulnerabilidad en la API REST en Zoho ManageEngine ADSelfService Plus (CVE-2021-40539)
Severidad: CRÍTICA
Fecha de publicación: 07/09/2021
Fecha de última actualización: 05/11/2025
Zoho ManageEngine ADSelfService Plus versiones 6113 y anteriores, es vulnerable a una omisión de autenticación de la API REST con una ejecución de código remota resultante
-
Vulnerabilidad en iOS y iPadOS (CVE-2023-42824)
Severidad: ALTA
Fecha de publicación: 04/10/2023
Fecha de última actualización: 05/11/2025
El problema se solucionó con controles mejorados. Este problema se solucionó en iOS 16.7.1 y iPadOS 16.7.1. Un atacante local podría aumentar sus privilegios. Apple tiene conocimiento de un informe que indica que este problema puede haber sido explotado activamente en versiones de iOS anteriores a iOS 16.6.
-
Vulnerabilidad en tvOS, iOS, iPadOS, macOS Sonoma, Safari, macOS Ventura y macOS Monterey (CVE-2024-23222)
Severidad: ALTA
Fecha de publicación: 23/01/2024
Fecha de última actualización: 05/11/2025
Se solucionó un problema de confusión de tipos con comprobaciones mejoradas. Este problema se solucionó en tvOS 17.3, iOS 17.3 y iPadOS 17.3, macOS Sonoma 14.3, iOS 16.7.5 y iPadOS 16.7.5, Safari 17.3, macOS Ventura 13.6.4, macOS Monterey 12.7.3. El procesamiento de contenido web creado con fines malintencionados puede provocar la ejecución de código arbitrario. Apple tiene conocimiento de un informe que indica que este problema puede haber sido aprovechado.
-
Vulnerabilidad en Delta Electronics (CVE-2024-28891)
Severidad: ALTA
Fecha de publicación: 21/03/2024
Fecha de última actualización: 05/11/2025
Existe una vulnerabilidad de inyección SQL en el script Handler_CFG.ashx.
-
Vulnerabilidad en Delta Electronics (CVE-2024-23494)
Severidad: ALTA
Fecha de publicación: 21/03/2024
Fecha de última actualización: 05/11/2025
Existe una vulnerabilidad de inyección SQL en GetDIAE_unListParameters.
-
Vulnerabilidad en Delta Electronics (CVE-2024-23975)
Severidad: ALTA
Fecha de publicación: 21/03/2024
Fecha de última actualización: 05/11/2025
Existe una vulnerabilidad de inyección SQL en GetDIAE_slogListParameters.
-
Vulnerabilidad en Delta Electronics (CVE-2024-25567)
Severidad: ALTA
Fecha de publicación: 21/03/2024
Fecha de última actualización: 05/11/2025
Es posible un ataque de path traversal, que escribe fuera del directorio previsto y puede acceder a información confidencial. Si se especifica un nombre de archivo que ya existe en el sistema de archivos, se sobrescribirá el archivo original.
-
Vulnerabilidad en Delta Electronics (CVE-2024-28040)
Severidad: ALTA
Fecha de publicación: 21/03/2024
Fecha de última actualización: 05/11/2025
Existe una vulnerabilidad de inyección SQL en GetDIAE_astListParameters.
-
Vulnerabilidad en Delta Electronics (CVE-2024-28045)
Severidad: MEDIA
Fecha de publicación: 21/03/2024
Fecha de última actualización: 05/11/2025
Una neutralización inadecuada de la entrada dentro del producto afectado podría dar lugar a cross-site scripting.
-
Vulnerabilidad en Delta Electronics (CVE-2024-28171)
Severidad: ALTA
Fecha de publicación: 21/03/2024
Fecha de última actualización: 05/11/2025
Es posible realizar un ataque de path traversal y escribir fuera del directorio deseado. Si se especifica un nombre de archivo que ya existe en el sistema de archivos, se sobrescribirá el archivo original.
-
Vulnerabilidad en Pimcore (CVE-2024-29197)
Severidad: MEDIA
Fecha de publicación: 26/03/2024
Fecha de última actualización: 05/11/2025
Pimcore es una plataforma de gestión de experiencias y datos de código abierto. Cualquier llamada con el argumento de consulta `?pimcore_preview=true` permite ver sitios no publicados. En versiones anteriores de Pimcore, la información de la sesión se propagaba a las vistas previas, por lo que solo un usuario que había iniciado sesión podía abrir una vista previa. Esto ya no se aplica. Las vistas previas están abiertas a cualquier usuario y con sólo un indicio de un enlace restringido se puede obtener acceso a posible información confidencial o inédita. Esta vulnerabilidad se solucionó en 11.2.2 y 11.1.6.1.
-
Vulnerabilidad en kernel de Linux (CVE-2024-36971)
Severidad: ALTA
Fecha de publicación: 10/06/2024
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: fix __dst_negative_advice() race __dst_negative_advice() no aplica las reglas adecuadas de RCU cuando se debe borrar sk->dst_cache, lo que genera una posible UAF. Las reglas de RCU son que primero debemos borrar sk->sk_dst_cache y luego llamar a dst_release(old_dst). Tenga en cuenta que sk_dst_reset(sk) implementa este protocolo correctamente, mientras que __dst_negative_advice() utiliza el orden incorrecto. Dado que ip6_negative_advice() tiene una lógica especial contra RTF_CACHE, esto significa que cada uno de los tres ->negative_advice() métodos existentes debe realizar sk_dst_reset() ellos mismos. Tenga en cuenta que la verificación de NULL dst está centralizada en __dst_negative_advice(), no es necesario duplicarla en varias devoluciones de llamada. Muchas gracias a Clement Lecigne por dar seguimiento a este problema. Este antiguo error se hizo visible después de la confirmación culpada, utilizando sockets UDP.
-
Vulnerabilidad en Online-Bookstore-Project-In-PHP v1.0 (CVE-2024-37848)
Severidad: ALTA
Fecha de publicación: 17/06/2024
Fecha de última actualización: 05/11/2025
Vulnerabilidad de inyección SQL en Online-Bookstore-Project-In-PHP v1.0 permite a un atacante local ejecutar código arbitrario a través del componente admin_delete.php.
-
Vulnerabilidad en DCME-320 v7.4.12.90 (CVE-2024-51115)
Severidad: CRÍTICA
Fecha de publicación: 05/11/2024
Fecha de última actualización: 05/11/2025
Se descubrió que DCME-320 v7.4.12.90 contenía una vulnerabilidad de inyección de comandos.
-
Vulnerabilidad en 115cms (CVE-2024-11491)
Severidad: MEDIA
Fecha de publicación: 20/11/2024
Fecha de última actualización: 05/11/2025
Se ha detectado una vulnerabilidad en 115cms hasta 20240807. Se ha calificado como problemática. Este problema afecta a algunas funciones desconocidas del archivo /index.php/admin/web/useradmin.html. La manipulación del argumento ks provoca cross site scripting. El ataque puede ejecutarse de forma remota. El exploit se ha revelado al público y puede utilizarse. Se contactó al proveedor con anticipación sobre esta revelación, pero no respondió de ninguna manera.
-
Vulnerabilidad en IBM Security Guardium 11.5 (CVE-2024-49336)
Severidad: MEDIA
Fecha de publicación: 19/12/2024
Fecha de última actualización: 05/11/2025
IBM Security Guardium 11.5 es vulnerable a server-side request forgery (SSRF). Esto puede permitir que un atacante autenticado envíe solicitudes no autorizadas desde el sistema, lo que podría provocar la enumeración de la red o facilitar otros ataques.
-
Vulnerabilidad en Apereo CAS 5.2.6 (CVE-2025-3984)
Severidad: BAJA
Fecha de publicación: 27/04/2025
Fecha de última actualización: 05/11/2025
Se encontró una vulnerabilidad en Apereo CAS 5.2.6, clasificada como crítica. Este problema afecta a la función saveService del archivo cas-5.2.6\webapp-mgmt\cas-management-webapp-support\src\main\java\org\apereo\cas\mgmt\services\web\RegisteredServiceSimpleFormController.java del componente Groovy Code Handler. La manipulación provoca la inyección de código. El ataque puede ejecutarse en remoto. Es un ataque de complejidad bastante alta. Parece difícil de explotar. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
-
Vulnerabilidad en Apereo CAS 5.2.6 (CVE-2025-3985)
Severidad: MEDIA
Fecha de publicación: 27/04/2025
Fecha de última actualización: 05/11/2025
Se encontró una vulnerabilidad en Apereo CAS 5.2.6. Se ha clasificado como problemática. Afecta a la función ResponseEntity del archivo cas-5.2.6\webapp-mgmt\cas-management-webapp-support\src\main\java\org\apereo\cas\mgmt\services\web\ManageRegisteredServicesMultiActionController.java. La manipulación del argumento "Query" genera una complejidad ineficiente en las expresiones regulares. Es posible iniciar el ataque de forma remota. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
-
Vulnerabilidad en Apereo CAS 5.2.6 (CVE-2025-3986)
Severidad: MEDIA
Fecha de publicación: 27/04/2025
Fecha de última actualización: 05/11/2025
Se encontró una vulnerabilidad en Apereo CAS 5.2.6. Se ha declarado problemática. Esta vulnerabilidad afecta al código desconocido del archivo cas-5.2.6\core\cas-server-core-configuration-metadata-repository\src\main\java\org\apereo\cas\metadata\rest\CasConfigurationMetadataServerController.java. La manipulación del argumento Name genera una complejidad ineficiente en las expresiones regulares. El ataque puede iniciarse remotamente. Se ha hecho público el exploit y puede que sea utilizado. Se contactó al proveedor con antelación para informarle sobre esta divulgación, pero no respondió.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23140)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: pci_endpoint_test: evitar el problema de las interrupciones restantes después del error request_irq Después de que devm_request_irq() falla con un error en pci_endpoint_test_request_irq(), se llama a pci_endpoint_test_free_irq_vectors() asumiendo que se han liberado todas las IRQ. Sin embargo, algunas IRQ solicitadas permanecen sin liberar, por lo que aún quedan entradas /proc/irq/* restantes y esto genera un WARN() con el siguiente mensaje: remove_proc_entry: eliminando el directorio no vacío 'irq/30', filtrando al menos 'pci-endpoint-test.0' ADVERTENCIA: CPU: 0 PID: 202 en fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c Para resolver este problema, establezca el número de IRQ restantes en test->num_irqs y libere las IRQ con anticipación llamando a pci_endpoint_test_release_irq(). [kwilczynski: registro de confirmaciones]
-
Vulnerabilidad en kernel de Linux (CVE-2025-23141)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86: Adquisición de SRCU en KVM_GET_MP_STATE para proteger los accesos a la memoria del invitado. Adquisición de un bloqueo en kvm->srcu cuando el espacio de usuario obtiene el estado MP para gestionar un caso extremo en el que la "aceptación" de eventos APIC, es decir, el procesamiento de INIT o SIPI pendientes, puede desencadenar accesos a la memoria del invitado. Si la vCPU está en L2 con INIT *y* una solicitud TRIPLE_FAULT pendiente, obtener el estado MP activará una salida de máquina virtual anidada mediante ->check_nested_events(), y la emulación de la salida de máquina virtual anidada puede acceder a la memoria del invitado. El splat fue alcanzado originalmente por syzkaller en un kernel interno de Google, y reproducido en un kernel ascendente hackeando la autoprueba triple_fault_event_test para rellenar un INIT pendiente, almacenar un MSR en VM-Exit (para generar un acceso a memoria en VMX), y hacer vcpu_mp_state_get() para activar el escenario. ============================== ADVERTENCIA: uso sospechoso de RCU 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 No contaminado ----------------------------- include/linux/kvm_host.h:1058 ¡uso sospechoso de rcu_dereference_check()! Otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 1 bloqueo mantenido por triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, en: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm] seguimiento de pila: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev No contaminado 6.14.0-rc3-b112d356288b-vmx #3 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Seguimiento de llamadas: dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53
-
Vulnerabilidad en kernel de Linux (CVE-2025-23142)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: detectar y prevenir referencias a un transporte liberado en sendmsg. sctp_sendmsg() reutiliza asociaciones y transportes cuando es posible mediante una búsqueda basada en el endpoint del socket y la dirección de destino del mensaje. A continuación, sctp_sendmsg_to_asoc() establece el transporte seleccionado en todos los fragmentos de mensaje que se enviarán. Existe una posible condición de ejecución si otro subproceso activa la eliminación de ese transporte seleccionado, por ejemplo, desvinculando explícitamente una dirección con setsockopt(SCTP_SOCKOPT_BINDX_REM), después de configurar los fragmentos y antes de enviar el mensaje. Esto puede ocurrir si el búfer de envío está lleno, durante el periodo en que el subproceso emisor libera temporalmente el bloqueo del socket en sctp_wait_for_sndbuf(). Esto provoca que el acceso a los datos de transporte en sctp_outq_select_transport(), al vaciar la cola de salida de la asociación, resulte en una lectura de use-after-free. Este cambio evita este escenario al indicar sctp_transport_free() la liberación del transporte, etiquetándolo como "muerto". Para ello, el parche restaura el bit "muerto" en la estructura sctp_transport, que se eliminó en el commit 47faa1e4c50e ("sctp: eliminar el campo muerto de sctp_transport"). Si el hilo emisor ha liberado el bloqueo del socket en sctp_wait_for_sndbuf(), el bit se vuelve a comprobar tras volver a adquirir el bloqueo para detectar la eliminación. Esto se realiza manteniendo una referencia al transporte para evitar que se libere durante el proceso. Si el transporte se eliminó mientras se liberaba el bloqueo del socket, sctp_sendmsg_to_asoc() devolverá -EAGAIN para que el espacio de usuario pueda reintentar el envío. El error fue detectado por una instancia privada de syzbot (consulte el informe de errores [1] y el reproductor de C que lo activa [2]).
-
Vulnerabilidad en kernel de Linux (CVE-2025-23143)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: Fix null-ptr-deref por sock_lock_init_class_and_name() y rmmod. Cuando ejecuté la reproducción [0] y esperé unos segundos, observé dos símbolos LOCKDEP: una advertencia seguida inmediatamente por un null-ptr-deref. [1] Pasos de reproducción: 1) Montar CIFS 2) Agregar una regla de iptables para descartar los paquetes FIN entrantes para CIFS 3) Desmontar CIFS 4) Descargar el módulo CIFS 5) Eliminar la regla de iptables En el paso 3), el módulo CIFS llama a sock_release() para el socket TCP subyacente y regresa rápidamente. Sin embargo, el socket permanece en FIN_WAIT_1 porque los paquetes FIN entrantes se descartan. En este punto, el refcnt del módulo es 0 mientras el socket sigue activo, por lo que el siguiente comando rmmod tiene éxito. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0 Esto indica una discrepancia entre la duración del módulo CIFS y el socket TCP subyacente. Incluso después de que CIFS invoque sock_release() y este regrese, el socket TCP no se cierra inmediatamente para cerrar la conexión correctamente. Si bien esto generalmente funciona bien, causa un problema con LOCKDEP, ya que CIFS asigna una clase de bloqueo diferente al sk->sk_lock del socket TCP mediante sock_lock_init_class_and_name(). Una vez que se procesa un paquete entrante para el socket o se activa un temporizador, se adquiere sk->sk_lock. Luego, LOCKDEP verifica el contexto de bloqueo en check_wait_context(), donde se llama a hlock_class() para recuperar la clase de bloqueo. Sin embargo, dado que el módulo ya se ha descargado, hlock_class() registra una advertencia y devuelve NULL, lo que activa la desreferencia null-ptr. Si LOCKDEP está habilitado, debemos asegurarnos de que un módulo que llama a sock_lock_init_class_and_name() (CIFS, NFS, etc.) no pueda descargarse mientras dicho socket siga activo para evitar este problema. Mantendremos la referencia del módulo en sock_lock_init_class_and_name() y la liberaremos cuando el socket se libere en sk_prot_free(). Tenga en cuenta que sock_lock_init() borra sk->sk_owner para svc_create_socket(), que llama a sock_lock_init_class_and_name() para un socket que escucha, lo que clona un socket mediante sk_clone_lock() sin GFP_ZERO. [0]: CIFS_SERVER="10.0.0.137" CIFS_PATH="//${CIFS_SERVER}/Usuarios/Administrador/Escritorio/CIFS_TEST" DEV="enp0s3" CRED="/root/WindowsCredential.txt" MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credenciales=${CRED},caché=ninguno,intervalo_de_eco=1 iptables -A INPUT -s ${CIFS_SERVER} -j DROP para i en $(seq 10); Desmontar ${MNT} rmmod cifs sleep 1 hecho rm -r ${MNT} iptables -D INPUT -s ${CIFS_SERVER} -j DROP [1]: DEBUG_LOCKS_WARN_ON(1) ADVERTENCIA: CPU: 10 PID: 0 en kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Módulos enlazados en: cifs_arc4 nls_ucs2_utils cifs_md4 [última descarga: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 No contaminado 6.14.0 #36 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Rastreo de llamadas: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350) ... ERROR: desreferencia de puntero NULL del núcleo, dirección: 00000000000000c4 PF: acceso de lectura del supervisor en modo núcleo PF: error_code(0x0000) - página no presente PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Contaminado: GW 6.14.0 #36 Contaminado: [W]=WARN Nombre del hardware: QEMU Standard PC (i440FX + PIIX, ---truncado---
-
Vulnerabilidad en kernel de Linux (CVE-2025-23145)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: se corrige el puntero NULL en can_accept_new_subflow Al probar la herramienta de evaluación comparativa valkey con MPTCP, el kernel entra en pánico en 'mptcp_can_accept_new_subflow' porque subflow_req->msk es NULL. Rastreo de llamadas: mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminador 4)) (P) subflow_syn_recv_sock (./net/mptcp/subflow.c:854) tcp_check_req (./net/ipv4/tcp_minisocks.c:863) tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) ip_local_deliver_finish (./net/ipv4/ip_input.c:234) ip_local_deliver (./net/ipv4/ip_input.c:254) ip_rcv_finish (./net/ipv4/ip_input.c:449) ... Según el registro de depuración, la misma solicitud recibió dos SYN-ACK en muy poco tiempo, probablemente porque el cliente retransmite el SYN-ACK por varias razones. Incluso si los paquetes se transmiten con un intervalo de tiempo relevante, el servidor puede procesarlos en diferentes CPU simultáneamente. La propiedad de 'subflow_req->msk' se transfiere primero al subflujo, lo que conlleva el riesgo de una desreferencia de puntero nulo. Este parche corrige este problema moviendo 'subflow_req->msk' bajo la condición `own_req == true`. Tenga en cuenta que la comprobación !msk en subflow_hmac_valid() puede omitirse, ya que ya existe en la rama own_req de mpj, donde se ha movido el código.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23146)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mfd: ene-kb3930: Se corrige una posible desreferencia de puntero nulo. El valor off_gpios podría ser nulo. Se añade la comprobación faltante en kb3930_probe(). Esto es similar al problema corregido en el commit b1ba8bcb2d1f ("backlight: hx8357: Se corrige una posible desreferencia de puntero nulo"). Esto fue detectado por nuestra herramienta de análisis estático.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23147)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: Añadir comprobación de puntero nulo en i3c_master_queue_ibi(). El controlador maestro I3C puede recibir una IBI de un dispositivo de destino que aún no se ha sondeado. En tales casos, el maestro llama a `i3c_master_queue_ibi()` para poner en cola una tarea de trabajo IBI, lo que genera el error "No se puede manejar la lectura del kernel desde memoria ilegible" y provoca un pánico del kernel. Flujo típico de manejo de IBI: 1. El maestro I3C escanea los dispositivos de destino y sondea sus respectivos controladores. 2. El controlador del dispositivo de destino llama a `i3c_device_request_ibi()` para habilitar IBI y asigna `dev->ibi = ibi`. 3. El maestro I3C recibe una IBI del dispositivo de destino y llama a `i3c_master_queue_ibi()` para poner en cola la tarea de manejo de IBI del controlador del dispositivo de destino. Sin embargo, dado que los eventos del dispositivo de destino son asíncronos a la secuencia de sondeo I3C, el paso 3 puede ocurrir antes del paso 2, lo que provoca que `dev->ibi` sea `NULL` y provoque un pánico del kernel. Agregue una comprobación de puntero NULL en `i3c_master_queue_ibi()` para evitar el acceso a un `dev->ibi` sin inicializar, garantizando así la estabilidad.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23148)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: samsung: exynos-chipid: Se ha añadido una comprobación de puntero nulo en exynos_chipid_probe(). soc_dev_attr->revision podría ser nulo, por lo que se ha añadido una comprobación de puntero para evitar posibles desreferencias de punteros nulos. Esto es similar a la corrección en el commit 3027e7b15b02 ("ice: Se corrigen algunos problemas de desreferencia de puntero nulo en ice_ptp.c"). Nuestra herramienta de análisis estático ha detectado este problema.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23150)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige el error de uno en uno en do_split Syzkaller detectó un problema de use-after-free en ext4_insert_dentry que fue causado por un acceso fuera de los límites debido a una división incorrecta en do_split. ERROR: KASAN: use-after-free en ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Escritura de tamaño 251 en la dirección ffff888074572f14 por la tarea syz-executor335/5847 CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 No contaminado 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 30/10/2024 Rastreo de llamadas: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f El siguiente bucle se encuentra justo encima de la declaración 'if'. for (i = count-1; i >= 0; i--) { /* ¿hay más de la mitad de esta entrada en la 2da mitad del bloque? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; } En este caso, la 'i' podría bajar a -1, en cuyo caso la suma de las entradas activas no superaría la mitad del tamaño del bloque. Sin embargo, el comportamiento anterior también se dividiría por la mitad si la suma superara el tamaño del último bloque. Esto, al tener demasiados archivos con nombres largos en un solo bloque, podría provocar un acceso fuera de los límites y el consiguiente uso después de la liberación. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23151)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: host: Corrección de la competencia entre unprepare y queue_buf. Un controlador de cliente podría usar mhi_unprepare_from_transfer() para silenciar los datos entrantes durante su desconexión. El controlador de cliente también podría estar procesando datos simultáneamente, lo que resulta en una llamada a mhi_queue_buf(), que invocará mhi_gen_tre(). Si mhi_gen_tre() se ejecuta después de que mhi_unprepare_from_transfer() haya desconectado el canal, se producirá un pánico debido a una desreferencia no válida que provoca un fallo de página. Esto ocurre porque mhi_gen_tre() no verifica el estado del canal después de bloquearlo. Para solucionar esto, haga que mhi_gen_tre() confirme que el estado del canal es válido o devuelva un error para evitar acceder a los datos desinicializados. [mani: etiqueta estable añadida]
-
Vulnerabilidad en kernel de Linux (CVE-2025-23153)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm/crc-t10dif: corrige el uso de una matriz fuera de alcance en crc_t10dif_arch() Corrige un error tonto en el que se usaba una matriz fuera de su alcance.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23154)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/net: corrección del abuso de io_req_post_cqe por parte del paquete de envío [ 114.987980][ T5313] ADVERTENCIA: CPU: 6 PID: 5313 en io_uring/io_uring.c:872 io_req_post_cqe+0x12e/0x4f0 [ 114.991597][ T5313] RIP: 0010:io_req_post_cqe+0x12e/0x4f0 [ 115.001880][ T5313] Rastreo de llamadas: [ 115.002222][ T5313] [ 115.007813][ T5313] io_send+0x4fe/0x10f0 [ 115.009317][ T5313] io_issue_sqe+0x1a6/0x1740 [ 115.012094][ T5313] io_wq_submit_work+0x38b/0xed0 [ 115.013223][ T5313] io_worker_handle_work+0x62a/0x1600 [ 115.013876][ T5313] io_wq_worker+0x34f/0xdf0 Como se indica en el comentario, io_req_post_cqe() solo debe usarse en solicitudes multienvío, como REQ_F_APOLL_MULTISHOT, que no se usan en envíos agrupados. Agregue un indicador que indique si una solicitud desea publicar múltiples CQE. Finalmente, REQ_F_APOLL_MULTISHOT debería implicar la nueva bandera, pero esto se omite para simplificar.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23155)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: Se corrige el acceso a la IRQ liberada affinity_hint. La máscara cpu no debe ser una variable local, ya que su puntero se guarda en irq_desc y se puede acceder desde procfs. Para corregirla, utilice la máscara persistente cpumask_of(cpu#).
-
Vulnerabilidad en kernel de Linux (CVE-2025-23156)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi_parser: refactorización de la lógica de análisis de paquetes HFI. words_count indica el número de palabras en el payload total, mientras que data apunta al payload de varias propiedades dentro de ella. Cuando words_count alcanza la última palabra, data puede acceder a memoria más allá de payload total. Esto puede provocar accesos fuera de banda (OOB). Con este parche, la API de utilidad para gestionar propiedades individuales ahora devuelve el tamaño de los datos consumidos. Por consiguiente, los bytes restantes se calculan antes de analizar el payload, eliminando así las posibilidades de accesos fuera de banda (OOB).
-
Vulnerabilidad en kernel de Linux (CVE-2025-23157)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi_parser: añadir comprobación para evitar accesos fuera de los límites. Existe la posibilidad de que init_codecs se invoque varias veces durante la manipulación de la carga útil del firmware de vídeo. En tal caso, si codecs_count se incrementa a un valor superior a MAX_CODEC_NUM, puede haber accesos fuera de los límites. Restablezca el contador para que siempre comience desde el principio.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23158)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi: se ha añadido una comprobación para gestionar el tamaño incorrecto de queue size qsize representa el tamaño de la cola compartida entre el controlador y el firmware de vídeo. El firmware puede modificar este valor a un valor grande no válido. En tal situación, el espacio vacío será mayor que el espacio realmente disponible. Dado que new_wr_idx no se comprueba, el siguiente código resultará en una escritura fuera de banda (OOB). ... qsize = qhdr->q_size if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> Escritura fuera de banda (OOB). Se ha añadido una comprobación para garantizar que qsize se encuentre dentro del tamaño asignado al leer y escribir paquetes en la cola.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23159)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: hfi: se ha añadido una comprobación para gestionar la escritura OOB en la región sfr. sfr->buf_size se encuentra en memoria compartida y puede ser modificado por un usuario malintencionado. Es posible escribir OOB cuando el tamaño es mayor que el del búfer de datos sfr. En estos casos, limite el tamaño al tamaño asignado.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23161)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: vmd: Convertir vmd_dev::cfg_lock en tipo raw_spinlock_t El acceso al espacio de configuración PCI mediante pci_ops::read y pci_ops::write es un acceso de hardware de bajo nivel. Se puede acceder a las funciones con interrupciones deshabilitadas incluso en PREEMPT_RT. El pci_lock es un raw_spinlock_t para este propósito. Un spinlock_t se convierte en un bloqueo inactivo en PREEMPT_RT, por lo que no se puede adquirir con interrupciones deshabilitadas. Se accede a vmd_dev::cfg_lock en el mismo contexto que el pci_lock. Convertir vmd_dev::cfg_lock en un tipo raw_spinlock_t para que pueda usarse con interrupciones deshabilitadas. Esto se informó como: ERROR: función inactiva llamada desde un contexto no válido en kernel/locking/spinlock_rt.c:48 Rastreo de llamadas: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90 [bigeasy: reformular el mensaje de confirmación] Probado por: Luis Claudio R. Goncalves [kwilczynski: registro de confirmaciones] [bhelgaas: agregar información del informe de https://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]
-
Vulnerabilidad en kernel de Linux (CVE-2025-23162)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/vf: No intente activar un reinicio completo de GT si VF Los VF no tienen acceso al registro GDRST(0x941c) que el controlador usa para reiniciar un GT. Intento de activar un reinicio usando debugfs: $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset o debido a una condición de bloqueo detectada por el controlador conduce a: [ ] xe 0000:00:02.1: [drm] GT0: intentando reiniciar desde force_reset [xe] [ ] xe 0000:00:02.1: [drm] GT0: reinicio en cola [ ] xe 0000:00:02.1: [drm] GT0: reinicio iniciado [ ] ------------[ cortar aquí ]------------ [ ] xe 0000:00:02.1: [drm] GT0: VF está intentando escribir 0x1 en un registro inaccesible 0x941c+0x0 [ ] ADVERTENCIA: CPU: 3 PID: 3069 en controladores/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] Rastreo de llamadas: [ ] [ ] ? show_regs+0x6c/0x80 [ ] ? __warn+0x93/0x1c0 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? report_bug+0x182/0x1b0 [ ] ? handle_bug+0x6e/0xb0 [ ] ? asm_exc_invalid_op+0x1b/0x20 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe] [ ] ? Solucione esto enviando la acción H2G VF_RESET(0x5507) en su lugar.
-
Vulnerabilidad en kernel de Linux (CVE-2025-23163)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: vlan: no propagar indicadores al abrir Con el bloqueo de la instancia del dispositivo, ahora existe la posibilidad de un interbloqueo: [ 1.211455] =============================================== [ 1.211571] ADVERTENCIA: posible bloqueo recursivo detectado [ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 No contaminado [ 1.211823] -------------------------------------------- [ 1.211936] ip/184 is trying to acquire lock: [ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0 [ 1.212207] [ 1.212207] but task is already holding lock: [ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.212487] [ 1.212487] other info that might help us debug this: [ 1.212626] Possible unsafe locking scenario: [ 1.212626] [ 1.212751] CPU0 [ 1.212815] ---- [ 1.212871] lock(&dev->lock); [ 1.212944] lock(&dev->lock); [ 1.213016] [ 1.213016] *** DEADLOCK *** [ 1.213016] [ 1.213143] May be due to missing lock nesting notation [ 1.213143] [ 1.213294] 3 locks held by ip/184: [ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0 [ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0 [ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.213895] [ 1.213895] stack backtrace: [ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 [ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 1.213994] Call Trace: [ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0 [ 1.214000] print_deadlock_bug+0x28b/0x2a0 [ 1.214020] lock_acquire+0xea/0x2a0 [ 1.214027] __mutex_lock+0xbf/0xd40 [ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI [ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev [ 1.214042] __dev_open+0x145/0x270 [ 1.214046] __dev_change_flags+0xb0/0x1e0 [ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev [ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info [ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0 [ 1.214058] notifier_call_chain+0x78/0x120 [ 1.214062] netif_open+0x6d/0x90 [ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0 [ 1.214066] bond_enslave+0x64c/0x1230 [ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0 [ 1.214077] do_setlink+0x516/0x13b0 [ 1.214094] rtnl_newlink+0xaba/0xb80 [ 1.214132] rtnetlink_rcv_msg+0x440/0x490 [ 1.214144] netlink_rcv_skb+0xeb/0x120 [ 1.214150] netlink_unicast+0x1f9/0x320 [ 1.214153] netlink_sendmsg+0x346/0x3f0 [ 1.214157] __sock_sendmsg+0x86/0xb0 [ 1.214160] ____sys_sendmsg+0x1c8/0x220 [ 1.214164] ___sys_sendmsg+0x28f/0x2d0 [ 1.214179] __x64_sys_sendmsg+0xef/0x140 [ 1.214184] do_syscall_64+0xec/0x1d0 [ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 1.214191] RIP: 0033:0x7f2d1b4a7e56 Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down) Al esclavizar el dispositivo inferior (netdevsim0) que tiene una VLAN, propagamos los indicadores allmuti/promisc de la VLAN durante ndo_open. Esto provoca el (re)bloqueo de real_dev. Allmulti/promisc se propaga cuando cambian los indicadores, no cuando están abiertos. Hay un ligero cambio semántico: las VLAN inactivas ahora propagan los indicadores, pero es poco probable que esto cause los problemas reales. Reproductor: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm ---truncado---
-
Vulnerabilidad en kernel de Linux (CVE-2025-37743)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Evitar fugas de memoria al habilitar las estadísticas. El controlador utiliza anillos de destino del monitor para el modo de estadísticas extendidas y el modo de monitor independiente. En el modo de estadísticas extendidas, los TLV se analizan desde el búfer recibido del anillo de destino del monitor y se asignan a la estructura ppdu_info para actualizar las estadísticas por paquete. En el modo de monitor independiente, junto con las estadísticas por paquete, se capturan los datos del paquete (carga útil) y el controlador actualiza por MSDU a mac80211. Cuando la interfaz AP está habilitada, solo se activa el modo de estadísticas extendidas. Como parte de la habilitación de los anillos de monitor para recopilar estadísticas, el controlador se suscribe al TLV HAL_RX_MPDU_START en la configuración del filtro. Este TLV se recibe del anillo de destino del monitor y se produce kzalloc para el objeto mon_mpdu, que no se libera, lo que provoca una fuga de memoria. El kzalloc para el objeto mon_mpdu solo es necesario mientras se habilita la interfaz de monitor independiente. Esto causa una fuga de memoria al habilitar el modo de estadísticas extendidas en el controlador. Solucione esta fuga de memoria eliminando el kzalloc del objeto mon_mpdu en la gestión de la TLV HAL_RX_MPDU_START. Además, elimine la gestión del modo de monitor independiente en las TLV HAL_MON_BUF_ADDR y HAL_RX_MSDU_END. Estas etiquetas TLV se gestionarán correctamente al habilitar el modo de monitor independiente en el futuro. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3.
-
Vulnerabilidad en kernel de Linux (CVE-2025-37744)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: se corrige la pérdida de memoria en ath12k_pci_remove() Kmemleak informó este error: objeto sin referencia 0xffff1c165cec3060 (tamaño 32): comm "insmod", pid 560, jiffies 4296964570 (edad 235.596s) backtrace: [<000000005434db68>] __kmem_cache_alloc_node+0x1f4/0x2c0 [<000000001203b155>] kmalloc_trace+0x40/0x88 [<0000000028adc9c8>] _request_firmware+0xb8/0x608 [<00000000cad1aef7>] firmware_request_nowarn+0x50/0x80 [<000000005011a682>] local_pci_probe+0x48/0xd0 [<00000000077cd295>] pci_device_probe+0xb4/0x200 [<0000000087184c94>] really_probe+0x150/0x2c0 La memoria del firmware se asignó en ath12k_pci_probe(), pero no se liberó en ath12k_pci_remove() si el bit ATH12K_FLAG_QMI_FAIL está activado. Por lo tanto, se llama ath12k_fw_unmap() para liberar la memoria. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.2.0-02280-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1
-
Vulnerabilidad en kernel de Linux (CVE-2025-37745)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: hibernate: Evitar interbloqueo en hibernate_compressor_param_set(). syzbot reportó un interbloqueo en lock_system_sleep() (ver más abajo). La operación de escritura en "/sys/module/hibernate/parameters/compressor" entra en conflicto con el registro del dispositivo ieee80211, lo que resulta en un interbloqueo al intentar adquirir system_transition_mutex bajo param_lock. Para evitar este interbloqueo, modifique hibernate_compressor_param_set() para usar mutex_trylock() al intentar adquirir system_transition_mutex y devolver -EBUSY si falla. No es necesario guardar ni ajustar los indicadores de tarea antes de llamar a mutex_trylock(&system_transition_mutex), ya que el llamador no esperará este mutex y, si se ejecuta simultáneamente con la suspensión del sistema en curso, se congelará correctamente al regresar al espacio de usuario. Informe de syzbot: syz-executor895/5833 está intentando adquirir el bloqueo: ffffffff8e0828c8 (system_transition_mutex){+.+.}-{4:4}, en: lock_system_sleep+0x87/0xa0 kernel/power/main.c:56 pero la tarea ya tiene el bloqueo: ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, en: kernel_param_lock kernel/params.c:607 [en línea] ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, en: param_attr_store+0xe6/0x300 kernel/params.c:586 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 (param_lock){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [en línea] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 ieee80211_rate_control_ops_get net/mac80211/rate.c:220 [en línea] rate_control_alloc net/mac80211/rate.c:266 [en línea] ieee80211_init_rate_ctrl_alg+0x18d/0x6b0 net/mac80211/rate.c:1015 ieee80211_register_hw+0x20cd/0x4060 net/mac80211/main.c:1531 mac80211_hwsim_new_radio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5558 init_mac80211_hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211_hwsim.c:6910 hacer_una_initcall+0x128/0x700 init/main.c:1257 hacer_nivel_initcall init/main.c:1319 [en línea] hacer_initcalls init/main.c:1335 [en línea] hacer_configuración_básica init/main.c:1354 [en línea] kernel_init_freeable+0x5c7/0x900 init/main.c:1568 kernel_init+0x1c/0x2b0 init/main.c:1457 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 -> #2 (rtnl_mutex){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [en línea] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 wg_pm_notification drivers/net/wireguard/device.c:80 [en línea] wg_pm_notification+0x49/0x180 controladores/net/wireguard/device.c:64 cadena_de_llamadas_del_notificador+0xb7/0x410 kernel/notifier.c:85 cadena_de_llamadas_del_notificador_robust kernel/notifier.c:120 [en línea] cadena_de_llamadas_del_notificador_robust kernel/notifier.c:345 [en línea] cadena_de_llamadas_del_notificador_robust+0xc9/0x170 kernel/notifier.c:333 cadena_de_llamadas_del_notificador_robust+0x27/0x60 kernel/power/main.c:102 snapshot_open+0x189/0x2b0 kernel/power/user.c:77 misc_open+0x35a/0x420 controladores/char/misc.c:179 chrdev_open+0x237/0x6a0 fs/char_dev.c:414 do_dentry_open+0x735/0x1c40 fs/open.c:956 vfs_open+0x82/0x3f0 fs/open.c:1086 do_open fs/namei.c:3830 [en línea] path_openat+0x1e88/0x2d80 fs/namei.c:3989 do_filp_open+0x20c/0x470 fs/namei.c:4016 do_sys_openat2+0x17a/0x1e0 fs/open.c:1428 do_sys_open fs/open.c:1443 [en línea] __do_sys_openat fs/open.c:1459 [en línea] __se_sys_openat fs/open.c:1454 [en línea] __x64_sys_openat+0x175/0x210 fs/open.c:1454 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #1 ((pm_chain_head).rwsem){++++}-{4:4}: down_read+0x9a/0x330 kernel/locking/rwsem.c:1524 blocking_notifier_call_chain_robust kernel ---truncado---
-
Vulnerabilidad en kernel de Linux (CVE-2025-37746)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/dwc_pcie: se corrigen dispositivos pci_dev duplicados. Durante platform_device_register, el uso incorrecto de struct device pci_dev como platform_data provocaba una copia kmemdup de pci_dev. Peor aún, acceder al dispositivo duplicado provoca la corrupción de la lista, ya que su contenido mutex (p. ej., list, magic) permanece igual que el original.
-
Vulnerabilidad en kernel de Linux (CVE-2025-37747)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: Se soluciona el bloqueo al liberar el evento sigtrap Perf puede bloquearse al liberar un evento sigtrap si no se ha logrado enviar una señal diferida relacionada antes de que se cerrara el archivo: perf_event_overflow() task_work_add(perf_pending_task) fput() task_work_add(____fput()) task_work_run() ____fput() perf_release() perf_event_release_kernel() _free_event() perf_pending_task_sync() task_work_cancel() -> FAILED rcuwait_wait_event() Una vez que task_work_run() se está ejecutando, la lista de devoluciones de llamadas pendientes se elimina de task_struct y desde este punto, task_work_cancel() no puede eliminar ningún elemento de trabajo pendiente y aún no iniciado, de ahí el error de task_work_cancel() y el bloqueo de rcuwait_wait_event(). El trabajo de la tarea se puede cambiar para eliminar un trabajo a la vez, de modo que un trabajo que se ejecuta en la tarea actual siempre puede cancelar uno pendiente, sin embargo, el diseño de espera/activación aún está sujeto a dependencias invertidas cuando se involucran objetivos remotos, como lo ilustra Oleg: T1 T2 fd = perf_event_open(pid => T2->pid); fd = perf_event_open(pid => T1->pid); close(fd) close(fd) perf_event_overflow() perf_event_overflow() task_work_add(perf_pending_task) task_work_add(perf_pending_task) fput() fput() task_work_add(____fput()) task_work_add(____fput()) task_work_run() task_work_run() ____fput() ____fput() perf_release() perf_release() perf_event_release_kernel() perf_event_release_kernel() _free_event() _free_event() perf_pending_task_sync() perf_pending_task_sync() rcuwait_wait_event() rcuwait_wait_event() Por lo tanto, la única opción que queda es adquirir el recuento de referencias de evento al poner en cola el trabajo de la tarea de rendimiento y liberarlo del trabajo de la tarea. Tal como se hizo antes de 3a5465418f5f ("perf: Corregir fuga de eventos al ejecutar y liberar archivos"), pero sin las fugas corregidas. Se requieren algunos ajustes para que funcione: * Un evento secundario podría desreferenciar a su padre al liberarse. Se debe tener cuidado de liberar al padre al final. * Algunos sitios, al asumir que el evento no tiene ninguna referencia retenida y, por lo tanto, puede liberarse de inmediato, deben colocar la referencia y dejar que el recuento de referencias continúe.
-
Vulnerabilidad en kernel de Linux (CVE-2025-37766)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.
-
Vulnerabilidad en kernel de Linux (CVE-2025-37767)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.
-
Vulnerabilidad en kernel de Linux (CVE-2025-37768)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.
-
Vulnerabilidad en kernel de Linux (CVE-2025-37769)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm/smu11: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE. (Seleccionada de la confirmación da7dc714a8f8e1c9fc33c57cd63583779a3bef71)
-
Vulnerabilidad en kernel de Linux (CVE-2025-37770)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.
-
Vulnerabilidad en kernel de Linux (CVE-2025-37771)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Impide la división por cero. El usuario puede establecer cualquier valor de velocidad. Si la velocidad es superior a UINT_MAX/8, es posible la división por cero. Encontrada por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.
-
Vulnerabilidad en kernel de Linux (CVE-2025-37772)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/cma: Se corrige el fallo de la cola de trabajo en cma_netevent_work_handler. La estructura rdma_cm_id tiene el miembro "struct work_struct net_work", que se reutiliza para encolar cma_netevent_work_handler()s en cma_wq. El fallo [1] puede ocurrir si se realizan varias llamadas a cma_netevent_callback() en rápida sucesión, lo que encola aún más cma_netevent_work_handler()s para el mismo rdma_cm_id, sobrescribiendo cualquier elemento de trabajo previamente en cola que se haya programado para ejecutarse. Es decir, no hay garantía de que el elemento de trabajo en cola se ejecute entre dos llamadas sucesivas a cma_netevent_callback() y el segundo INIT_WORK sobrescribiría el primer elemento de trabajo (para el mismo rdma_cm_id), a pesar de obtener id_table_lock durante la encola. Además, el análisis drgn [2] indica que es probable que el elemento de trabajo se haya sobrescrito. Para solucionarlo, mueva INIT_WORK() a __rdma_create_id(), de modo que no compita con ninguna queue_work() existente ni con su subproceso de trabajo. [1] Pila de fallos recortada: =============================================== ERROR: desreferencia de puntero NULL del núcleo, dirección: 000000000000008 kworker/u256:6 ... 6.12.0-0... Cola de trabajo: cma_netevent_work_handler [rdma_cm] (rdma_cm) RIP: 0010:process_one_work+0xba/0x31a Seguimiento de llamadas: worker_thread+0x266/0x3a0 kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 ============================================= [2] drgn crash analysis: >>> trace = prog.crashed_thread().stack_trace() >>> trace (0) crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15) (1) __crash_kexec (kernel/crash_core.c:122:4) (2) panic (kernel/panic.c:399:3) (3) oops_end (arch/x86/kernel/dumpstack.c:382:3) ... (8) process_one_work (kernel/workqueue.c:3168:2) (9) process_scheduled_works (kernel/workqueue.c:3310:3) (10) worker_thread (kernel/workqueue.c:3391:4) (11) kthread (kernel/kthread.c:389:9) Line workqueue.c:3168 for this kernel version is in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); >>> trace[8]["work"] *(struct work_struct *)0xffff92577d0a21d8 = { .data = (atomic_long_t){ .counter = (s64)536870912, <=== Note }, .entry = (struct list_head){ .next = (struct list_head *)0xffff924d075924c0, .prev = (struct list_head *)0xffff924d075924c0, }, .func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280, } Suspicion is that pwq is NULL: >>> trace[8]["pwq"] (struct pool_workqueue *) In process_one_work(), pwq is assigned from: struct pool_workqueue *pwq = get_work_pwq(work); and get_work_pwq() is: static struct pool_workqueue *get_work_pwq(struct work_struct *work) { unsigned long data = atomic_long_read(&work->data); if (data & WORK_STRUCT_PWQ) return work_struct_pwq(data); else return NULL; } WORK_STRUCT_PWQ is 0x4: >>> print(repr(prog['WORK_STRUCT_PWQ'])) Object(prog, 'enum work_flags', value=4) But work->data is 536870912 which is 0x20000000. So, get_work_pwq() returns NULL and we crash in process_one_work(): 3168 strscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN); =============================================
-
Vulnerabilidad en kernel de Linux (CVE-2025-37773)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtiofs: añadir comprobación del nombre de la fuente en el contexto del sistema de archivos. En ciertos escenarios, por ejemplo, durante las pruebas fuzz, el nombre de la fuente puede ser nulo, lo que podría provocar un pánico del kernel. Por lo tanto, se debe añadir una comprobación adicional del nombre de la fuente.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49790)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: iforce - invierte la comprobación de longitud válida al obtener los ID de dispositivo. syzbot informa un valor no inicializado en iforce_init_device() [1], para el commit 6ac0aec6b0a6 ("Entrada: iforce - permite que los llamantes suministren el búfer de datos al obtener los ID de dispositivo") y comprueba que la longitud válida sea menor que los bytes a leer. Dado que iforce_get_id_packet() almacena la longitud válida al devolver 0, el llamante debe comprobar que la longitud válida sea mayor o igual que los bytes a leer.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49791)
Severidad: MEDIA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corrección de fugas de solicitudes de aceptación multishot. Tener REQ_F_POLLED configurado no garantiza que la solicitud se ejecute como multishot desde la ruta de sondeo. Afortunadamente, si el código considera que se trata de un problema multishot cuando no lo es, solo puede solicitar omitir la finalización, lo que provoca la fuga de la solicitud. Use issue_flags para marcar los problemas de multipoll.
-
Vulnerabilidad en kernel de Linux (CVE-2022-49792)
Severidad: ALTA
Fecha de publicación: 01/05/2025
Fecha de última actualización: 05/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: mp2629: se corrige un posible acceso fuera de los límites de la matriz. Se agrega centinela al final de los mapas para evitar un posible acceso fuera de los límites de la matriz en el núcleo iio.



