Instituto Nacional de ciberseguridad. Sección Incibe

017 - Ir a la línea de ayuda en Ciberseguridad    Ir a Agenda     Ir a Sala de prensa     Ir a suscripción de boletines

Ir al buscador

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 WP Swings Coupon Referral Program (CVE-2024-25100)
    Severidad: CRÍTICA
    Fecha de publicación: 12/02/2024
    Fecha de última actualización: 26/09/2025
    Vulnerabilidad de deserialización de datos no confiables en WP Swings Coupon Referral Program. Este problema afecta a Coupon Referral Program: desde n/a hasta 1.7.2.
  • Vulnerabilidad en kernel de Linux (CVE-2024-27411)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/nouveau: mantiene los buffers DMA necesarios para suspender/reanudar Nouveau desasigna algunos buffers después del inicio de GPU que son necesarios para que la suspensión/reanudación de GPU funcione correctamente. Probablemente esto no sea un problema tan grande en sistemas donde la NVGPU es la única GPU, pero en configuraciones de múltiples GPU conduce a una regresión en la que el módulo del kernel genera errores y provoca una congelación de la representación en todo el sistema. Esta confirmación soluciona esa regresión moviendo los dos buffers necesarios para suspender y reanudar para que se desasignen durante la descarga del controlador en lugar de después del inicio.
  • Vulnerabilidad en kernel de Linux (CVE-2024-27415)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: bridge: confirme los paquetes de multidifusión antes de pasarlos a la pila conntrack La lógica nf_confirm no puede manejar skbs clonados que hagan referencia a la misma entrada nf_conn, lo que sucederá con las tramas de multidifusión (difusión) en puentes. Ejemplo: macvlan0 | br0 / \ ethX ethY ethX (o Y) recibe un paquete de multidifusión o difusión L2 que contiene un paquete IP, el flujo aún no está en la tabla conntrack. 1. skb pasa por el puente y el enrutamiento previo de IP falsa (br_netfilter). -> skb->_nfct ahora hace referencia a una entrada no confirmada 2. skb es un paquete amplio/mcast. El puente ahora pasa clones en cada interfaz del puente. 3. skb pasa a la pila. 4. En el caso de macvlan, el controlador macvlan conserva los clones del skb mcast y programa una cola de trabajo para enviarlos a los dispositivos inferiores. El clon skb->_nfct no es una copia, es la misma entrada que el skb original. El controlador macvlan rx luego devuelve RX_HANDLER_PASS. 5. Los ganchos de conexión normales (en NF_INET_LOCAL_IN) confirman el skb original. El trabajador de transmisión de Macvlan y la ruta de confirmación normal correrán. Esta carrera no se realizará si el paso 2 ya confirmó un clon. En ese caso, los pasos posteriores realizan skb_clone() con skb->_nfct ya confirmado (en la tabla hash). Esto funciona bien. Pero dicha confirmación no ocurrirá cuando las reglas eb/ip/nftables eliminen los paquetes antes de que alcancen el paso nf_confirm en el posenrutamiento. Pablo señala que nf_conntrack_bridge no permite el uso de nat con estado, por lo que podemos descartar con seguridad la entrada nf_conn y dejar que inet llame a conntrack nuevamente. Esto no funciona para bridge netfilter: skb podría tener una transformación nat. Además, bridge nf evita la reinvocación del enrutamiento previo de inet a través del gancho 'sabotage_in'. Evite este problema confirmando explícitamente la entrada en el momento LOCAL_IN, antes de que la capa superior tenga la oportunidad de clonar la entrada no confirmada. La desventaja es que esto desactiva NAT y los asistentes de conexión. Una solución alternativa sería agregar bloqueo a todas las partes del código que tratan con paquetes no confirmados, pero incluso si eso pudiera hacerse de manera sensata, esto abre otros problemas, por ejemplo: -m physdev --physdev-out eth0 -j SNAT - -snat-to 1.2.3.4 -m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5 Para el caso de multidifusión, solo se creará una de estas asignaciones conflictivas, conntrack solo maneja asignaciones NAT 1:1. Los usuarios deben crear una configuración que marque explícitamente dicho tráfico NOTRACK (omisión de conntrack) para evitar esto, pero no podemos omitirlos automáticamente, es posible que el conjunto de reglas ya haya aceptado reglas para el tráfico sin seguimiento, por lo que el comportamiento visible para el usuario cambiaría.
  • Vulnerabilidad en kernel de Linux (CVE-2024-27418)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: mctp: toma posesión de skb en mctp_local_output Actualmente, mctp_local_output solo toma propiedad de skb en caso de éxito, y podemos filtrar un fallo skb si mctp_local_output en estados específicos; la propiedad del skb no se transfiere hasta que se produce el enrutamiento de salida real. En su lugar, haga que mctp_local_output libere el skb en todas las rutas de error hasta la acción de ruta, de modo que siempre consuma el skb pasado.
  • Vulnerabilidad en kernel de Linux (CVE-2024-27432)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: mtk_eth_soc: soluciona el problema de bloqueo del PPE Se encontró un parche para resolver un problema en el SDK con licencia GPL de MediaTek: En la función mtk_ppe_stop(), el modo de escaneo del PPE no está desactivado antes de desactivar el EPI. Potencialmente, esto puede provocar un bloqueo durante el proceso de desactivación del EPI. Sin este parche, el PPE puede sufrir un bloqueo durante la prueba de reinicio.
  • Vulnerabilidad en kernel de Linux (CVE-2024-27434)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: no configure el indicador MFP para GTK El firmware no necesita el indicador MFP para GTK, incluso puede provocar que el firmware falle. en caso de que el AP esté configurado con: cifrado de grupo TKIP y MFPC. Enviaríamos el GTK con cifrado = TKIP y MFP, lo cual, por supuesto, no es posible.
  • Vulnerabilidad en kernel de Linux (CVE-2024-35787)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/md-bitmap: corrige el uso incorrecto de sb_index Commit d7038f951828 ("md-bitmap: no usar ->índice para páginas que respaldan el archivo de mapa de bits") página eliminada-> índice del código de mapa de bits, pero dejó una lógica de código incorrecta para clustered-md. El código actual nunca establece el desplazamiento de ranura para los nodos del clúster, a veces causa fallos en el entorno del clúster. Rastreo de llamadas (parcialmente): md_bitmap_file_set_bit+0x110/0x1d8 [md_mod] md_bitmap_startwrite+0x13c/0x240 [md_mod] raid1_make_request+0x6b0/0x1c08 [raid1] md_handle_request+0x1dc/0x368 [md_submit_bio+0x8 0/0xf8 [md_mod] __submit_bio+0x178/ 0x300 enviar_bio_noacct_nocheck+0x11c/0x338 enviar_bio_noacct+0x134/0x614 enviar_bio+0x28/0xdc enviar_bh_wbc+0x130/0x1cc enviar_bh+0x1c/0x28
  • Vulnerabilidad en kernel de Linux (CVE-2024-35793)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: debugfs: corrige el manejo de espera/cancelación durante la eliminación Ben Greear informa además bloqueos durante la eliminación de debugfs concurrentes mientras se accede a los archivos, aunque el código en cuestión ahora usa cancelaciones de debugfs. Resulta que a pesar de toda la revisión sobre el bloqueo, no entendimos por completo que la lógica es incorrecta: si el recuento llega a cero, podemos finalizar (y no necesitamos esperar a que se complete), pero si no es así, tenemos que activar todos los cancelaciones. Tal como está escrito, _nunca_ podemos entrar en el ciclo que desencadena las cancelaciones. Arregla esto y explícalo mejor mientras lo haces.
  • Vulnerabilidad en kernel de Linux (CVE-2024-35794)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-raid: sync_thread realmente congelado durante la suspensión 1) commit f52f5c71f3d4 ("md: fix deteniendo el hilo de sincronización") elimina MD_RECOVERY_FROZEN de __md_stop_writes() y no se da cuenta de que dm-raid se basa en __md_stop_writes() para congelar sync_thread indirectamente. Solucione este problema agregando MD_RECOVERY_FROZEN en md_stop_writes(), y dado que stop_sync_thread() solo se usa para dm-raid en este caso, mueva también stop_sync_thread() a md_stop_writes(). 2) La bandera MD_RECOVERY_FROZEN no significa que el subproceso de sincronización esté congelado, solo impide que se inicie un nuevo subproceso de sincronización y no puede detener el subproceso de sincronización en ejecución; Para congelar sync_thread, después de configurar la bandera, se debe usar stop_sync_thread(). 3) La bandera MD_RECOVERY_FROZEN no significa que se detengan las escrituras; usarla como condición para md_stop_writes() en raid_postsuspend() no parece correcta. Considere que el reentrante stop_sync_thread() no hace nada, siempre llame a md_stop_writes() en raid_postsuspend(). 4) raid_message puede establecer/borrar el indicador MD_RECOVERY_FROZEN en cualquier momento, y si MD_RECOVERY_FROZEN se borra mientras la matriz está suspendida, un nuevo sync_thread puede iniciarse inesperadamente. Solucione este problema al no permitir que raid_message() cambie el estado de sync_thread durante la suspensión. Tenga en cuenta que después de confirmar f52f5c71f3d4 ("md: arreglar la detención del hilo de sincronización"), la prueba shell/lvconvert-raid-reshape.sh comienza a bloquearse en stop_sync_thread(), y con las correcciones anteriores, la prueba ya no se bloqueará allí, sin embargo , la prueba seguirá fallondo y se quejará de que ext4 está dañado. Y con este parche, la prueba no se bloqueará debido a stop_sync_thread() ni fallará debido a que ext4 ya está dañado. Sin embargo, todavía hay un punto muerto relacionado con dm-raid456 que se solucionará en los siguientes parches.
  • Vulnerabilidad en kernel de Linux (CVE-2024-35803)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/efistub: llame a los servicios de arranque en modo mixto en la pila del firmware. Normalmente, el código auxiliar de EFI llama a los servicios de arranque de EFI utilizando la pila que estaba activa cuando se ingresó el código auxiliar. Según la especificación UEFI, esta pila debe tener un tamaño mínimo de 128k; esto puede parecer grande, pero todo el procesamiento asíncrono y el manejo de eventos en EFI se ejecutan desde la misma pila, por lo que en la práctica se puede utilizar bastante espacio. En modo mixto, la situación es un poco diferente: el gestor de arranque llama al punto de entrada del código auxiliar EFI de 32 bits, que llama al punto de entrada de 32 bits del descompresor, donde se configura la pila de arranque, utilizando una asignación fija de 16k. Esta pila todavía está en uso cuando el código auxiliar EFI se inicia en modo de 64 bits, por lo que todas las llamadas al firmware EFI utilizarán la pila de arranque limitada del descompresor. Debido a la ubicación de la pila de arranque justo después del montón de arranque, cualquier desbordamiento de la pila pasa desapercibido. Sin embargo, la confirmación 5c4feadb0011983b ("x86/decompressor: Mover referencias de símbolos globales al código C") movió la definición del montón de arranque al código C, y ahora la pila de arranque se coloca justo en la base de BSS, donde cualquier desbordamiento dañará el final de la sección .data. Si bien sería posible solucionar este problema aumentando el tamaño de la pila de arranque, hacerlo afectaría a todos los sistemas x86, y los sistemas de modo mixto son una fracción pequeña (y cada vez menor) de la base instalada x86. En su lugar, registre el valor del puntero de la pila de firmware al ingresar desde el firmware de 32 bits y cambie a esta pila cada vez que se realice una llamada al servicio de arranque EFI.
  • Vulnerabilidad en kernel de Linux (CVE-2024-35810)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: corregida la vida útil de la memoria del cursor bo. La sanitización se puede realizar mientras la actualización atómica aún está activa, lo que significa que la memoria adquirida en la actualización atómica no necesita ser invalidado por la limpieza. Los objetos del búfer en vmw_plane_state, en lugar de utilizar el map_and_cache incorporado, intentaban manejar ellos mismos la vida útil de la memoria asignada, lo que provocaba fallos. Utilice map_and_cache en lugar de intentar administrar la vida útil de los objetos del búfer retenidos por vmw_plane_state. Corrige los errores del kernel en kms_cursor_legacy forked-bo de IGT.
  • Vulnerabilidad en kernel de Linux (CVE-2024-35816)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: firewire: ohci: evita la fuga de IRQ sobrante al desvincular confirmación5a95f1ded28691e6 ("firewire: ohci: usa devres para IRQ solicitada") también eliminó la llamada a free_irq() en pci_remove (), lo que lleva a un irq sobrante de devm_request_irq() en pci_disable_msi() en pci_remove() al desvincular el controlador del dispositivo remove_proc_entry: eliminando el directorio no vacío 'irq/136', filtrando al menos 'firewire_ohci' Call Trace:? remove_proc_entry+0x19c/0x1c0? __advertir+0x81/0x130 ? remove_proc_entry+0x19c/0x1c0? report_bug+0x171/0x1a0? console_unlock+0x78/0x120? handle_bug+0x3c/0x80? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? remove_proc_entry+0x19c/0x1c0 unregister_irq_proc+0xf4/0x120 free_desc+0x3d/0xe0? kfree+0x29f/0x2f0 irq_free_descs+0x47/0x70 msi_domain_free_locked.part.0+0x19d/0x1d0 msi_domain_free_irqs_all_locked+0x81/0xc0 pci_free_msi_irqs+0x12/0x40 pci_disable_msi+0x4c/0x60 pci_remove+0x9d/0xc0 [firewire_ohci 01b483699bebf9cb07a3d69df0aa2bee71db1b26] pci_device_remove+0x37/0xa0 dispositivo_release_driver_internal+ 0x19f/0x200 unbind_store+0xa1/0xb0 elimina irq con devm_free_irq() antes de pci_disable_msi() también elimínalo en fail_msi: de pci_probe() ya que esto conduciría a una fuga idéntica
  • Vulnerabilidad en kernel de Linux (CVE-2024-35817)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: amdgpu_ttm_gart_bind establece el indicador vinculado a gtt. De lo contrario, después de que se libera GTT bo, se libera el espacio GTT y gart, pero amdgpu_ttm_backend_unbind no borrará la entrada de la tabla de páginas de gart y dejará una asignación válida. entrada que apunta a la página del sistema obsoleto. Luego, si la GPU accede a la dirección de Gart por error, leerá un valor indefinido en lugar de un error de página, lo que será más difícil de depurar y reproducir el problema real.
  • Vulnerabilidad en kernel de Linux (CVE-2024-35818)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: define el gancho __io_aw() como mmiowb(). Confirmación fb24ea52f78e0d595852e ("drivers: elimina las invocaciones explícitas de mmiowb()") elimina todos los mmiowb() en los controladores, pero dice : "NOTA: mmiowb() solo ha garantizado el pedido junto con spin_unlock(). Sin embargo, emparejar cada eliminación de mmiowb() en este parche con la llamada correspondiente a spin_unlock() no es nada trivial, por lo que existe una pequeña posibilidad que este cambio puede hacer retroceder cualquier controlador que dependa incorrectamente de mmiowb() para ordenar escrituras MMIO entre CPU usando sincronización sin bloqueo". El mmio en radeon_ring_commit() está protegido por un mutex en lugar de un spinlock, pero en el mutex fastpath se comporta de manera similar al spinlock. Podemos agregar llamadas mmiowb() en el controlador radeon, pero el mantenedor dice que no le gusta esa solución, y radeon no es el único ejemplo de mmio protegido por mutex. Entonces deberíamos extender el sistema de seguimiento mmiowb de spinlock a mutex, y tal vez a otras primitivas de bloqueo. Esto no es fácil y propenso a errores, por lo que lo solucionamos en el código arquitectónico, simplemente definiendo el gancho __io_aw() como mmiowb(). Y ya no necesitamos anular queued_spin_unlock() así que use la definición genérica. Sin esto, obtenemos este error cuando ejecutamos 'glxgears' en arquitecturas de ordenamiento débiles como LoongArch: radeon 0000:04:00.0: el anillo 0 se detuvo durante más de 10324 mseg radeon 0000:04:00.0: el anillo 3 se detuvo durante más de 10240 mseg radeon 0000:04:00.0: bloqueo de GPU (ID de valla actual 0x000000000001f412 ID de última valla 0x000000000001f414 en el anillo 3) radeon 0000:04:00.0: Bloqueo de GPU (ID de valla actual 0x000000000000f940 ID de última valla 0x000 000000000f941 en el anillo 0) radeon 0000:04:00.0: la programación IB falló (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35)
  • Vulnerabilidad en kernel de Linux (CVE-2024-35824)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: lis3lv02d_i2c: corrige que los reguladores se activen/desactiven dos veces al suspender/reanudar Cuando no está configurado para reactivación, lis3lv02d_i2c_suspend() llamará a lis3lv02d_poweroff() incluso si el dispositivo ya ha sido desactivado por el controlador de suspensión de tiempo de ejecución y si está configurado para reactivación y el dispositivo está suspendido en tiempo de ejecución en este punto, no se vuelve a activar para que sirva como fuente de activación. Antes de la confirmación b1b9f7a49440 ("misc: lis3lv02d_i2c: Agregar configuración faltante de la devolución de llamada reg_ctrl"), lis3lv02d_poweroff() fallaba al deshabilitar los reguladores, lo que como efecto secundario hizo que llamar a poweroff() dos veces fuera correcto. Ahora que poweroff() desactiva correctamente los reguladores, al hacer esto dos veces se activa una ADVERTENCIA() en el núcleo del regulador: desactivaciones desequilibradas para regulador ficticio ADVERTENCIA: CPU: 1 PID: 92 en drivers/regulator/core.c:2999 _regulator_disable .. Corrija lis3lv02d_i2c_suspend() para que no llame a poweroff() una segunda vez si ya está suspendido el tiempo de ejecución y agregue una llamada a poweron() cuando sea necesario para que la reactivación funcione. lis3lv02d_i2c_resume() tiene problemas similares, con el inconveniente adicional de que siempre enciende el dispositivo si el tiempo de ejecución está suspendido, después de lo cual la primera reanudación del tiempo de ejecución llamará a poweron() nuevamente, lo que provocará que el recuento habilitado para el regulador aumente en 1 cada suspender/reanudar. Estas llamadas desequilibradas regulator_enable() hacen que el regulador nunca se apague y activan la siguiente ADVERTENCIA() al desvincular el controlador: ADVERTENCIA: CPU: 1 PID: 1724 en drivers/regulator/core.c:2396 _regulator_put Solucione esto haciendo lis3lv02d_i2c_resume( ) refleja la nueva suspensión().
  • Vulnerabilidad en kernel de Linux (CVE-2024-35826)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloquear: corregidos recuentos de páginas para buffers no alineados en __bio_release_pages() Corrige un número incorrecto de páginas que se liberan para buffers que no comienzan al principio de una página.
  • Vulnerabilidad en kernel de Linux (CVE-2024-35831)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corregida la liberación de páginas fijadas cuando falla __io_uaddr_map. Mirando la ruta de error de __io_uaddr_map, si fallamos después de fijar las páginas por cualquier motivo, ret se establecerá en -EINVAL y el El controlador de errores no libera correctamente las páginas fijadas. No logré activarlo sin forzar un fallo, pero puede suceder en la vida real cuando la memoria está muy fragmentada.
  • Vulnerabilidad en kernel de Linux (CVE-2024-35841)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: tls, corrija la ADVERTENCIA en __sk_msg_free Un empalme con MSG_SPLICE_PAGES hará que el código tls use la ruta tls_sw_sendmsg_splice en el código TLS sendmsg para mover las páginas proporcionadas por el usuario del msg al msg_pl . Esto recorrerá el mensaje hasta que msg_pl esté lleno, verificado por sk_msg_full(msg_pl). El usuario también puede configurar el indicador MORE para que la pila de sugerencias retrase el envío hasta recibir más páginas e idealmente un búfer completo. Si el usuario agrega más páginas al mensaje de las que caben en la lista de dispersión msg_pl (MAX_MSG_FRAGS), debemos ignorar el indicador MÁS y enviar el búfer de todos modos. Sin embargo, lo que realmente sucede es que abortamos la configuración de la lista de dispersión de msg a msg_pl y luego, como nos olvidamos de configurar el 'registro completo', lo que indica que ya no podemos consumir datos sin un envío, pasamos a la ruta 'continuar' que verificará si msg_data_left(msg) tiene más bytes para enviar y luego intenta incluirlos en el msg_pl que ya está completo. Luego, la próxima iteración del remitente que realiza el envío encontrará un msg_pl completo y arrojará la advertencia en el informe syzbot. Para solucionarlo, simplemente verifique si tenemos un registro completo en la ruta del código de empalme y, si no, envíe el mensaje independientemente del indicador MORE.
  • Vulnerabilidad en kernel de Linux (CVE-2024-35844)
    Severidad: MEDIA
    Fecha de publicación: 17/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: compress: corrige el error de conteo de reserve_cblocks cuando no hay espacio. Cuando un archivo solo necesita un direct_node, realizar las siguientes operaciones hará que el archivo no se pueda reparar: unisoc # ./f2fs_io compress test.apk unisoc #df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.2M 100% /data unisoc # ./f2fs_io release_cblocks test.apk 924 unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 4,8M 100% /data unisoc # dd if=/dev/random of=file4 bs=1M count=3 3145728 bytes (3,0 M) copiados, 0,025 s, 120 M/s unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS falló: no queda espacio en el dispositivo adb reboot unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 0 Esto se debe a que el archivo tiene solo un nodo_directo. Después de regresar a -ENOSPC, reserve_blocks += ret no se ejecutará. Como resultado, los bloques_reservados en este momento siguen siendo 0, que no es el número real de bloques reservados. Por lo tanto, no se puede configurar fsck para reparar el archivo. Después de este parche, se configurará el indicador fsck para solucionar este problema. unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS falló: no queda espacio en el dispositivo y al reinicio del adb luego se ejecutará fsck unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 924
  • Vulnerabilidad en kernel de Linux (CVE-2024-35860)
    Severidad: MEDIA
    Fecha de publicación: 19/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: se admite el aplazamiento de la asignación de bpf_link después del período de gracia de RCU. El enlace BPF para algunos tipos de programas se pasa como un "contexto" que pueden utilizar esos programas BPF para buscar información adicional. Por ejemplo, para multi-kprobes y multi-uprobes, el enlace se utiliza para recuperar valores de cookies BPF. Debido a esta dependencia del tiempo de ejecución, cuando bpf_link refcnt cae a cero, todavía podría haber programas BPF activos ejecutándose y accediendo a los datos del enlace. Este parche agrega soporte genérico para diferir la devolución de llamada de bpf_link dealloc después de RCU GP, si se solicita. Esto se hace exponiendo dos devoluciones de llamada de desasignación diferentes, una sincrónica y otra diferida. Si se proporciona uno diferido, bpf_link_free() programará la devolución de llamada de dealloc_deferred() para que se realice después de RCU GP. BPF utiliza dos tipos de RCU: uno "clásico" que no se puede dormir y uno de seguimiento de tareas de RCU. Este último se utiliza cuando se utilizan programas BPF que se pueden dormir. bpf_link_free() se adapta a eso al verificar el indicador de suspensión del programa BPF subyacente, y pasa por la GP de RCU normal solo para los no dormidos, o a través de tareas de RCU rastrean la GP *y* luego la GP de RCU normal (teniendo en cuenta la optimización de rcu_trace_implies_rcu_gp()), si El programa BPF se puede dormir. Usamos esto para enlaces multi-kprobe y multi-uprobe, que desreferencian el enlace durante la ejecución del programa. También cambiamos preventivamente el enlace raw_tp para usar la devolución de llamada de dealloc diferida, ya que los próximos cambios en el árbol bpf-next también exponen los datos del enlace raw_tp (específicamente, el valor de la cookie) al programa BPF en tiempo de ejecución.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52787)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: blk-mq: asegúrese de que el uso de la cola activa se mantenga para bio_integrity_prep() blk_integrity_unregister() puede aparecer si el contador de uso de la cola no se mantiene para una biografía con integridad preparada, por lo que esta solicitud se puede completar llamando al perfil->complete_fn, luego kernel panic. Otra restricción es que es necesario llamar a bio_integrity_prep() antes de la fusión biológica. Solucione el problema de la siguiente manera: - llame a bio_integrity_prep() con un contador de uso de cola capturado de manera confiable - llame a bio_integrity_prep() antes de fusionar la biografía
  • Vulnerabilidad en kernel de Linux (CVE-2023-52791)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: core: ejecute atomic i2c xfer cuando !preemptible. Desde bae1d3a05a8b, las transferencias i2c no son atómicas si la preferencia está deshabilitada. Sin embargo, las transferencias i2c no atómicas requieren preferencia (por ejemplo, en wait_for_completion() mientras se espera el DMA). pánico() llama a preempt_disable_notrace() antes de llamar a emergence_restart(). Por lo tanto, si se utiliza un dispositivo i2c para el reinicio, el xfer debe ser atómico. Esto evita advertencias como: [12.667612] ADVERTENCIA: CPU: 1 PID: 1 en kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0 [12.676926] ¡Cambio de contexto voluntario dentro de la sección crítica del lado de lectura de RCU! ... [12.742376] Schedule_timeout de wait_for_completion_timeout+0x90/0x114 [12.749179] wait_for_completion_timeout de tegra_i2c_wait_completion+0x40/0x70 ... [12.994527] atomic_notifier_call_chain de machine_restart+0x34/0x58 13.001050] machine_restart desde panic+0x2a8/0x32c Utilice !preemptible( ) en su lugar, que es básicamente la misma verificación que la versión anterior a la v5.2.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52797)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: perf: Verifique el valor de retorno de find_first_bit(). Debemos verificar el valor de retorno de find_first_bit() antes de usar el valor de retorno como una matriz de índice ya que sucede que desborda la matriz y luego pánico: [107.318430] BUG del kernel [#1] [107.319434] CPU: 3 PID: 1238 Comm: kill Contaminado: GE 6.6.0-rc6ubuntu-defconfig #2 [ 107.319465] Nombre de hardware: riscv-virtio,qemu (DT) [ 107.319551] epc: pmu_sbi_ovf_handler+0x3a4/0x3ae [107.319840] ra: pmu_sbi_ovf_handler+0x52/0x3ae [107.319868] epc: ffffffff80a0a77c ra: ffffffff80a0a42a sp: 83fecda350 [ 107.319884] gp : ffffffff823961a8 tp : ffffaf8083db1dc0 t0 : ffffaf83fecda480 [ 107.319899] t1 : ffffffff80cafe62 t2 : 000000000000ff00 s0 : ffffaf83fecda520 [ 107.319921] s1 : ffffaf83fecda380 a0 : 00000018fca29df0 a1 : ffffffffffffffff [ 107.319936] a2 : 000000000107373 4 a3: 0000000000000004 a4: 0000000000000000 [107.319951] a5: 0000000000000040 a6: 000000001d1c8774 a7: 000000000504d55 [107.3199 65] s2: ffffffff82451f10 s3: ffffffff82724e70 s4: 000000000000003f [107.319980] s5: 0000000000000011 s6: ffffaf8083db27c0 s7: 00000000000000000 [107.319995] s8: 000000000000 0001 s9: 00007fffb45d6558 s10: 00007fffb45d81a0 [107.320009] s11: ffffaf7ffff60000 t3: 00000000000000004 t4: 0000000000000000 [ 107.320 023] t5: ffffaf7f80000000 t6: ffffaf8000000000 [107.320037 ] estado: 0000000200000100 badaddr: 00000000000000000 causa: 0000000000000003 [ 107.320081] [] pmu_sbi_ovf_handler+0x3a4/0x3ae [ 107.3201 12] [] handle_percpu_devid_irq+0x9e/0x1a0 [ 107.320131] [] generic_handle_domain_irq+0x28/0x36 [ 107.320148] [] riscv_intc_irq+0x36/0x4e [ 107.320166] [] handle_riscv_irq+0x54/0x86 [ 107.320189] [] _irq+0x64/0x96 [ 107.320271] Código: 85a6 855e b097 ff7f 80e7 9220 b709 9002 4501 bbd9 (9002) 6097 [107.320585] ---[ seguimiento final 0000000000000000 ]--- [ 107.320704] Pánico del kernel - no se sincroniza: excepción fatal en interrupción [ 107.320775] SMP: deteniendo CPU secundarias [ 107.32121 9]Compensación del kernel: 0x0 desde 0xffffffff80000000 [107.333051] ---[ fin del pánico del kernel - no se sincroniza: excepción fatal en la interrupción ]---
  • Vulnerabilidad en kernel de Linux (CVE-2023-52813)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: crypto: pcrypt - Reparar hungtask para PADATA_RESET. Encontramos un error de hungtask en test_aead_vec_cfg de la siguiente manera: INFORMACIÓN: tarea cryptomgr_test:391009 bloqueada durante más de 120 segundos. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. Seguimiento de llamadas: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 Schedule+0xd8/0x1b4 Schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_ve c_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+ 0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 kernel panic - no syncing: hung_task: tareas bloqueadas para el error for_completion (&esperar->finalización) en test_aead_vec_cfg. En caso normal, se llamará aead_request_complete() en pcrypt_aead_serial y el error de retorno es 0 para padata_do_parallel. Pero, cuando pinst->flags es PADATA_RESET, el error de retorno es -EBUSY para padata_do_parallel y no llamará a aead_request_complete(). Por lo tanto, test_aead_vec_cfg se colgará en wait_for_completion(&wait->completion), lo que provocará que se cuelgue la tarea. El problema viene de la siguiente manera: (padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | si (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return err Para resolver el problema, reemplazamos el retorno err -EBUSY con -EAGAIN, lo que significa que los datos_paralelos están cambiando y la persona que llama debe llamarlo nuevamente. v3: elimine el reintento y simplemente cambie el error de devolución. v2: introduce padata_try_do_parallel() en pcrypt_aead_encrypt y pcrypt_aead_decrypt para resolver la tarea colgada.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52828)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Detectar IP == ksym.end como parte del programa BPF. Ahora que bpf_throw kfunc es la primera instrucción de llamada que no tiene semántica de retorno dentro del verificador, esto también activa el código muerto eliminación de formas sin precedentes. Por un lado, cualquier instrucción que siga a una llamada a bpf_throw nunca se marcará como vista. Además, si una cadena de llamadas termina lanzándose, cualquier instrucción posterior a la instrucción de llamada al subprog que finalmente se lance en las personas que llaman tampoco se marcará como vista. La forma tentadora de solucionar este problema sería emitir instrucciones 'int3' adicionales que superen el jited_len de un programa y garantizar que, durante el tiempo de ejecución, cuando se inicia un programa, podamos descubrir sus límites incluso si la instrucción de llamada a bpf_throw (o a subprogs que siempre tirar) se emite como instrucción final en el programa. Un ejemplo de un programa de este tipo sería este: do_something(): ... r0 = 0 salir foo(): r1 = 0 llamar a bpf_throw r0 = 0 salir de la barra (cond): si r1 != 0 ir a pc+2 llamar a hacer_algo exit call foo r0 = 0 // Nunca visto por el verificador exit // main(ctx): r1 = ... call bar r0 = 0 exit Aquí, si terminamos lanzando, el seguimiento de pila sería el siguiente: bpf_throw foo bar main En bar, la instrucción final emitida será la llamada a foo, como tal, la dirección de retorno será la instrucción posterior (que el JIT emite como int3 en x86). Esto terminará quedando fuera del jited_len del programa, por lo tanto, al desenrollarlo, no podremos descubrir que la dirección del remitente pertenece a ningún programa y terminaremos en pánico debido al desenrollado poco confiable de la pila de programas BPF que nunca esperamos. Para remediar este caso, haga que bpf_prog_ksym_find trate IP == ksym.end como parte del programa BPF, de modo que is_bpf_text_address devuelva verdadero cuando ocurra tal caso, y podamos desenredarlo de manera confiable cuando la instrucción final termine siendo una instrucción de llamada.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52834)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: atl1c:workaround al problema de desbordamiento de DMA RX. Esto se basa en la confirmación del controlador alx 881d0327db37 ("net: alx: solución alternativa al problema de desbordamiento de DMA RX"). Los controladores alx y atl1c tenían un error de desbordamiento de RX, por lo que se creó un asignador personalizado para evitar ciertas direcciones. Luego se creó la solución más simple para el controlador alx, pero no para atl1c debido a la falta de un probador. En lugar de utilizar un asignador personalizado, verifique la dirección skb asignada y use skb_reserve() para alejarse de la dirección problemática 0x...fc0. Probado en AR8131 en Acer 4540.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52839)
    Severidad: BAJA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: controladores: perf: no transmitir a otras CPU al iniciar un contador. Este comando: $ perf record -e ciclos:k -e instrucciones:k -c 10000 -m 64M dd if =/dev/zero of=/dev/null count=1000 da lugar a esta advertencia del kernel: [444.364395] ADVERTENCIA: CPU: 0 PID: 104 en kernel/smp.c:775 smp_call_function_many_cond+0x42c/0x436 [444.364515] Módulos vinculados en: [ 444.364657] CPU: 0 PID: 104 Comm: perf-exec No contaminado 6.6.0-rc6-00051-g391df82e8ec3-dirty #73 [ 444.364771] Nombre de hardware: riscv-virtio,qemu (DT) [ 444.364868] epc : smp_call_function_many_cond+0x42c/0x436 [ 444.364917] ra : on_each_cpu_cond_mask+0x20/0x32 [ 444.364948] epc : ffffffff8009f9e0 ra : ffffffff8009fa5a sp : ff20000000003800 [ 444.364966] gp : ffffffff81500aa0 tp : ff60000002b83000 t0 : ff200000000038c0 [ 444.364982] t1 : ffffffff815021f0 t2 : 000000000000001f s0 : ff200000000038b0 [444.364998] s1: ff60000002c54d98 a0: ff60000002a73940 a1: 0000000000000000 [444.365013] a2: 0000000000000000 a3 : 0000000000000003 a4 : 0000000000000100 [ 444.365029 ] a5 : 000000000010100 a6 : 0000000000f00000 a7 : 0000000000000000 [ 444.365044] s2: 0000000000000000 s3: ffffffffffffffff s4: ff60000002c54d98 [ 444.365060] s5: ffffffff81539610 s6: ffffffff80c20c48 s7: 0000000000000000 [444.365075] s8: 0000000000000000 s9: 0000000000000001 s10: 0000000000000001 [444.365090] s11: ffffffff80099394 t3: 0000000000000003 t4: 00000000eac0c6e6 [444.365104] t5: 0000000400000000 t6: ff60000002e010d0 [444.365120] estado: 0000000200000100 badaddr: 0000000000000000 causa: 0000000000000003 [444.365226] [] smp_call_function_many_cond+0x42c/0x436 [444.365295] [] on_each_cpu_cond_mask+0x20/0x32 [ 444.365311] [] pmu_sbi_ctr_start+0x7a/0xaa [ 444.365327] [< ffffffff806e880c>] riscv_pmu_start+0x48/0x66 [ 444.365339] [] perf_adjust_freq_unthr_context+0x196/0x1ac [ 444.365356] [] _task_tick+0x78/0x8c [ 444.365368] [] scheduler_tick+0xe6/0x25e [ 444.365383] [] update_process_times+0x80/0x96 [ 444.365398] [] tick_sched_handle+0x26/0x52 [ 444.365410] [] [ 444.365422] [] __hrtimer_run_queues+0x126/0x18a [ 444.365433] [] hrtimer_interrupt+0xce/0x1da [ 444.365444] [] riscv_timer_interrupt+0x30/0x3a [ 444.365457] [] cpu_devid_irq+0x80/0x114 [ 444.365470] [] generic_handle_domain_irq+0x1c/ 0x2a [ 444.365483] [] riscv_intc_irq+0x2e/0x46 [ 444.365497] [] handle_riscv_irq+0x4a/0x74 [ 444.365521 [] do_irq+0x7c/0x7e [ 444.365796] ---[ final de seguimiento 0000000000000000 ]--- Esto se debe a que la solución en la confirmación 3fec323339a4 ("drivers: perf: Fix panic in riscv SBI mmap support") era incorrecta ya que no hay necesidad de transmitir a otras CPU al iniciar un contador, eso solo es necesario en mmap cuando el Es posible que los contadores ya se hayan iniciado en otras CPU, así que simplemente elimine esta transmisión.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52853)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hid: cp2112: corrige la inicialización duplicada de la cola de trabajo. Anteriormente, el controlador cp2112 llamaba INIT_DELAYED_WORK dentro de cp2112_gpio_irq_startup, lo que generaba inicializaciones duplicadas de la cola de trabajo en inicios IRQ posteriores después de una solicitud inicial. Esto resultó en una advertencia en set_work_data en workqueue.c, así como en una rara desreferencia NULL dentro de process_one_work en workqueue.c. En su lugar, inicialice la cola de trabajo dentro de _probe.
  • CVE-2023-52868
    Severidad: ALTA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: térmica: núcleo: evita un posible desbordamiento de cadenas. El valor dev->id proviene de ida_alloc(), por lo que es un número entre cero e INT_MAX. Si es demasiado alto, estos sprintf()s se desbordarán.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52871)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: llcc: Manejar un segundo dispositivo sin corrupción de datos. Generalmente solo hay un dispositivo llcc. Pero si hubiera un segundo, incluso una llamada de sonda fallida modificaría el puntero global drv_data. Así que verifique si drv_data es válido antes de sobrescribirlo.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52874)
    Severidad: MEDIA
    Fecha de publicación: 21/05/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/tdx: Ponga a cero el RSI que falta en la macro TDX_HYPERCALL. En el conjunto TDX_HYPERCALL, después de que la instrucción TDCALL regresa del VMM que no es de confianza, los registros que el invitado TDX comparte con el VMM necesitan debe borrarse para evitar la ejecución especulativa de los valores proporcionados por VMM. RSI se especifica en el mapa de bits de esos registros, pero falta al poner a cero esos registros en el TDX_HYPERCALL actual. Estaba allí cuando se agregó originalmente en la confirmación 752d13305c78 ("x86/tdx: Expand__tdx_hypercall() to handle more arguments"), pero luego se eliminó en la confirmación 1e70c680375a ("x86/tdx: Do not corrupt frame-pointer in __tdx_hypercall( )"), lo cual era correcto porque %rsi se restaura posteriormente en el "pop %rsi". Sin embargo, una confirmación posterior 7a3a401874be ("x86/tdx: Drop flags from __tdx_hypercall()") eliminó ese "pop %rsi" pero olvidó volver a agregar "xor %rsi, %rsi". Solucionadlo volviéndolo a agregar.
  • Vulnerabilidad en Intrado 911 Emergency Gateway (CVE-2024-1839)
    Severidad: CRÍTICA
    Fecha de publicación: 26/06/2024
    Fecha de última actualización: 26/09/2025
    El formulario de inicio de sesión de Intrado 911 Emergency Gateway es vulnerable a una inyección SQL blind basada en tiempo no autenticada, que puede permitir que un atacante remoto no autenticado ejecute código malicioso, extraiga datos o manipule la base de datos.
  • Vulnerabilidad en IPWorks (CVE-2024-6580)
    Severidad: BAJA
    Fecha de publicación: 08/07/2024
    Fecha de última actualización: 26/09/2025
    Se puede inducir al componente SFTPServer de la librería SSH de IPWorks del software /n a realizar solicitudes no deseadas de ruta de red o de sistema de archivos al cargar un certificado o clave pública SSH. Para ser explotable, una aplicación que llama al componente SFTPServer debe otorgar acceso al usuario sin verificar la clave pública o el certificado SSH (lo que probablemente sería una vulnerabilidad separada en la aplicación que llama). Las versiones 22.0.8945 y 24.0.8945 de IPWorks SSH se lanzaron para abordar esta condición mediante el bloqueo de todas las solicitudes de rutas de red y sistemas de archivos para claves públicas o certificados SSH.
  • Vulnerabilidad en kernel de Linux (CVE-2024-41069)
    Severidad: ALTA
    Fecha de publicación: 29/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: topología: corrige referencias a la memoria liberada. La mayoría de los usuarios, después de analizar un archivo de topología, liberan la memoria utilizada por este, por lo que tener referencias de puntero directamente al contenido del archivo de topología es incorrecto. Utilice devm_kmemdup() para asignar memoria según sea necesario.
  • Vulnerabilidad en kernel de Linux (CVE-2024-41074)
    Severidad: ALTA
    Fecha de publicación: 29/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: archivos de caché: establece el objeto para que se cierre si ondemand_id < 0 en copen. Si se llama maliciosamente a copen en el modo de usuario, puede eliminar la solicitud correspondiente a la identificación aleatoria. Y es posible que la solicitud aún no se haya leído. Tenga en cuenta que cuando el objeto está configurado para reabrirse, la solicitud de apertura se realizará con el estado aún reabierto en el caso anterior. Como resultado, la solicitud correspondiente a este objeto siempre se omite en la función select_req, por lo que la solicitud de lectura nunca se completa y bloquea otros procesos. Solucione este problema simplemente configurando el objeto para que se cierre si su id <0 en copen.
  • Vulnerabilidad en kernel de Linux (CVE-2024-41078)
    Severidad: MEDIA
    Fecha de publicación: 29/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: btrfs:qgroup: arregla fuga de cuota raíz tras fallo de desactivación de cuota Si durante la desactivación de cuota fallamos al limpiar el árbol de cuotas o al borrar el root del árbol raíz, saltamos al etiqueta 'out' sin eliminar la referencia en la raíz de la cuota, lo que resulta en una pérdida de la raíz ya que fs_info->quota_root ya no apunta a la raíz (la hemos configurado en NULL justo antes de esos pasos). Solucione este problema realizando siempre una llamada btrfs_put_root() bajo la etiqueta 'out'. Este es un problema que existe desde que qgroups se agregaron por primera vez en 2012 mediante el compromiso bed92eae26cc ("Btrfs: implementación y prototipos de qgroup"), pero en aquel entonces nos perdimos un kfree en la cuota raíz y llamadas free_extent_buffer() en su raíz y en los nodos raíz de confirmación. , ya que en aquel entonces las raíces aún no se contaban como referencia.
  • Vulnerabilidad en kernel de Linux (CVE-2023-52887)
    Severidad: MEDIA
    Fecha de publicación: 29/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: can: j1939: manejo de errores mejorado para mensajes RTS recibidos estrechamente en xtp_rx_rts_session_new Este parche mejora el manejo de errores en escenarios con mensajes RTS (Solicitud de envío) que llegan cerca. Reemplaza los rastreos WARN_ON_ONCE menos informativos con un nuevo método de manejo de errores. Esto proporciona mensajes de error más claros y permite la finalización anticipada de sesiones problemáticas. Anteriormente, las sesiones sólo se publicaban al final de j1939_xtp_rx_rts(). Potencialmente, esto podría reproducirse con algo como: testj1939 -r vcan0:0x80 & while true; hacer # enviar primero RTS cansend vcan0 18EC8090#1014000303002301; # enviar segundo RTS cansend vcan0 18EC8090#1014000303002301; # enviar cancelar cansend vcan0 18EC8090#ff00000000002301; hecho
  • Vulnerabilidad en kernel de Linux (CVE-2024-42086)
    Severidad: ALTA
    Fecha de publicación: 29/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: iio:chemical:bme680: Corregir desbordamientos en funciones de compensación(). Hay casos en las funciones de compensación del controlador en los que se pueden producir desbordamientos de variables por operaciones de cambio de bits. Estas implicaciones se discutieron inicialmente aquí [1] y se mencionaron en el mensaje de registro del compromiso 1b3bd8592780 ("iio: químico: agregar soporte para el sensor Bosch BME680"). [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/
  • Vulnerabilidad en kernel de Linux (CVE-2024-42092)
    Severidad: ALTA
    Fecha de publicación: 29/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: gpio: davinci: valida el número de IRQ obtenidos. El valor de pdata->gpio_unbanked se toma del árbol de dispositivos. En caso de DT roto debido a algún error, este valor puede ser cualquiera. Sin esta validación de valor, puede haber acceso sin chips->irqs a los límites de la matriz en davinci_gpio_probe(). Valide el valor nirq obtenido para que no exceda el número máximo de IRQ por banco. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.
  • Vulnerabilidad en kernel de Linux (CVE-2024-42100)
    Severidad: MEDIA
    Fecha de publicación: 30/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: sunxi-ng: common: no llame a hw_to_ccu_common en hw sin common Para establecer el rango de velocidad de un hw, sunxi_ccu_probe llama a hw_to_ccu_common() asumiendo todas las entradas en desc- >ccu_clks están contenidos en una estructura ccu_common. Esta suposición es incorrecta y, en consecuencia, provoca desreferencias de punteros no válidas. Eliminar la llamada defectuosa. En su lugar, agregue un bucle más que itere sobre ccu_clks y establezca el rango de velocidad, si es necesario.
  • Vulnerabilidad en kernel de Linux (CVE-2024-42103)
    Severidad: MEDIA
    Fecha de publicación: 30/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige la adición de un grupo de bloques a una lista de recuperación y la lista no utilizada durante la recuperación. Existe una posible adición de lista paralela para volver a intentarlo en btrfs_reclaim_bgs_work y agregarla a la lista no utilizada. Dado que el grupo de bloques se elimina de la lista de recuperación y se encuentra en un trabajo de reubicación, se puede agregar a la lista no utilizada en paralelo. Cuando eso sucede, agregarlo a la lista de recuperación dañará el encabezado de la lista y provocará una corrupción en la lista como se muestra a continuación. Solucionarlo tomando fs_info->unused_bgs_lock. [177.504][T2585409] Error BTRFS (dispositivo nullb1): error al reubicar ch= unk 2415919104 [177.514][T2585409] corrupción list_del. siguiente->anterior debería ser ff1100= 0344b119c0, pero era ff11000377e87c70. (next=3Dff110002390cd9c0) [177.529][T2585409] ------------[ cortar aquí ]------------ [177.537][T2585409] ERROR del kernel en lib/ list_debug.c:65! [177.545][T2585409] Ups: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN NOPTI [177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Contaminado: GW 6.10.0-rc5-kts # 1 [177.568][T2585409] Nombre de hardware: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 14/02/2022 [177.579][T2585409] Cola de trabajo: events_unbound btrfs_reclaim_bgs_work[btrfs] [177.589][T2585409] QEPD: 0010 :__list_del_entry_valid_or_report.cold+0x70/0x72 [177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286 [177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000 [177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI :ffe21c006efd0f40 [177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08 [177.665][T2585409] R10: 7847 R11: 0000000000000000 R12:ff110002390cd9c0 [177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000 [177. 687] [T2585409] FS: 0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000 [177.700][T2585409] CS: 0010 DS: 0000 ES: 0000 CR0: 00000080050033 [177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4: 0000000000771ef0 [177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000 [177.731][T2585409] DR3: 00000000 DR6: 00000000fffe0ff0 DR7:0000000000000400 [177.742][T2585409] PKRU: 55555554 [177.748][T2585409] Seguimiento de llamadas: [ 177.753][T2585409] [177.759][T2585409] ? __die_body.cold+0x19/0x27 [177.766][T2585409] ? morir+0x2e/0x50 [177.772][T2585409] ? do_trap+0x1ea/0x2d0 [177.779][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.788][T2585409] ? do_error_trap+0xa3/0x160 [177.795][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.805][T2585409] ? handle_invalid_op+0x2c/0x40 [177.812][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.820][T2585409] ? exc_invalid_op+0x2d/0x40 [177.827][T2585409] ? asm_exc_invalid_op+0x1a/0x20 [177.834][T2585409] ? __list_del_entry_valid_or_report.cold+0x70/0x72 [177.843][T2585409] btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs] Hay un código retry_list similar en btrfs_delete_unused_bgs(), pero es seguro, AFAICS. Dado que el grupo de bloques estaba en la lista no utilizada, los bytes usados deberían ser 0 cuando se agregó a la lista no utilizada. Luego, verifica que block_group->{used,reserved,pinned} todavía sean 0 bajo block_group->lock. Por lo tanto, aún deberían ser elegibles para la lista no utilizada, no para la lista de recuperación. La razón por la que es seguro allí es porque mantenemos space_info->groups_sem en modo de escritura. Eso significa que ninguna otra tarea puede asignar desde el grupo de bloques, por lo que mientras estamos en deleted_unused_bgs() no es posible que otras tareas asignen y desasignen extensiones del grupo de bloques, por lo que no se pueden agregar a la lista no utilizada ni a la reclamación. lista por cualquier otra persona. El error puede repro ---truncado---
  • Vulnerabilidad en kernel de Linux (CVE-2024-42105)
    Severidad: ALTA
    Fecha de publicación: 30/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: corrige las comprobaciones del rango de números de inodos. Serie de parches "nilfs2: soluciona posibles problemas relacionados con los inodos reservados". Esta serie corrige un problema de use after free reportado por syzbot, causado por la exposición del inodo interno de nilfs2 en el espacio de nombres de un sistema de archivos corrupto, y un par de fallos que causan problemas si el número inicial de inodos no reservados escritos en el -El superbloque de disco se cambia intencionalmente (o de forma corrupta) de su valor predeterminado. Este parche (de 3): En la implementación actual de nilfs2, "nilfs->ns_first_ino", que proporciona el primer número de inodo no reservado, se lee del superbloque, pero no se verifica su límite inferior. Como resultado, si en el parámetro de superbloque se establece un número que se superpone con el rango de números de inodos reservados, como el directorio raíz o los archivos de metadatos, las macros de prueba de números de inodos (NILFS_MDT_INODE y NILFS_VALID_INODE) no funcionarán correctamente. Además, estas macros de prueba utilizan cálculos de desplazamiento de bits a la izquierda utilizando el número de inodo como recuento de desplazamiento a través de la macro BIT, pero el resultado de un cálculo de desplazamiento que excede el ancho de bits de un número entero no está definido en la especificación C, por lo que si "ns_first_ino" está configurado en un valor grande distinto del valor predeterminado NILFS_USER_INO (=11), es posible que las macros no funcionen correctamente según el entorno. Solucione estos problemas verificando el límite inferior de "nilfs->ns_first_ino" y evitando cambios de bits iguales o mayores que la constante NILFS_USER_INO en las macros de prueba de número de inodo. Además, cambie el tipo de "ns_first_ino" de entero con signo a entero sin signo para evitar la necesidad de conversión de tipos en comparaciones como la verificación de límite inferior introducida esta vez.
  • Vulnerabilidad en kernel de Linux (CVE-2024-42111)
    Severidad: MEDIA
    Fecha de publicación: 30/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: siempre haga las comprobaciones básicas de la estructura btrfs_qgroup_inherit [ERROR] Syzbot informa la siguiente regresión detectada por KASAN: ERROR: KASAN: slab-out-of-bounds in btrfs_qgroup_inherit+0x42e/ 0x2e20 fs/btrfs/qgroup.c:3277 Lectura de tamaño 8 en la dirección ffff88814628ca50 por tarea syz-executor318/5171 CPU: 0 PID: 5171 Comm: syz-executor318 No contaminado 6.10.0-rc2-syzkaller-00010-g2ab7951410 95 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/04/2024 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm /kasan/report.c:377 [en línea] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 btrfs_qgroup_inherit+0x42e/0x2e20 fs/btrfs/qgroup. c:3277 create_pending_snapshot+0x1359/0x29b0 fs/btrfs/transaction.c:1854 create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1922 btrfs_commit_transaction+0xf20/0x3740 fs/btrfs/transaction.c:23 82 create_snapshot+0x6a1/0x9e0 fs/btrfs/ioctl.c:875 btrfs_mksubvol+0x58f/0x710 fs/btrfs/ioctl.c:1029 btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1075 __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c: 1340 btrfs_ioctl_snap_create_v2+0x1f2/0x3a0 fs/btrfs/ioctl.c:1422 btrfs_ioctl+0x99e/0xc60 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:907 [en línea] __se_sys_ioctl+0xfc/0x170 fs/ioctl .c:893 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcbf1992509 RSP: 002b:00007fcbf1928218 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcbf1a1f618 RCX: 00007fcbf1992509 RDX: 0000000020000280 RSI: 0000000050 009417 RDI: 0000000000000003 RBP: 00007fcbf1a1f610 R08: 00007ffea1298e97 R09: 00000000000000000 R10: 0000000000000000 R11: 00000000000000 246 R12: 00007fcbf19eb660 R13: 00000000200002b8 R14: 00007fcbf19e60c0 R15: 0030656c69662f2e Y también lo fijó para confirmar b5357cb268c4 ("btrfs: qgroup: no marque la herencia de qgroup si qgroup está deshabilitado"). [CAUSA] Esa confirmación infractora omite toda la verificación de herencia de qgroup si qgroup no está habilitado. Pero eso también omite las comprobaciones más básicas como num_ref_copies/num_excl_copies y las comprobaciones del tamaño de la estructura. Es decir, si se produce una carrera de habilitación/deshabilitación de qgroup en segundo plano y pasamos una estructura btrfs_qgroup_inherit cuando qgroup está deshabilitado, la verificación se omitirá por completo. Luego, en el momento del compromiso de la transacción, qgroup se vuelve a habilitar y btrfs_qgroup_inherit() utilizará la estructura incorrecta y provocará el error KASAN anterior. [FIX] Haga que btrfs_qgroup_check_inherit() solo omita las comprobaciones de qgroup de origen. De modo que incluso si se pasa una estructura btrfs_qgroup_inherit no válida, aún podemos rechazar las no válidas sin importar si qgroup está habilitado o no. Además, ya tenemos una seguridad adicional dentro de btrfs_qgroup_inherit(), que simplemente ignoraría las fuentes de qgroup no válidas, por lo que incluso si solo nos saltamos la verificación de la fuente de qgroup, todavía estamos a salvo.
  • Vulnerabilidad en kernel de Linux (CVE-2024-42113)
    Severidad: MEDIA
    Fecha de publicación: 30/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: txgbe: inicializa num_q_vectors para interrupciones MSI/INTx Cuando se utilizan interrupciones MSI/INTx, wx->num_q_vectors no está inicializado. Por lo tanto, habrá pánico en el kernel en wx_alloc_q_vectors() para asignar vectores de cola.
  • Vulnerabilidad en kernel de Linux (CVE-2024-42115)
    Severidad: MEDIA
    Fecha de publicación: 30/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: jffs2: corrija el posible acceso ilegal a la dirección en jffs2_free_inode Durante la prueba de esfuerzo del sistema de archivos jffs2, se encontraron las siguientes impresiones anormales: [2430.649000] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 0069696969696948 [ 2430.649622] Información de cancelación de memoria: [ 2430.649829] ESR = 0x96000004 [ 2430.650115] EC = 0x25: DABT (EL actual), IL = 32 bits [ 2430.650564] SET = 0, FnV = 0 [ 2430.650795] EA = 0, S1PTW = 0 [ 2430.651032] FSC = 0x04: error de traducción de nivel 0 [ 2430.651446] Información de cancelación de datos: [ 2430.651683] ISV = 0, ISS = 0x00000004 [ 2430.652001] CM = 0, WnR = 0 [ 2430.652558] [0069696969696948] dirección entre usuario y kernel rangos de direcciones [2430.653265] Error interno: Ups: 96000004 [#1] PREEMPT SMP [2430.654512] CPU: 2 PID: 20919 Comm: cat No contaminado 5.15.25-g512f31242bf6 #33 [2430.655008] Nombre de hardware: tonto-virt ( DT) [ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2430.656142] pc : kfree+0x78/0x348 [ 2430.656630] lr : jffs2_free_inode+0x24/0x48 [ 2430.657051]sp : ffff800009eebd10 [ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000 [ 2430.658327] x26: ffff000038f09d80 25: 0080000000000000 x24: ffff800009d38000 [ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14 [ 2430.65943 4] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 00000000000000000 [ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000 [ 2430.660637] x14: 0000000000000000 x13: 00000001000 820a1 x12: 00000000000d1b19 [2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9: ffff8000084f0d14 [2430.662025] x8: bf9a6b40 x7: ffff0000bf9a6b48 x6: 0000000003470302 [2430.662695 ] x5: ffff00002e41dcc0 x4: ffff0000bf9aa3b0 x3: 0000000003470342 [2430.663486] x2: 0000000000000000 x1: ffff8000084f0d14 x0: ffffc0000000 000 [2430.664217] Rastreo de llamadas: [2430.664528] kfree+0x78/0x348 [2430.664855] jffs2_free_inode+0x24/0x48 [2430.665233] i_callback+0x24 /0x50 [ 2430.665528] rcu_do_batch+0x1ac/0x448 [ 2430.665892] rcu_core+0x28c/0x3c8 [ 2430.666151] rcu_core_si+0x18/0x28 [ 2430.666473] x138/0x3cc [ 2430.666781] irq_exit+0xf0/0x110 [ 2430.667065] handle_domain_irq+0x6c/0x98 [ 2430.667447] gic_handle_irq+0xac/0xe8 [ 2430.667739] call_on_irq_stack+0x28/0x54 El parámetro pasado a kfree fue 5a5a5a5a, que corresponde al campo de destino de la estructura jffs_inode_info. Se encontró que todas las variables en la estructura jffs_inode_info eran 5a5a5a5a, excepto el primer miembro sem. Se sospecha que estas variables no se inicializan porque se configuraron en 5a5a5a5a durante la prueba de memoria, lo que pretende detectar memoria no inicializada. La variable sem se inicializa en la función jffs2_i_init_once, mientras que otros miembros se inicializan en la función jffs2_init_inode_info. La función jffs2_init_inode_info se llama después de iget_locked, pero en la función iget_locked, se activa el proceso destroy_inode, que libera el inodo y, en consecuencia, el miembro objetivo del inodo no se inicializa. En escenarios concurrentes de alta presión, iget_locked puede ingresar a la rama destroy_inode como descrito en el código. Dado que la funcionalidad destroy_inode de jffs2 solo libera el objetivo, el método de reparación es establecer el objetivo en NULL en jffs2_i_init_once.
  • Vulnerabilidad en kernel de Linux (CVE-2024-42117)
    Severidad: ALTA
    Fecha de publicación: 30/07/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: ASSERT cuando no se puede encontrar el índice por avión/ID de flujo [POR QUÉ] find_disp_cfg_idx_by_plane_id y find_disp_cfg_idx_by_stream_id devuelven un índice de matriz y devuelven -1 cuando no se encuentran; sin embargo, -1 no es un número de índice válido. [CÓMO] Cuando esto suceda, llame a ASSERT() y devuelva un número positivo (que es menor que el tamaño de la matriz de quienes llaman). Esto soluciona 4 problemas de OVERRUN y 2 NEGATIVE_RETURNS informados por Coverity.
  • Vulnerabilidad en kernel de Linux (CVE-2024-50220)
    Severidad: MEDIA
    Fecha de publicación: 09/11/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fork: no invocar uffd en fork si ocurre un error Serie de parches "fork: no exponer mm incompleto en fork". Durante fork podemos colocar el espacio de direcciones de memoria virtual en un estado inconsistente antes de que se complete la operación de fork. Además, podemos encontrar un error durante la operación de fork que indique que el espacio de direcciones de memoria virtual está invalidado. Como resultado, no deberíamos exponerlo de ninguna manera a maquinaria externa que pueda interactuar con mm o VMAs, maquinaria que no está diseñada para lidiar con estado incompleto. Actualizamos específicamente la lógica de fork para diferir khugepaged y ksm hasta el final de la operación y solo para ser invocados si no surgió ningún error, y no permitimos que uffd observe eventos de fork si se ha producido un error. Este parche (de 2): Actualmente en fork exponemos el espacio de direcciones virtuales de un proceso al espacio de usuario incondicionalmente si uffd está registrado en VMAs, independientemente de si surgió un error en la bifurcación. Esto se realiza en dup_userfaultfd_complete(), que se invoca de manera incondicional y realiza dos tareas: invocar controladores registrados para el evento UFFD_EVENT_FORK a través de dup_fctx() y limpiar los objetos userfaultfd_fork_ctx establecidos en dup_userfaultfd(). Esto es problemático, porque el espacio de direcciones virtuales puede no estar inicializado correctamente si surge un error. El cambio en el commit d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") hace que esto sea más pertinente, ya que podemos estar en un estado en el que las entradas en el árbol de maple aún no sean consistentes. Abordamos esto, en caso de error de fork, asegurándonos de revertir el estado que de otra manera esperaríamos limpiar a través del evento que está siendo manejado por el espacio de usuario y realizar la tarea de liberación de memoria que de otra manera realizaría dup_userfaultfd_complete(). Para ello, implementamos una nueva función, dup_userfaultfd_fail(), que realiza el mismo bucle, pero disminuyendo el recuento de referencias. Tenga en cuenta que ejecutamos mmgrab() en los mm principales y secundarios, sin embargo, userfaultfd_ctx_put() ejecutará mmdrop() una vez que el recuento de referencias baje a cero, por lo que evitaremos fugas de memoria correctamente aquí.
  • Vulnerabilidad en kernel de Linux (CVE-2024-56624)
    Severidad: MEDIA
    Fecha de publicación: 27/12/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommufd: Arreglar out_fput en iommufd_fault_alloc() Como fput() llama a la operación file->f_op->release, donde se liberan los objetos de falla y ictx, no hay necesidad de liberar estos dos después de fput() una vez más, lo que daría como resultado recuentos de referencias desequilibrados: refcount_t: el decremento llega a 0; pérdida de memoria. ADVERTENCIA: CPU: 48 PID: 2369 en lib/refcount.c:31 refcount_warn_saturate+0x60/0x230 Rastreo de llamadas: refcount_warn_saturate+0x60/0x230 (P) refcount_warn_saturate+0x60/0x230 (L) iommufd_fault_fops_release+0x9c/0xe0 [iommufd] ... VFS: Cerrar: el recuento de archivos es 0 (f_op=iommufd_fops [iommufd]) ADVERTENCIA: CPU: 48 PID: 2369 en fs/open.c:1507 filp_flush+0x3c/0xf0 Rastreo de llamadas: filp_flush+0x3c/0xf0 (P) filp_flush+0x3c/0xf0 (L) __arm64_sys_close+0x34/0x98 ... desequilibrado en el recuento de referencias de archivo ADVERTENCIA: CPU: 48 PID: 2369 en fs/file.c:74 __file_ref_put+0x100/0x138 Rastreo de llamadas: __file_ref_put+0x100/0x138 (P) __file_ref_put+0x100/0x138 (L) __fput_sync+0x4c/0xd0 Omita esas dos líneas para corregir las advertencias anteriores.
  • Vulnerabilidad en kernel de Linux (CVE-2024-56630)
    Severidad: MEDIA
    Fecha de publicación: 27/12/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: inodo libre cuando ocfs2_get_init_inode() falla syzbot informa inodos ocupados después del desmontaje, para el commit 9c89fe0af826 ("ocfs2: Error de gestión de dquot_initialize()") olvidó llamar a iput() cuando new_inode() tuvo éxito y dquot_initialize() falló.
  • Vulnerabilidad en kernel de Linux (CVE-2024-56644)
    Severidad: MEDIA
    Fecha de publicación: 27/12/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/ipv6: liberación de la excepción dst expirada almacenada en caché en el socket. Los objetos Dst se filtran en ip6_negative_advice() cuando se ejecuta esta función para una ruta IPv6 expirada ubicada en la tabla de excepciones. Hay varias condiciones que deben cumplirse para que se produzca la fuga: * se recibe un paquete ICMPv6 que indica un cambio de la MTU para la ruta, lo que da como resultado la creación de un dst de excepción * una conexión TCP que utiliza el dst de excepción para enrutar paquetes debe comenzar a agotar el tiempo de espera para que TCP comience las retransmisiones * después de que el dst de excepción caduque, el recolector de basura FIB6 no debe ejecutarse antes de que TCP ejecute ip6_negative_advice() para el dst de excepción caducado Cuando TCP ejecuta ip6_negative_advice() para un dst de excepción que ha caducado y si ningún otro socket tiene una referencia al dst de excepción, el recuento de referencias del dst de excepción es 2, que corresponde al incremento realizado por dst_init() y el incremento realizado por el socket TCP para el que se agota el tiempo de espera de la conexión. El recuento de referencias realizado por el socket nunca se libera. El recuento de referencias del dst se reduce en sk_dst_reset() pero esa reducción se contrarresta con un dst_hold() colocado intencionalmente justo antes del sk_dst_reset() en ip6_negative_advice(). Después de que ip6_negative_advice() haya terminado, no hay otro objeto vinculado al dst. El socket perdió su referencia almacenada en sk_dst_cache y el dst ya no está en la tabla de excepciones. El dst de excepción se convierte en un objeto filtrado. Como resultado de esta filtración de dst, se informa un recuento de referencias desequilibrado para el dispositivo de bucle invertido de un espacio de nombres de red que se destruye en núcleos que no contienen e5f80fcf869a ("ipv6: dar un dev IPv6 a blackhole_netdev"): unregister_netdevice: esperando a que lo se libere. Recuento de uso = 2 Corrija la filtración de dst eliminando dst_hold() en ip6_negative_advice(). El parche que introdujo dst_hold() en ip6_negative_advice() fue 92f1655aa2b22 ("net: fix __dst_negative_advice() race"). Pero 92f1655aa2b22 simplemente refactorizó el código con respecto al recuento de referencias dst, por lo que el problema estaba presente incluso antes de 92f1655aa2b22. El error se introdujo en 54c1a859efd9f ("ipv6: Don't drop cache route entry sometimes expired.") donde la ruta en caché expirada se elimina y el miembro sk_dst_cache del socket se establece en NULL al llamar a dst_negative_advice(), pero el recuento de referencias que pertenece al socket se deja desequilibrado. La versión IPv4 - ipv4_negative_advice() - no se ve afectada por este error. Cuando se agota el tiempo de conexión TCP, ipv4_negative_advice() simplemente restablece el sk_dst_cache del socket mientras disminuye el recuento de referencias del dst de excepción.
  • Vulnerabilidad en kernel de Linux (CVE-2024-56645)
    Severidad: MEDIA
    Fecha de publicación: 27/12/2024
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: j1939_session_new(): corrige el conteo de referencias de skb Dado que j1939_session_skb_queue() realiza un skb_get() adicional para cada nuevo skb, haga lo mismo para el inicial en j1939_session_new() para evitar el desbordamiento del conteo de referencias. [mkl: limpia el mensaje de confirmación]
  • Vulnerabilidad en kernel de Linux (CVE-2025-21656)
    Severidad: MEDIA
    Fecha de publicación: 21/01/2025
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (drivetemp) Se soluciona que el controlador produzca datos basura cuando se producen errores SCSI. La función scsi_execute_cmd() puede devolver códigos de error negativos (códigos de Linux) y positivos (campo de resultado scsi_cmnd). Actualmente, el controlador solo pasa los códigos de error de scsi_execute_cmd() al núcleo de hwmon, lo que es incorrecto porque hwmon solo verifica los códigos de error negativos. Esto hace que hwmon informe datos no inicializados al espacio de usuario en caso de errores SCSI (por ejemplo, si la unidad de disco se desconectó). Este parche verifica la salida de scsi_execute_cmd() y devuelve -EIO si su código de error es positivo. [groeck: Evite la declaración de variables en línea para la portabilidad]
  • Vulnerabilidad en kernel de Linux (CVE-2025-21662)
    Severidad: MEDIA
    Fecha de publicación: 21/01/2025
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Se solucionó que la variable no se completara cuando la función retorna Cuando cmd_alloc_index(), falla cmd_work_handler() debe completar ent->slotted antes de regresar antes. De lo contrario, la tarea que emitió el comando puede bloquearse: mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): no se pudo asignar la entrada del comando INFO: la tarea kworker/13:2:4055883 se bloqueó durante más de 120 segundos. No está contaminada 4.19.90-25.44.v2101.ky10.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/13:2 D 0 4055883 2 0x00000228 Workqueue: events mlx5e_tx_dim_work [mlx5_core] Call trace: __switch_to+0xe8/0x150 __schedule+0x2a8/0x9b8 schedule+0x2c/0x88 schedule_timeout+0x204/0x478 wait_for_common+0x154/0x250 wait_for_completion+0x28/0x38 cmd_exec+0x7a0/0xa00 [mlx5_core] mlx5_cmd_exec+0x54/0x80 [mlx5_core] mlx5_core_modify_cq+0x6c/0x80 [mlx5_core] mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core] mlx5e_tx_dim_work+0x54/0x68 [mlx5_core] process_one_work+0x1b0/0x448 worker_thread+0x54/0x468 kthread+0x134/0x138 ret_from_fork+0x10/0x18
  • Vulnerabilidad en kernel de Linux (CVE-2025-21664)
    Severidad: MEDIA
    Fecha de publicación: 21/01/2025
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm thin: hacer que get_first_thin use la función list first de rcu-safe La documentación en rculist.h explica la ausencia de list_empty_rcu() y advierte a los programadores que no confíen en una secuencia list_empty() -> list_first() en el código seguro de RCU. Esto se debe a que cada una de estas funciones realiza su propio READ_ONCE() del encabezado de la lista. Esto puede llevar a una situación en la que list_empty() ve una entrada de lista válida, pero el list_first() posterior ve una vista diferente del estado del encabezado de lista después de una modificación. En el caso de dm-thin, este autor tuvo un bloqueo del cuadro de producción debido a una falla de GP en la ruta process_deferred_bios. Esta función vio un encabezado de lista válido en get_first_thin() pero cuando posteriormente desreferenciaba eso y lo convertía en un thin_c, obtuvo el interior del grupo de estructuras, ya que la lista ahora estaba vacía y se refería a sí misma. El núcleo en el que esto ocurrió imprimió una advertencia sobre la saturación de un refcount_t y un error UBSAN por un acceso a cpuid fuera de los límites en el spinlock en cola, antes del fallo en sí. Cuando se examinó el kdump resultante, fue posible ver otro hilo esperando pacientemente en elsynchronous_rcu de thin_dtr. La llamada thin_dtr logró sacar el thin_c de la lista de thins activa (y hacer que sea la última entrada en la lista de active_thins) justo en el momento equivocado, lo que provocó este bloqueo. Afortunadamente, la solución aquí es sencilla. Cambie la función get_first_thin() para usar list_first_or_null_rcu() que realiza solo un único READ_ONCE() y devuelve NULL si la lista ya está vacía. Esto se ejecutó contra las suites de aprovisionamiento fino del conjunto de pruebas devicemapper para eliminar y suspender y no se observaron regresiones.
  • Vulnerabilidad en kernel de Linux (CVE-2025-21668)
    Severidad: MEDIA
    Fecha de publicación: 31/01/2025
    Fecha de última actualización: 26/09/2025
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pmdomain: imx8mp-blk-ctrl: agregar condición de interrupción de bucle faltante Actualmente, imx8mp_blk_ctrl_remove() continuará el bucle for hasta que se produzca una excepción fuera de los límites. pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : dev_pm_domain_detach+0x8/0x48 lr : imx8mp_blk_ctrl_shutdown+0x58/0x90 sp : ffffffc084f8bbf0 x29: ffffffc084f8bbf0 x28: ffffff80daf32ac0 x27: 0000000000000000 x26: ffffffc081658d78 x25: 0000000000000001 x24: ffffffc08201b028 x23: ffffff80d0db9490 x22: ffffffc082340a78 x21: 00000000000005b0 x20: ffffff80d19bc180 x19: 000000000000000a x18: ffffffffffffffff x17: ffffffc080a39e08 x16: ffffffc080a39c98 x15: 4f435f464f006c72 x14: 0000000000000004 x13: ffffff80d0172110 x12: 0000000000000000 x11: ffffff80d0537740 x10: ffffff80d05376c0 x9 : ffffffc0808ed2d8 x8 : ffffffc084f8bab0 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff80d19b9420 x4 : fffffffe03466e60 x3 : 0000000080800077 x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000 Call trace: dev_pm_domain_detach+0x8/0x48 platform_shutdown+0x2c/0x48 device_shutdown+0x158/0x268 kernel_restart_prepare+0x40/0x58 kernel_kexec+0x58/0xe8 __do_sys_reboot+0x198/0x258 __arm64_sys_reboot+0x2c/0x40 invoke_syscall+0x5c/0x138 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x38/0xc8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 Code: 8128c2d0 ffffffc0 aa1e03e9 d503201f
  • Vulnerabilidad en ZKTeco BioTime (CVE-2024-13966)
    Severidad: MEDIA
    Fecha de publicación: 27/05/2025
    Fecha de última actualización: 26/09/2025
    ZKTeco BioTime permite a atacantes no autenticados enumerar nombres de usuario e iniciar sesión como cualquier usuario con una contraseña que no sea la predeterminada "123456". Los usuarios deben cambiar sus contraseñas (ubicadas en la pestaña "Configuración de Asistencia" como "Contraseña propia").
  • Vulnerabilidad en Wikimedia Foundation Mediawiki - MintyDocs Extension (CVE-2025-53493)
    Severidad: MEDIA
    Fecha de publicación: 02/07/2025
    Fecha de última actualización: 26/09/2025
    Vulnerabilidad de neutralización incorrecta de entrada durante la generación de páginas web (XSS o 'Cross-site Scripting') en Wikimedia Foundation Mediawiki - MintyDocs Extension permite XSS almacenado. Este problema afecta a la extensión Mediawiki - MintyDocs: 1.39.X, 1.42.X, desde 1.43.X hasta 1.43.2.
  • Vulnerabilidad en Wikimedia Foundation Mediawiki - MintyDocs Extension (CVE-2025-53492)
    Severidad: BAJA
    Fecha de publicación: 02/07/2025
    Fecha de última actualización: 26/09/2025
    Vulnerabilidad de neutralización incorrecta de entrada durante la generación de páginas web (XSS o 'Cross-site Scripting') en Wikimedia Foundation Mediawiki - MintyDocs Extension permite XSS almacenado. Este problema afecta a la extensión Mediawiki - MintyDocs: 1.39.X, 1.42.X, desde 1.43.X hasta 1.43.2.
  • Vulnerabilidad en OPNsense 25.1 (CVE-2025-50989)
    Severidad: CRÍTICA
    Fecha de publicación: 27/08/2025
    Fecha de última actualización: 26/09/2025
    OPNsense 25.1 contiene una vulnerabilidad de inyección de comandos autenticados en su endpoint Bridge Interface Edit (interfaces_bridge_edit.php). El parámetro POST span se concatena en un comando a nivel de sistema sin la debida depuración ni escape, lo que permite a un administrador inyectar operadores de shell y payloads arbitrarias. Una explotación exitosa otorga a RCE los privilegios del servicio web (normalmente root), lo que podría provocar la vulneración total del sistema o un desplazamiento lateral. Esta vulnerabilidad surge de una validación de entrada inadecuada y del manejo incorrecto de los datos proporcionados por el usuario en las invocaciones de comandos del backend.