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 Yonyou (CVE-2024-24256)
  Severidad: MEDIA
  Fecha de publicación: 15/02/2024
  Fecha de última actualización: 18/09/2025
  Una vulnerabilidad de inyección SQL en la plataforma de integración de información empresarial espacio-temporal de Yonyou v.9.0 y anteriores permite a un atacante obtener información confidencial a través del parámetro gwbhAIM en saveMove.jsp en el directorio hr_position.
  
• Vulnerabilidad en VitalPBX v.3.2.4-5 (CVE-2024-24386)
  Severidad: ALTA
  Fecha de publicación: 15/02/2024
  Fecha de última actualización: 18/09/2025
  Un problema en VitalPBX v.3.2.4-5 permite a un atacante ejecutar código arbitrario a través de un payload manipulado en la carpeta /var/lib/vitalpbx/scripts.
  
• Vulnerabilidad en Amazon Fire (CVE-2024-27350)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2024
  Fecha de última actualización: 18/09/2025
  Amazon Fire OS 7 anterior a 7.6.6.9 y 8 anterior a 8.1.0.3 permite que las aplicaciones Fire TV establezcan conexiones ADB (Android Debug Bridge) locales. NOTA: algunos terceros cuestionan si esto tiene relevancia para la seguridad, porque una conexión ADB solo es posible después de que la opción Depuración ADB (no predeterminada) esté habilitada y después de que el iniciador de ese intento de conexión específico haya sido aprobado a través de un mensaje en pantalla completa.
  
• Vulnerabilidad en orjson (CVE-2024-27454)
  Severidad: ALTA
  Fecha de publicación: 26/02/2024
  Fecha de última actualización: 18/09/2025
  orjson.loads en orjson anterior a 3.9.15 no limita la recursividad para documentos JSON profundamente anidados.
  
• Vulnerabilidad en rack-cors (CVE-2024-27456)
  Severidad: CRÍTICA
  Fecha de publicación: 26/02/2024
  Fecha de última actualización: 18/09/2025
  rack-cors (también conocido como Rack CORS Middleware) 2.0.1 tiene permisos 0666 para los archivos .rb.
  
• Vulnerabilidad en Showdownjs (CVE-2024-1899)
  Severidad: MEDIA
  Fecha de publicación: 26/02/2024
  Fecha de última actualización: 18/09/2025
  Un problema en el subanalizador de anclajes de las versiones de Showdownjs <= 2.1.0 podría permitir que un atacante remoto provoque condiciones de denegación de servicio.
  
• Vulnerabilidad en Niushop B2B2C V5 (CVE-2024-25247)
  Severidad: CRÍTICA
  Fecha de publicación: 26/02/2024
  Fecha de última actualización: 18/09/2025
  Vulnerabilidad de inyección SQL en /app/api/controller/Store.php en Niushop B2B2C V5 permite a atacantes ejecutar comandos SQL arbitrarios a través de parámetros de latitud y longitud.
  
• Vulnerabilidad en PBX Innovaphone (CVE-2024-24721)
  Severidad: MEDIA
  Fecha de publicación: 27/02/2024
  Fecha de última actualización: 18/09/2025
  Se descubrió un problema en PBX Innovaphone anteriores a dispositivos 14r1. El formulario de contraseña, utilizado para autenticar, permite un ataque de fuerza bruta a través del cual un atacante puede acceder al panel de administración.
  
• Vulnerabilidad en PBX Innovaphone (CVE-2024-24720)
  Severidad: MEDIA
  Fecha de publicación: 27/02/2024
  Fecha de última actualización: 18/09/2025
  Se descubrió un problema en PBX Innovaphone anteriores a dispositivos 14r1. Proporciona diferentes respuestas a las solicitudes entrantes de una manera que revela información a un atacante.
  
• Vulnerabilidad en GL-iNet (CVE-2024-27356)
  Severidad: ALTA
  Fecha de publicación: 27/02/2024
  Fecha de última actualización: 18/09/2025
  Se descubrió un problema en ciertos dispositivos GL-iNet. Los atacantes pueden descargar archivos, como registros, mediante comandos, obteniendo potencialmente información crítica del usuario. Esto afecta a MT6000 4.5.5, XE3000 4.4.4, X3000 4.4.5, MT3000 4.5.0, MT2500 4.5.0, AXT1800 4.5.0, AX1800 4.5.0, A1300 4.5.0, S200 4.1.4-0300, X750 4.3.7, SFT1200 4.3.7, XE300 4.3.7, MT1300 4.3.10, AR750 4.3.10, AR750S 4.3.10, AR300M 4.3.10, AR300M16 4.3.10, B1300 4.3.10, MT300N-v2 4.3. 10 , X300B 3.217, S1300 3.216, SF1200 3.216, MV1000 3.216, N300 3.216, B2200 3.216 y X1200 3.203.
  
• Vulnerabilidad en Srelay (CVE-2024-25398)
  Severidad: ALTA
  Fecha de publicación: 27/02/2024
  Fecha de última actualización: 18/09/2025
  En Srelay (el proxy y retransmisión SOCKS) v.0.4.8p3, un payload de red especialmente manipulado puede desencadenar una condición de denegación de servicio e interrumpir el servicio.
  
• Vulnerabilidad en Jenkins Bitbucket Branch Source (CVE-2024-28152)
  Severidad: MEDIA
  Fecha de publicación: 06/03/2024
  Fecha de última actualización: 18/09/2025
  En el complemento Jenkins Bitbucket Branch Source 866.vdea_7dcd3008e y versiones anteriores, excepto 848.850.v6a_a_2a_234a_c81, al descubrir solicitudes de extracción de bifurcaciones, la política de confianza "Bifurcaciones en la misma cuenta" permite cambios en los archivos Jenkins de usuarios sin acceso de escritura al proyecto cuando se usa Bitbucket Server. .
  
• Vulnerabilidad en Jenkins GitBucket Plugin (CVE-2024-28157)
  Severidad: ALTA
  Fecha de publicación: 06/03/2024
  Fecha de última actualización: 18/09/2025
  Jenkins GitBucket Plugin 0.8 y versiones anteriores no desinfectan las URL de Gitbucket en las vistas de compilación, lo que genera una vulnerabilidad de Cross-Site Scripting (XSS) almacenadas que pueden explotar los atacantes capaces de configurar trabajos.
  
• Vulnerabilidad en Jenkins (CVE-2024-2215)
  Severidad: MEDIA
  Fecha de publicación: 06/03/2024
  Fecha de última actualización: 18/09/2025
  Una vulnerabilidad de falsificación de solicitud entre sitios (CSRF) en el complemento Docker-build-step de Jenkins 2.11 y versiones anteriores permite a los atacantes conectarse a una URL de socket TCP o Unix especificada por el atacante y reconfigurar el complemento utilizando los parámetros de prueba de conexión proporcionados, afectando las futuras ejecuciones de pasos de construcción.
  
• Vulnerabilidad en Jenkins (CVE-2024-2216)
  Severidad: ALTA
  Fecha de publicación: 06/03/2024
  Fecha de última actualización: 18/09/2025
  Una verificación de permiso faltante en un punto final HTTP en el complemento Docker-build-step de Jenkins 2.11 y versiones anteriores permite a los atacantes con permiso general/lectura conectarse a una URL de socket TCP o Unix especificada por el atacante y reconfigurar el complemento utilizando los parámetros de prueba de conexión proporcionados, lo que afecta las ejecuciones futuras de pasos de compilación.
  
• Vulnerabilidad en Cypress Solutions CTM-200 (CVE-2023-47415)
  Severidad: ALTA
  Fecha de publicación: 07/03/2024
  Fecha de última actualización: 18/09/2025
  Se descubrió que Cypress Solutions CTM-200 v2.7.1.5600 y versiones anteriores contenían una vulnerabilidad de inyección de comandos del sistema operativo a través del parámetro cli_text.
  
• Vulnerabilidad en WinMail (CVE-2024-25501)
  Severidad: ALTA
  Fecha de publicación: 09/03/2024
  Fecha de última actualización: 18/09/2025
  Un problema con WinMail v.7.1 y v.5.1 y anteriores permite a un atacante remoto ejecutar código arbitrario a través de un script manipulado en el parámetro de correo electrónico.
  
• Vulnerabilidad en GV-ASManager V6.0.1.0 (CVE-2022-46070)
  Severidad: ALTA
  Fecha de publicación: 11/03/2024
  Fecha de última actualización: 18/09/2025
  GV-ASManager V6.0.1.0 contiene una vulnerabilidad de inclusión de archivos locales en GeoWebServer a través de Path.
  
• Vulnerabilidad en PrestaShop (CVE-2024-28388)
  Severidad: CRÍTICA
  Fecha de publicación: 14/03/2024
  Fecha de última actualización: 18/09/2025
  Vulnerabilidad de inyección SQL en el módulo stproductcomments de SunnyToo para PrestaShop v.1.0.5 y anteriores, permite a un atacante remoto escalar privilegios y obtener información confidencial a través del método StProductCommentClass::getListcomments.
  
• Vulnerabilidad en TP-Link Omada er605 (CVE-2024-25139)
  Severidad: CRÍTICA
  Fecha de publicación: 14/03/2024
  Fecha de última actualización: 18/09/2025
  En TP-Link Omada er605 1.0.1 a (v2.6) 2.2.3, un binario cloud-brd es susceptible a un desbordamiento de almacenamiento dinámico que conduce a un desbordamiento del búfer de almacenamiento dinámico. Después de la configuración del montón, un atacante puede lograr la ejecución de código en el contexto del binario cloud-brd que se ejecuta en el nivel raíz. Esto se solucionó en ER605(UN)_v2_2.2.4 Build 020240119.
  
• Vulnerabilidad en pscartabandonmentpro v.2.0.11 (CVE-2024-28392)
  Severidad: CRÍTICA
  Fecha de publicación: 20/03/2024
  Fecha de última actualización: 18/09/2025
  Vulnerabilidad de inyección SQL en pscartabandonmentpro v.2.0.11 y anteriores permite a un atacante remoto escalar privilegios a través del método pscartabandonmentproFrontCAPUnsubscribeJobModuleFrontController::setEmailVisualized().
  
• Vulnerabilidad en Best-Kit bestkit_popup v.1.7.2 (CVE-2024-28395)
  Severidad: CRÍTICA
  Fecha de publicación: 20/03/2024
  Fecha de última actualización: 18/09/2025
  Vulnerabilidad de inyección SQL en Best-Kit bestkit_popup v.1.7.2 y anteriores permite a un atacante remoto escalar privilegios a través del componente bestkit_popup.php.
  
• Vulnerabilidad en ClickUp Desktop (CVE-2024-23755)
  Severidad: ALTA
  Fecha de publicación: 23/03/2024
  Fecha de última actualización: 18/09/2025
  ClickUp Desktop anterior a 3.3.77 en macOS y Windows permite la inyección de código debido a Electron Fuses específicos. Existe una protección inadecuada contra la inyección de código a través de configuraciones como RunAsNode.
  
• Vulnerabilidad en Home-Made.io fastmagsync (CVE-2024-28386)
  Severidad: CRÍTICA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 18/09/2025
  Un problema en Home-Made.io fastmagsync v.1.7.51 y anteriores permite a un atacante remoto ejecutar código arbitrario a través del componente getPhpBin().
  
• Vulnerabilidad en axonaut (CVE-2024-28387)
  Severidad: ALTA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 18/09/2025
  Un problema en axonaut v.3.1.23 y anteriores permite a un atacante remoto obtener información confidencial a través del componente log.txt.
  
• Vulnerabilidad en Scalapay (CVE-2024-28393)
  Severidad: CRÍTICA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 18/09/2025
  Vulnerabilidad de inyección SQL en Scalapay v.1.2.41 y anteriores permite a un atacante remoto escalar privilegios a través del método ScalapayReturnModuleFrontController::postProcess().
  
• Vulnerabilidad en CRM Twenty (CVE-2024-28434)
  Severidad: ALTA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 18/09/2025
  La plataforma CRM Twenty es vulnerable a cross site scripting almacenado mediante la carga de archivos en la versión 0.3.0. Un archivo svg manipulado puede desencadenar la ejecución del código javascript.
  
• Vulnerabilidad en CRM Twenty (CVE-2024-28435)
  Severidad: MEDIA
  Fecha de publicación: 25/03/2024
  Fecha de última actualización: 18/09/2025
  La plataforma CRM Twenty versión 0.3.0 es vulnerable a SSRF mediante la carga de archivos.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48640)
  Severidad: MEDIA
  Fecha de publicación: 28/04/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: bonding: corrige la deref NULL en bond_rr_gen_slave_id Se corrige una desreferencia NULL del miembro struct bonding.rr_tx_counter porque si un enlace se crea inicialmente con un modo inicial != cero (Round Robin) la memoria requerido para el contador nunca se crea y cuando se cambia el modo nunca se intenta verificar que la memoria esté asignada al cambiar de modo. Esto provoca los siguientes errores en una máquina aarch64: [334.686773] No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff2c91ac905000 [334.694703] Información de cancelación de memoria: [334.697486] ESR = 0x0000000096000004 [334.701234] EC = 0x25: DABT (EL actual), IL = 32 bits [ 334.706536] SET = 0, FnV = 0 [ 334.709579] EA = 0, S1PTW = 0 [ 334.712719] FSC = 0x04: error de traducción de nivel 0 [ 334.717586] Información de cancelación de datos: [ 334.720454] ISV = 0, ISS = 0x00000004 [334.724288] CM = 0, WnR = 0 [334.727244] tabla de intercambio: páginas 4k, VA de 48 bits, pgdp=000008044d662000 [334.733944] [ffff2c91ac905000] 0000000000000, p4d=00000000000000000 [334.740734] Error interno: Ups: 96000004 [#1] SMP [334.745602] Módulos vinculados en: unión tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon [334.772217] CPU: 7 PID: 2214 Comm: ping No contaminado 6.0.0-rc4-00133-g64ae13ed4784 #4 [334.779950] Nombre de hardware: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01 /2021 [ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [unión] [ 334.801691] lr : _slave_get+0x38/0xdc [ vinculación] [ 334.807962] sp : ffff8000221733e0 [ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c [ 334.818392] x26: 00000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000 [ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0 [ 334.832646] x 20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014 [ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62 [ 334.846899] 14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000 [ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec [ 3 34.861153] x8: ffff07ff9f6e5a28 x7: 0000000000000000 x6: 000000007c2b3742 [334.868279] x5: ffff2c91ac905000 x4: ffff2c91ac905000 x3: ffff07ff9f554400 [334.875406] x2: 1ac905000 x1: 0000000000000001 x0: ffff07ff981029c0 [334.882532] Rastreo de llamadas: [334.884967] bond_rr_gen_slave_id+0x40/0x124 [vinculación] [334.890109] _obtener+ 0x38/0xdc [vínculo] [ 334.896033] __bond_start_xmit+0x128/0x3a0 [vínculo] [ 334.901001] bond_start_xmit+0x54/0xb0 [vínculo] [ 334.905622] dev_hard_start_xmit+0xb4/0x220 [ 334 .909798] __dev_queue_xmit+0x1a0/0x720 [ 334.913799] arp_xmit+0x3c /0xbc [ 334.916932] arp_send_dst+0x98/0xd0 [ 334.920410] arp_solicit+0xe8/0x230 [ 334.923888] neigh_probe+0x60/0xb0 [ 334.927279] 0x470 [334.931453] neigh_resolve_output+0x70/0x90 [334.935626] ip_finish_output2+0x158/0x514 [ 334.939714] __ip_finish_output+0xac/0x1a4 [ 334.943800] ip_finish_output+0x40/0xfc [ 334.947626] ip_output+0xf8/0x1a4 [ 334.950931] 0 [ 334.954410] ip_push_pending_frames+0x3c/0x60 [ 334.958758] raw_sendmsg+0x458/0x6d0 [ 334.962325 ] inet_sendmsg+0x50/0x80 [ 334.965805] sock_sendmsg+0x60/0x6c [ 334.969286] __sys_sendto+0xc8/0x134 [ 334.972853] __arm64_sys_sendto+0x34/0x4c ncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48643)
  Severidad: MEDIA
  Fecha de publicación: 28/04/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: corrige el desbordamiento de nft_counters_enabled en nf_tables_addchain() syzbot informa el desbordamiento del contador nft_counters_enabled en nf_tables_addchain() [1], para el commit 43eb8949cfdffa76 ("netfilter: nf_tables: no salir estadísticas de cadena habilitadas en caso de error") pasó por alto que nf_tables_chain_destroy() después de nft_basechain_init() en la ruta de error de nf_tables_addchain() disminuye el contador porque nft_basechain_init() hace que nft_is_base_chain() devuelva verdadero al configurar el indicador NFT_CHAIN_BASE. Incrementa el contador inmediatamente después de regresar de nft_basechain_init().
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48644)
  Severidad: MEDIA
  Fecha de publicación: 28/04/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: taprio: evita deshabilitar la descarga cuando nunca estuvo habilitada. En una decisión de diseño de API increíblemente extraña, se llama a qdisc->destroy() incluso si qdisc->init() nunca tuvo éxito, no exclusivamente desde el commit 87b60cfacf9f ("net_sched: corregir recuperación de error en la creación de qdisc"), sino aparentemente también antes (en el caso de qdisc_create_dflt()). La qdisc taprio no reconoce completamente esto cuando intenta una descarga completa, porque comienza con q->flags = TAPRIO_FLAGS_INVALID en taprio_init(), luego reemplaza q->flags con TCA_TAPRIO_ATTR_FLAGS analizado desde netlink (en taprio_change(), cola llamada de taprio_init()). Pero en taprio_destroy(), llamamos a taprio_disable_offload(), y esto determina qué hacer en función de FULL_OFFLOAD_IS_ENABLED(q->flags). Pero al observar la implementación de FULL_OFFLOAD_IS_ENABLED() (una verificación bit a bit del bit 1 en q->flags), no es válido llamar a esta macro en q->flags cuando contiene TAPRIO_FLAGS_INVALID, porque está configurado en U32_MAX y, por lo tanto, FULL_OFFLOAD_IS_ENABLED () devolverá verdadero en un conjunto de indicadores no válido. Como resultado, es posible bloquear el kernel si el espacio del usuario fuerza un error entre configurar q->flags = TAPRIO_FLAGS_INVALID y la llamada de taprio_enable_offload(). Esto se debe a que los conductores no esperan que se deshabilite la descarga cuando nunca estuvo habilitada. El error que forzamos aquí es adjuntar taprio como una qdisc no raíz, sino como hija de una qdisc raíz mqprio: $ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ colas 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc qdisc reemplazar dev swp0 padre 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ colas 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 tiempo base 0 \ entrada programada S 0x7f 990000 entrada programada S 0x80 100000 \ banderas 0x0 clockid CLOCK_TAI No se puede para manejar la solicitud de paginación del kernel en la dirección virtual ffffffffffffffff8 [ffffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000 Error interno: Vaya: 96000004 [#1] Seguimiento de llamada SMP PREEMPT: taprio_dump+0x27c/0x310 vsc9959_port _setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc +0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 x5c/0x130 rtnetlink_rcv+0x1c/0x2c Solucione este problema manteniendo un registro de operaciones que hicimos, y deshacer la descarga solo si realmente lo hicimos. Agregué "bool descargado" dentro de un hueco de 4 bytes entre "int clockid" y "atomic64_t picos_per_byte". Ahora la primera línea de caché se ve así: $ pahole -C taprio_sched net/sched/sch_taprio.o struct taprio_sched { struct Qdisc * * qdiscs; /* 0 8 */ struct Qdisc * raíz; /* 8 8 */ u32 banderas; /* 16 4 */ enum tk_offsets tk_offset; /* 20 4 */ int relojid; /* 24 4 */ bool descargado; /* 28 1 */ /* XXX agujero de 3 bytes, intenta empaquetar */ atomic64_t picos_per_byte; /* 32 0 */ /* XXX agujero de 8 bytes, intenta empaquetar */ spinlock_t current_entry_lock; /* 40 0 */ /* XXX agujero de 8 bytes, intenta empaquetar */ struct sched_entry * current_entry; /* 48 8 */ struct sched_gate_list * oper_sched; /* 56 8 */ /* --- límite de línea de caché 1 (64 bytes) --- */
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48645)
  Severidad: MEDIA
  Fecha de publicación: 28/04/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: enetc: denegar la descarga de funciones TSN basadas en tc en interfaces VF Las funciones TSN en ENETC (taprio, cbs, gate, policial) se configuran mediante una combinación de comandos BD ring mensajes y registros de puertos: enetc_port_rd(), enetc_port_wr(). Los registros de puerto son una región del mapa de memoria ENETC a la que solo se puede acceder desde la función física PCIe. No son accesibles desde las Funciones Virtuales. Además, al intentar acceder a estos registros se bloquea el kernel: $ echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001 fsl_enetc_vf 0000:00:01.0: Agregar al grupo iommu 15 fsl_enetc_vf 0000:00:01.0: habilitar el dispositivo (0000 -> 0002) fsl_enetc_vf 0000:00:01.0 eno0vf0: renombrado de eth0 $ tc qdisc reemplazar dev eno0vf0 root taprio num_tc 8 mapa 0 1 2 3 4 5 6 7 \ colas 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 tiempo base 0 \ entrada programada S 0x7f 900000 entrada programada S 0x80 100000 banderas 0x2 No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff800009551a08 Error interno: Ups: 96000007 [#1] PC SMP PREEMPT: enetc_setup_tc_taprio+0x170/0x47c lr: enetc_setup_tc_taprio+0x16c/0x47c Rastreo de llamadas: enetc_setup_tc_taprio +0x170/0x47c enetc_setup_tc+0x38/0x2dc taprio_change+0x43c/0x970 taprio_init+0x188/0x1e0 qdisc_create+0x114/0x470 tc_modify_qdisc+0x1fc/0x6c0 rtnetlink_rcv_msg+0x12c/0x390 Divida enetc_setup_tc() en funciones separadas para los controladores PF y VF. También elimine enetc_qos.o para que no se incluya en enetc-vf.ko, ya que no sirve para nada allí.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48652)
  Severidad: MEDIA
  Fecha de publicación: 28/04/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: se corrige el fallo manteniendo cfg antiguo cuando se actualizan TC más que colas. Hay problemas si se asignan colas con menos clases de tráfico. el commit a632b2a4c920 ("ice: ethtool: Prohibir configuración de canal incorrecta para DCB") ya no permite configurar menos colas que los TC. Otro caso es si primero configuramos menos colas y luego actualizamos más configuraciones de TC debido a LLDP, ice_vsi_cfg_tc() fallará pero dejará num_txq/rxq y tc_cfg sucios en vsi, lo que provocará un acceso al puntero no válido. [ 95.968089] ice 0000:3b:00.1: Más TC definidos que colas/anillos asignados. [ 95.968092] ice 0000:3b:00.1: ¡Intentando utilizar más colas de Rx (8) de las asignadas (1)! [ 95.968093] ice 0000:3b:00.1: Error al configurar TC para índice VSI: 0 [ 95.969621] falla de protección general: 0000 [#1] SMP NOPTI [ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: cargado Contaminado: GUWO --------- -t - 4.18.0 #1 [ 95.969867] Nombre de hardware: OEM/BC11SPSCB10, BIOS 8.23 30/12/2021 [ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60 [ 95.970052] Código: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 0 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c [ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206 [ 95.970425] RAX: muerto0000000 00200 RBX: ffffea003c425b00 RCX: 00000000006080c0 [ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: muerto000000000200 [ 95.970648] RBP: muerto000000000200 R08: 00000000000463c0 R09: ffff888ffa900000 [ 95.970760] R10: 0000000000000000 R11: 00000000000002 R12: ffff888ff6b40100 [ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460 [ 95.970981] FS: 1b7d24700(0000) GS: ffff88903ee80000(0000) knlGS:00000000000000000 [ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.971197] CR2: 10 CR3: 0000000f2c1de002 CR4: 00000000007606e0 [ 95.971309] DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 [ 95.971419 ] DR3 : 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 95.971530] PKRU: 55555554 [ 95.971573] Seguimiento de llamadas: [ 95.971622] x110 [hielo] [ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [hielo] [ 95.971774] ice_vsi_open+0x25/0x120 [hielo] [ 95.971843] ice_open_internal+0xb8/0x1f0 [hielo] [ 95.971919] ice_ena_vsi+0x4f/0xd0 [hielo] [ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [hielo] [ 95.972082] f_dcb_cfg+0x29a/0x380 [hielo ] [ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [hielo] [ 95.972220] dcbnl_ieee_set+0x89/0x230 [ 95.972279] ? dcbnl_ieee_del+0x150/0x150 [ 95.972341] dcb_doit+0x124/0x1b0 [ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0 [ 95.972457] ? dcb_doit+0x14d/0x1b0 [95.972510]? __kmalloc_node_track_caller+0x1d3/0x280 [95.972591]? rtnl_calcit.isra.31+0x100/0x100 [ 95.972661] netlink_rcv_skb+0xcf/0xf0 [ 95.972720] netlink_unicast+0x16d/0x220 [ 95.972781] netlink_sendmsg+0x2ba/0x3a0 [ 95.975 891] sock_sendmsg+0x4c/0x50 [ 95.979032] ___sys_sendmsg+0x2e4/0x300 [ 95.982147] ? kmem_cache_alloc+0x13e/0x190 [95.985242]? __wake_up_common_lock+0x79/0x90 [95.988338]? __check_object_size+0xac/0x1b0 [ 95.991440] ? _copiar_al_usuario+0x22/0x30 [ 95.994539] ? move_addr_to_user+0xbb/0xd0 [95.997619]? __sys_sendmsg+0x53/0x80 [ 96.000664] __sys_sendmsg+0x53/0x80 [ 96.003747] do_syscall_64+0x5b/0x1d0 [ 96.006862] Entry_SYSCALL_64_after_hwframe+0x65/0xca Solo actualización num_txq/rxq cuando se pasa la verificación y restaura tc_cfg si falla el mapa de cola de configuración.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48653)
  Severidad: MEDIA
  Fecha de publicación: 28/04/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ice: no desconectar dos veces el auxiliar en el reinicio iniciado por el par. En la devolución de llamada de IDC a la que se accede cuando los controladores auxiliares solicitan un reinicio, se llama a la función para desconectar los dispositivos auxiliares. Esta función también se llama en la función ice_prepare_for_reset. Esta doble llamada está provocando un ERROR de "programación atómica". [662.676430] ice 0000:4c:00.0 rocep76s0: cqp opcode = 0x1 maj_err_code = 0xffff min_err_code = 0x8003 [662.676609] ice 0000:4c:00.0 rocep76s0: [Modificar error de comando QP][op_code=8] =-29 esperando=1 complete_err=1 maj=0xffff min=0x8003 [662.815006] ice 0000:4c:00.0 rocep76s0: Notificación de evento ICE OICR: oicr = 0x10000003 [662.815014] ice 0000:4c:00.0 rocep76s0: Error PE crítico, GLPE_CRITERR= 0x00011424 [662.815017] hielo 0000:4c:00.0 rocep76s0: Solicitando un reinicio [662.815475] ERROR: programación mientras atómico: swapper/37/0/0x00010002 [662.815475] ERROR: programación mientras atómico: swapper/37/0/0x00010002 [ 662.815477] Módulos vinculados en: rpcsec_gss_krb5 auténtico x86_pkg_temp_thermal intel_powerclamp coretemp target_core_mod snd_hda_intel ib_iser snd_intel_dspcfg libiscsi snd_intel_sdw_acpi scsi_transport_iscsi kvm_intel iTCO_wdt rdma_cm snd_hda_codec kvm iw_cm ipmi_ssif iTCO_vendor_support s nd_hda_core irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hwdep snd_seq snd_seq_device rapl snd_pcm snd_timer isst_if_mbox_pci pcspkr isst_if_mmio irdma intel_uncore idxd acpi_ipmi joydev isst_if_common snd mei_me idxd_bus ipmi_si soundcore i2c_i801 mei i2c_smbus i2c_ismt ipmi_msghandler acpi_power_meter acpi_pad rv(OE) ib_uverbs ib_cm ib_core xfs libcrc32c ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helpe r ttm [ 662.815546 ] nvme nvme_core ice drm crc32c_intel i40e t10_pi wmi pinctrl_emmitsburg dm_mirror dm_region_hash dm_log dm_mod fuse [ 662.815557] Preferencia deshabilitada en: [ 662.815558] [<0000000000000000>] 0x0 [ 6 62.815563] CPU: 37 PID: 0 Comunicaciones: intercambiador/37 Kdump: cargado Contaminado: GS OE 5.17.1 #2 [ 662.815566] Nombre del hardware: Intel Corporation D50DNP/D50DNP, BIOS SE5C6301.86B.6624.D18.2111021741 02/11/2021 [ 662.815568] Seguimiento de llamadas: [ 662.815572] [ 662 .815574] dump_stack_lvl +0x33/0x42 [ 662.815581] __schedule_bug.cold.147+0x7d/0x8a [ 662.815588] __schedule+0x798/0x990 [ 662.815595] horario+0x44/0xc0 [ 662.815597] +0x14/0x20 [ 662.815600] __mutex_lock.isra.11+0x46c /0x490 [662.815603] ? __ibdev_printk+0x76/0xc0 [ib_core] [ 662.815633] dispositivo_del+0x37/0x3d0 [ 662.815639] ice_unplug_aux_dev+0x1a/0x40 [ice] [ 662.815674] ice_schedule_reset+0x3c/0xd0 [ice] [ 2.815693] irdma_iidc_event_handler.cold.7+0xb6/0xd3 [irdma] [662.815712] ? bitmap_find_next_zero_area_off+0x45/0xa0 [ 662.815719] ice_send_event_to_aux+0x54/0x70 [ice] [ 662.815741] ice_misc_intr+0x21d/0x2d0 [ice] [ 662.815756] pu+0x4c/0x180 [ 662.815762] handle_irq_event_percpu+0xf/0x40 [ 662.815764] handle_irq_event+0x34/ 0x60 [ 662.815766] handle_edge_irq+0x9a/0x1c0 [ 662.815770] __common_interrupt+0x62/0x100 [ 662.815774] common_interrupt+0xb4/0xd0 [ 662.815779] [ 662.81578 0] [ 662.815780] asm_common_interrupt+0x1e/0x40 [ 662.815785] RIP : 0010:cpuidle_enter_state+0xd6/0x380 [ 662.815789] Código: 49 89 c4 0f 1f 44 00 00 31 ff e8 65 d7 95 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 64 02 00 31 ff e8 ae c5 9c ff fb 45 85 f6 <0f> 88 12 01 00 00 49 63 d6 4c 2b 24 24 48 8d 04 52 48 8d 04 82 49 [ 662.815791] RSP: 0018:ff2c2c4f18edbe80 EFLAGS: 0202 [662.815793] RAX: ff280805df140000 RBX: 0000000000000002 RCX : 000000000000001f [ 662.815795] RDX: 0000009a52da2d08 R ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48665)
  Severidad: MEDIA
  Fecha de publicación: 28/04/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exfat: corrige el desbordamiento de una partición de gran capacidad. Al usar el tipo int para el índice del sector, habrá un desbordamiento en una partición de gran capacidad. Por ejemplo, si el almacenamiento con un tamaño de sector de 512 bytes y una capacidad de partición es superior a 2 TB, se producirá un desbordamiento.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48667)
  Severidad: BAJA
  Fecha de publicación: 28/04/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb3: corrige la corrupción de datos temporales en el rango de inserción. El rango de inserción no descarta la región en caché afectada, por lo que puede correr el riesgo de dañar temporalmente los datos del archivo. También incluye una limpieza menor (evitando volver a leer el tamaño del inodo repetidamente innecesariamente) para hacerlo más claro.
  
• Vulnerabilidad en kernel de Linux (CVE-2022-48668)
  Severidad: BAJA
  Fecha de publicación: 28/04/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb3: corrige la corrupción temporal de datos en el rango de contracción el rango de contracción no descarta la región en caché afectada, por lo que puede correr el riesgo de corromper temporalmente los datos del archivo. Esto corrige xfstest generic/031. También decidí fusionar una limpieza menor en el mismo parche (evitando volver a leer el tamaño del inodo repetidamente innecesariamente) para que quede más claro.
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52647)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: nxp: imx8-isi: compruebe si el crossbar pad no es NULL antes del acceso. Al traducir el código fuente a las secuencias receptoras en el subdev de la barra transversal, el controlador intenta localizar el subdev remoto conectado a la plataforma del fregadero. El pad remoto puede ser NULL, si el espacio de usuario intenta habilitar una secuencia que termina en un receptor de barra transversal no conectado. Cuando eso ocurre, el controlador elimina la referencia al pad NULL, lo que provoca un bloqueo. Evite el bloqueo verificando si el pad es NULL antes de usarlo y devuelva un error si lo es.
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52648)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/vmwgfx: desasignar la superficie antes de restablecerla en un estado plano. Cambiar a un nuevo estado plano requiere eliminar la referencia de todas las superficies retenidas. En el trabajo requerido para los cursores de mob, las superficies mapeadas comenzaron a almacenarse en caché, pero la variable que indica si la superficie está actualmente mapeada no se restableció. Esto provoca fallos ya que el estado duplicado, incorrectamente, indica que esa superficie está mapeada incluso cuando no hay ninguna superficie presente. Esto se debe a que después de eliminar la referencia a la superficie, es perfectamente posible que el avión esté respaldado por un bo en lugar de una superficie. Restablezca el indicador de superficie asignada al eliminar la referencia a la superficie del estado del plano para corregir las desreferencias nulas en la limpieza. Soluciona fallas en KDE KWin 6.0 en Wayland: Ups: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2 Nombre del hardware: VMware, Inc. VMware Virtual Platform/ Plataforma de referencia de escritorio 440BX, BIOS 6.00 12/11/2020 RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Código: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc 48 8b b 3a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246 RAX: 0000000000000000 : ffff969d84cdcb00 RCX: 00000000000000027 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600 RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920 R10: 0000000000000003 R11: 9e7feb3b10 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00 FS: 00007f1e8f1b4180(0000) e75f00000(0000) knlGS:0000000000000000 CS: 0010 DS : 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0 Seguimiento de llamadas: ? __morir+0x23/0x70 ? page_fault_oops+0x171/0x4e0? exc_page_fault+0x7f/0x180? asm_exc_page_fault+0x26/0x30? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] drm_atomic_helper_cleanup_planes+0x9b/0xc0 commit_tail+0xd1/0x130 drm_atomic_helper_commit+0x11a/0x140 drm_atomic_commit+0x97/0xd0 ? __pfx___drm_printfn_info+0x10/0x10 drm_atomic_helper_update_plane+0xf5/0x160 drm_mode_cursor_universal+0x10e/0x270 drm_mode_cursor_common+0x102/0x230 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 drm_ioctl_kernel+0xb2/0x110 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10 ? __pfx_drm_ioctl+0x10/0x10 vmw_generic_ioctl+0xa4/0x110 [vmwgfx] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x61/0xe0 ? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40? do_syscall_64+0x70/0xe0? __x64_sys_ioctl+0xaf/0xd0 ? syscall_exit_to_user_mode+0x2b/0x40? do_syscall_64+0x70/0xe0? exc_page_fault+0x7f/0x180 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f1e93f279ed Código: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f> RSP: 002b:00007ffca0faf600 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 55db876ed2c0 RCX: 00007f1e93f279ed RDX: 00007ffca0faf6c0 RSI: 00000000c02464bb RDI: 0000000000000015 RBP: 00007ffca0faf650 R08: 000055db87184010 R09: 0000000000000007 R10: 000055db886471a0 R11: 0000000000000246 R12: 00007ffca0faf6c0 R13: 0000c02464bb R14: 0000000000000015 R15: 00007ffca0faf790 Módulos vinculados en: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 fib_ipv6 nft_fib nft_reject_ine> CR2: 0000000000000028 ---[ seguimiento final 0000000000000000 ]--- RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Código: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc 48 8b b3 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26936)
  Severidad: ALTA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: validar el tamaño del búfer de solicitud en smb2_allocate_rsp_buf() El búfer de respuesta debe asignarse en smb2_allocate_rsp_buf antes de validar la solicitud. Pero los campos en el payload y el encabezado smb2 se usan en smb2_allocate_rsp_buf(). Este parche agrega una validación simple del tamaño del búfer para evitar posibles límites en el búfer de solicitud.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26938)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode() Si no tenemos VBT, o el VBT no declaró el codificador en cuestión, no tendremos los 'devdata' para el codificador. En lugar de huir, simplemente sal de la cárcel antes de tiempo. No podremos saber si el puerto es DP++ o no, pero que así sea. (cereza escogida del compromiso 26410896206342c8a80d2b027923e9ee7d33b733)
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26946)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kprobes/x86: use copy_from_kernel_nofault() para leer desde una dirección no segura Lea desde una dirección no segura con copy_from_kernel_nofault() en arch_adjust_kprobe_addr() porque esta función se usa antes de verificar que la dirección esté en texto O no. El bot Syzcaller encontró un error e informó el caso si el usuario especifica un área de datos inaccesible, arch_adjust_kprobe_addr() provocará un pánico en el kernel. [ mingo: Aclaró el comentario. ]
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26947)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ARM: 9359/1: descarga: verifique si la publicación está reservada para direcciones sin asignación. Desde el commit a4d5613c4dc6 ("arm: extienda pfn_valid para tener en cuenta la alineación del mapa de memoria liberada") cambia la semántica de pfn_valid() para verificar la presencia del mapa de memoria para un PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout: node 0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node 0: [mem 0x00000000d0000000-0x00000000da1fffff] el diseño de uio es? 0xc0900000, 0x100000 el seguimiento del fallo es como: No se puede manejar la solicitud de paginación del kernel en la dirección virtual bff00000 [...] CPU: 1 PID: 465 Comm: startapp.bin Contaminado: GO 5.10.0 #1 Nombre del hardware: La PC del sistema basado en DT genérico está en b15_flush_kern_dcache_area+0x24/0x3c LR está en __sync_icache_dcache+0x6c/0x98 [...] (b15_flush_kern_dcache_area) de (__sync_icache_dcache+0x6c/0x98) (__sync_icache_dcache) de (set_pte_at+0x2 8/0x54) (set_pte_at) desde (remap_pfn_range+0x1a0/0x274) (remap_pfn_range) desde (uio_mmap+0x184/0x1b8 [uio]) (uio_mmap [uio]) desde (__mmap_region+0x264/0x5f4) (__mmap_region) desde (__do_mmap_mm+0x3ec/0x440) milímetros) de (do_mmap+0x50/0x58) (do_mmap) de (vm_mmap_pgoff+0xfc/0x188) (vm_mmap_pgoff) de (ksys_mmap_pgoff+0xac/0xc4) (ksys_mmap_pgoff) de (ret_fast_syscall+0x0/0x5c) Código: e0801001 423001 e1c00003 f57ff04f (ee070f3e) ---[ end trace 09cf0734c3805d52 ]--- Pánico del kernel - no se sincroniza: excepción fatal. Así que verifique si PG_reserved estaba configurado para resolver este problema. [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26948)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: agregue una verificación dc_state NULL en dc_state_release [Cómo] Verifique si el estado es NULL antes de liberarlo.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26953)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: esp: corrige el mal manejo de las páginas desde page_pool Cuando el skb se reorganiza durante esp_output (!esp->inline), se supone que las páginas provenientes de los fragmentos del skb original son devuelto al sistema a través de put_page. Pero si las páginas del fragmento skb se originan en un page_pool, llamar a put_page en ellas desencadenará una fuga de page_pool que eventualmente resultará en un bloqueo. Esta fuga se puede observar fácilmente cuando se usa CONFIG_DEBUG_VM y se realiza el reenvío ipsec + gre (no descargado): ERROR: Estado de página incorrecto en el proceso ksoftirqd/16 pfn:1451b6 página:00000000de2b8d32 refcount:0 mapcount:0 mapeo:0000000000000000 índice:0x1451b6000 pfn: 0x1451b6 banderas: 0x200000000000000(nodo=0|zona=2) tipo de página: 0xffffffff() sin formato: 0200000000000000 muerto000000000040 ffff88810d23c000 0000000000000000 sin formato: 0001451b6000 0000000000000001 00000000ffffffff 0000000000000000 página volcada porque: fuga de page_pool Módulos vinculados en: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [última descarga: mlx5_core] CPU: 16 PID: 96 Comm: ksoftirqd/16 No contaminado 6 .8.0-rc4+ #22 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x36/0x50 bad_page+0x70/0xf0 free_unref_page_prepare+0x27a/0x460 free_unref_page+0x38/0x120 esp_ssg_unref.isra.0+0x15f/0x200 esp_output_tail+0x66d/0x780 esp_xmit+0x2c5/0x360 validar_xmit_xfrm+0x313/0x370 ? validar_xmit_skb+0x1d/0x330 validar_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x23e/0x350 __dev_queue_xmit+0x337/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x25e/0x580 iptunnel_xmit+0x19b/0x240 ip_tunnel_xmit+0x5fb/0xb60 ipgre_xmit+0x14d/0x280 [ip_gre] dev_hard_start_xmit+0xc3/0x1c0 __dev_queue_xmit+0x208/0xba0? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x1ca/0x580 ip_sublist_rcv_finish+0x32/0x40 ip_sublist_rcv+0x1b2/0x1f0 ? ip_rcv_finish_core.constprop.0+0x460/0x460 ip_list_rcv+0x103/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x1b3/0x2c0 napi_gro_receive+0xc8/0x200 encuesta+0x52/0x90 __napi_poll+0x25/0x1a0 net_rx_action+0x28e/0x300 __do_softirq+0xc3/0x276 ? sort_range+0x20/0x20 run_ksoftirqd+0x1e/0x30 smpboot_thread_fn+0xa6/0x130 kthread+0xcd/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x31/0x50 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 La solución sugerida es introducir un nuevo contenedor (skb_page_unref) que cubra también el recuento de páginas para las páginas page_pool.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26959)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: btnxpuart: Reparar btnxpuart_close Reparar la programación mientras el ERROR atómico en btnxpuart_close(), purgar adecuadamente la cola de transmisión y liberar el skb de recepción. [10.973809] ERROR: programación mientras es atómico: kworker/u9:0/80/0x00000002... [10.980740] CPU: 3 PID: 80 Comm: kworker/u9:0 No contaminado 6.8.0-rc7-0.0.0-devel -00005-g61fdfceacf09 #1 [10.980751] Nombre de hardware: Toradex Verdin AM62 WB en Dahlia Board (DT) [10.980760] Cola de trabajo: hci0 hci_power_off [bluetooth] [10.981169] Seguimiento de llamadas: ... [10.981363] 8/0x78 [ 10.981373] uart_dtr_rts+0x104/0x114 [ 10.981381] tty_port_shutdown+0xd4/0xdc [ 10.981396] tty_port_close+0x40/0xbc [ 10.981407] uart_close+0x34/0x9c [ 10.9814 14] ttyport_close+0x50/0x94 [ 10.981430] serdev_device_close+0x40/0x50 [ 10.981442] btnxpuart_close+0x24/0x98 [btnxpuart] [ 10.981469] hci_dev_close_sync+0x2d8/0x718 [bluetooth] [ 10.981728] hci_dev_do_close+0x2c/0x70 [bluetooth] [ 10.981862] x64 [bluetooth]
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26963)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3-am62: corrige el comportamiento de descarga/recarga del módulo. Como el PM en tiempo de ejecución está habilitado, el tiempo de ejecución del módulo se puede suspender cuando se llama a .remove(). Realice pm_runtime_get_sync() para asegurarse de que el módulo esté activo antes de realizar cualquier operación de registro. Hacer pm_runtime_put_sync() debería deshabilitar refclk, por lo que no es necesario deshabilitarlo nuevamente. Corrige la siguiente advertencia al eliminar el módulo. [39.705310] ------------[ cortar aquí ]------------ [ 39.710004] clk:162:3 ya deshabilitado [ 39.713941] ADVERTENCIA: CPU: 0 PID : 921 en drivers/clk/clk.c:1090 clk_core_disable+0xb0/0xb8 Llamamos a of_platform_populate() en .probe(), así que llame a la función de limpieza of_platform_depopulate() en .remove(). Deshágase del ahora innecesario dwc3_ti_remove_core(). Sin esto, la recarga del módulo no funciona correctamente.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26977)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: pci_iounmap(): corrige la fuga de mapeo MMIO El #ifdef ARCH_HAS_GENERIC_IOPORT_MAP accidentalmente también protege iounmap(), lo que significa que se filtraron los mapeos MMIO. Mueva la guardia para que llamemos a iounmap() para asignaciones MMIO.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26985)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/xe: corrija la fuga de bo en intel_fb_bo_framebuffer_init. Agregue un bo sin referencia en la ruta del error, para evitar que se filtre una referencia de bo. Devuelve 0 en caso de éxito para aclarar la ruta del éxito. (cereza escogida del compromiso a2f3d731be3893e730417ae3190760fcaffdf549)
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26990)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/mmu: Proteger contra escritura los SPTE L2 en la MMU TDP al borrar el estado sucio. Verifique kvm_mmu_page_ad_need_write_protect() cuando decida si desea proteger contra escritura o borrar los bits D en los SPTE de la MMU TDP. , de modo que la MMU TDP tenga en cuenta cualquier motivo específico de la función para deshabilitar el registro sucio de bits D. Específicamente, los SPTE de TDP MMU deben estar protegidos contra escritura cuando la TDP MMU se utiliza para ejecutar un L2 (es decir, L1 tiene EPT deshabilitado) y PML está habilitado. KVM siempre desactiva PML cuando se ejecuta L2, incluso cuando los GPA L1 y L2 están en algún dominio, por lo que si no se protegen contra escritura los SPTE TDP MMU, las escrituras realizadas por L2 no se reflejarán en el registro sucio. [sean: masajear el registro corto y el registro de cambios, modificar el formato de operación ternario]
  
• Vulnerabilidad en kernel de Linux (CVE-2024-26992)
  Severidad: BAJA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/pmu: deshabilitar el soporte para PEBS adaptativos. Eliminar el soporte para virtualizar PEBS adaptativos, ya que la implementación de KVM tiene una arquitectura rota sin un camino obvio/fácil a seguir, y porque exponer PEBS adaptativos puede filtrar los LBR del host al huésped, es decir, puede filtrar las direcciones del kernel del host al huésped. El error número 1 es que KVM no tiene en cuenta los 32 bits superiores de IA32_FIXED_CTR_CTRL cuando (re)programa contadores fijos, por ejemplo, fix_ctrl_field() elimina los bits superiores, reprogram_fixed_counters() almacena variables locales como u8 y también trunca los bits superiores, etc. El error número 2 es que, debido a que KVM _siempre_ establece precision_ip en un valor distinto de cero para eventos PEBS, perf _siempre_ generará un registro adaptativo, incluso si el invitado solicitó un registro básico. Tenga en cuenta que KVM también habilitará PEBS adaptativo en *contador* individual, incluso si PEBS adaptativo no está expuesto al invitado, pero esto es benigno ya que se garantiza que MSR_PEBS_DATA_CFG será cero, es decir, el invitado solo verá registros básicos. El error número 3 está en rendimiento. intel_pmu_disable_fixed() tampoco borra los bits superiores, es decir, deja ICL_FIXED_0_ADAPTIVE configurado, e intel_pmu_enable_fixed() efectivamente tampoco borra ICL_FIXED_0_ADAPTIVE. Es decir, perf _siempre_ habilita contadores ADAPTIVOS, independientemente de lo que solicite KVM. El error número 4 es que los PEBS adaptables *podrían* omitir efectivamente los filtros de eventos establecidos por el host, ya que el "Grupo de información de acceso a memoria actualizado" registra información que podría no estar permitida por el espacio de usuario a través de KVM_SET_PMU_EVENT_FILTER. El error número 5 es que KVM no garantiza que los MSR LBR mantengan valores de invitado (o al menos ceros) al ingresar a una vCPU con PEBS adaptable, lo que permite al invitado leer los LBR del host, es decir, los RIP/direcciones del host, al habilitar las "Entradas LBR". registros. Deshabilite el soporte PEBS adaptable como solución inmediata debido a la gravedad de la fuga de LBR en particular, y porque corregir todos los errores no será trivial, por ejemplo, no es adecuado para realizar backporting a núcleos estables. ¡Nota! Esto interrumpirá la migración en vivo, pero tratar de hacer que KVM funcione bien con la migración en vivo sería bastante complicado, no se garantizaría que funcione (es decir, KVM aún podría matar/confundir al invitado) y no está claro si hay alguno disponible públicamente. Los VMM que admiten PEBS adaptables, y mucho menos migran en vivo las máquinas virtuales que admiten PEBS adaptables; por ejemplo, QEMU no admite PEBS de ninguna manera.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27006)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Thermal/debugfs: agregue el incremento de conteo faltante a Thermal_debug_tz_trip_up() El campo de conteo en la estructura trip_stats, que representa la cantidad de veces que la temperatura de la zona estuvo por encima del punto de disparo, debe incrementarse en Thermal_debug_tz_trip_up(), por dos razones. Primero, si se cruza un punto de viaje en el camino hacia arriba por primera vez, Thermal_debug_update_temp() llamado desde update_temperature() no lo ve porque aún no se ha agregado a la matriz trips_crossed[] en el objeto struct tz_debugfs de la zona térmica. Por lo tanto, cuando se llama a Thermal_debug_tz_trip_up() después de eso, el valor de conteo del punto de disparo es 0, y el intento de dividirlo durante el cálculo de la temperatura promedio conduce a un error de división que provoca que el kernel falle. Establecer el conteo en 1 antes de la división incrementándolo soluciona este problema. En segundo lugar, si se cruza un punto de viaje en el camino hacia arriba, pero ya se ha cruzado en el camino hacia arriba, es necesario incrementar su valor de conteo para registrar el hecho de que la temperatura de la zona está por encima del viaje en este momento. Sin hacer eso, si las mitigaciones aplicadas después de cruzar el viaje hacen que la temperatura de la zona caiga por debajo de su umbral, el conteo no se actualizará para este episodio en absoluto y la temperatura promedio en el registro de estadísticas del viaje será algo mayor de lo que debería ser. . CC :6.8+ # 6.8+
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27007)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: userfaultfd: cambie src_folio después de asegurarse de que no esté fijado en UFFDIO_MOVE Commit d7a08838ab74 ("mm: userfaultfd: corrija el cambio inesperado en src_folio cuando UFFDIO_MOVE falla") movió src_folio->{mapping, index} cambiando a después de borrar la tabla de páginas y asegurarse de que no esté fijada. Esto evita fallos en el intercambio+migración y posiblemente daños en la memoria. Sin embargo, la confirmación no solucionó el problema en el caso de la página enorme.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27009)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/cio: corrige la condición de ejecución durante el procesamiento en línea Existe una condición de ejecución en ccw_device_set_online() que puede causar que el proceso en línea falle, dejando el dispositivo afectado en un estado inconsistente. Como resultado, los intentos posteriores de configurar ese dispositivo en línea fallan con el código de retorno ENODEV. El problema se produce cuando llega una solicitud de verificación de ruta después de que se complete la espera hasta que se complete el estado final del dispositivo, pero antes de que se evalúe el estado del resultado. Solucione este problema asegurándose de que el bloqueo del dispositivo CCW se mantenga entre la determinación del estado final y la verificación del estado del resultado. Tenga en cuenta que desde: commit 2297791c92d0 ("s390/cio: no cancelar el registro del subcanal de los controladores secundarios") es mucho más probable que se produzcan solicitudes de verificación de ruta durante el arranque, lo que aumenta las posibilidades de que se produzca esta condición de ejecución.
  
• Vulnerabilidad en kernel de Linux (CVE-2023-52652)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NTB: corrige una posible fuga de nombre en ntb_register_device() Si device_register() falla en ntb_register_device(), se debe liberar el nombre del dispositivo asignado por dev_set_name(). Según el comentario en device_register(), las personas que llaman deben usar put_device() para abandonar la referencia en la ruta de error. Así que solucione este problema llamando a put_device() en la ruta del error para que el nombre pueda liberarse en kobject_cleanup(). Como resultado de esto, put_device() en la ruta de error de ntb_register_device() se elimina y se devuelve el error real. [mani: mensaje de confirmación reformulado]
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27023)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: Se corrigió la versión faltante de 'active_io' para descarga submit_flushes atomic_set(&mddev->flush_pending, 1); rdev_for_each_rcu(rdev, mddev) atomic_inc(&mddev->flush_pending); bi->bi_end_io = md_end_flush submit_bio(bi); /* purgar io se realiza primero */ md_end_flush if (atomic_dec_and_test(&mddev->flush_pending)) percpu_ref_put(&mddev->active_io) -> active_io no se publica si (atomic_dec_and_test(&mddev->flush_pending)) -> falta la versión de active_io para Como consecuencia, mddev_suspend() esperará a que 'active_io' sea cero para siempre. Solucione este problema liberando 'active_io' en submit_flushes() si 'flush_pending' se reduce a cero.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27027)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dpll: corrige dpll_xa_ref_*_del() para múltiples registros Actualmente, si hay múltiples registros del mismo pin en el mismo dispositivo dpll, se observan las siguientes advertencias: ADVERTENCIA: CPU: 5 PID: 2212 en drivers/dpll/dpll_core.c:143 dpll_xa_ref_pin_del.isra.0+0x21e/0x230 ADVERTENCIA: CPU: 5 PID: 2212 en drivers/dpll/dpll_core.c:223 __dpll_pin_unregister+0x2b3/0x2c0 El problema es que Tanto en dpll_xa_ref_dpll_del() como en dpll_xa_ref_pin_del() el registro solo se elimina de la lista en caso de que el recuento de referencias caiga a cero. Eso está mal, siempre hay que eliminar el registro. Para solucionar este problema, elimine el registro de la lista y libérelo incondicionalmente, en lugar de hacerlo sólo cuando el contador de referencia de referencia llegue a cero.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27034)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: f2fs: compress: corrección para cubrir la escritura normal del clúster con cp_rwsem Cuando sobrescribimos el clúster comprimido con el clúster normal, no debemos desbloquear cp_rwsem durante f2fs_write_raw_pages(); de lo contrario, los datos se dañarán si Los bloques parciales persistieron antes de CP y SPOR, debido a que los metadatos del clúster no se actualizaron atómicamente.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27035)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: compress: corrección para garantizar la persistencia de los bloques comprimidos por CP. Si el bloque de datos en el clúster comprimido no persiste con los metadatos durante el punto de control, después de SPOR, los datos pueden estar dañados, garanticemos que escribir página comprimida por punto de control.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27036)
  Severidad: ALTA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cifs: corrige la corrupción de datos de reescritura cifs writeback no maneja correctamente el caso en el que cifs_extend_writeback() llega a un punto en el que está considerando una publicación adicional, pero esto sobrepasaría el tamaño de wsize - en momento en el que sale del ciclo de escaneo de xarray y llama a xas_pause(). El problema es que xas_pause() avanza el contador de bucle, omitiendo así esa página. Lo que debe suceder es que se llame a xas_reset() cada vez que decidamos que no queremos procesar la página que estamos viendo, sino enviar la solicitud que estamos creando y comenzar una nueva. Solucione este problema copiando y adaptando el código de escritura de netfslib como medida temporal, y la escritura diferida de cifs se descargará a netfslib en un futuro próximo. Esto también soluciona el problema con el uso de filemap_get_folios_tag() que provocaba un reintento de un grupo de páginas que el extensor ya había tratado. Esto se puede probar creando, por ejemplo, un archivo de 64 K en algún lugar que no esté en cif (de lo contrario, la descarga de copia podría complicarse), montando un recurso compartido cif con un tamaño de 64000, copiando el archivo en él y luego comparando el archivo original y la copia. : dd if=/dev/urandom of=/tmp/64K bs=64k count=1 mount //192.168.6.1/test /mnt -o user=...,pass=...,wsize=64000 cp /tmp /64K /mnt/64K cmp /tmp/64K /mnt/64K Sin la corrección, el cmp falla en la posición 64000 (o poco después).
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27039)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: clk: hisilicon: hi3559a: corrige un devm_kfree() erróneo 'p_clk' es una matriz asignada justo antes del bucle for para todos los clk que deben registrarse. Se incrementa en cada iteración del bucle. Si falla una llamada a clk_register(), 'p_clk' puede señalar algo diferente de lo que debería liberarse. Lo mejor que podemos hacer es evitar esta liberación incorrecta de memoria.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27056)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: asegúrese de que exista la cola de descarga TID La ruta del código de reanudación supone que se ha configurado la cola de TX para la descarga de TID. En el momento de la reanudación, intenta sincronizar el puntero de escritura, ya que es posible que el firmware lo haya actualizado. En el caso inusual de que no se hayan enviado paquetes en el TID 0, la cola no se habrá asignado y esto provocará una falla. Solucione este problema asegurándose de que la cola exista en el momento de la suspensión.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27057)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: SOF: ipc4-pcm: workaround para firmware bloqueado en suspensión del sistema Cuando el sistema se suspende mientras el audio está activo, se invoca sof_ipc4_pcm_hw_free() para restablecer las canalizaciones desde durante la suspensión el DSP está apagado, las transmisiones se reiniciarán después de reanudarse. Si el firmware falla mientras se ejecuta el audio (o cuando reiniciamos la transmisión antes de suspenderla), entonces sof_ipc4_set_multi_pipeline_state() fallará con un error de IPC y se interrumpirá el cambio de estado. Esto provocará una desalineación entre el estado del kernel y del firmware en el siguiente arranque del DSP, lo que provocará errores devueltos por el firmware para los mensajes IPC, lo que eventualmente provocará un error en la reanudación del audio. Al cerrar la transmisión, los errores se ignoran, por lo que el estado del kernel se corregirá en el siguiente inicio del DSP, es decir, en el segundo inicio después del pánico del DSP. Si se llama a sof_ipc4_trigger_pipelines() desde sof_ipc4_pcm_hw_free() entonces el parámetro de estado es SOF_IPC4_PIPE_RESET y solo en este caso. Trate un reinicio forzado de canalización de manera similar a como tratamos un pcm_free ignorando el error en el envío del estado para permitir que el estado del kernel sea consistente con el estado que tendrá el firmware después del siguiente arranque.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27063)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: leds: trigger: netdev: corrige el pánico del kernel al cambiar el nombre de la interfaz, notifica el trigono. Commit d5e01266e7f5 ("leds: trigger: netdev: agrega un modo de velocidad de enlace específico adicional") en los diversos cambios, reelaborados la forma de configurar el modo LINKUP en el commit cee4bd16c319 ("leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename") y lo moví a una función genérica. Esto cambió la lógica donde, en la implementación anterior, se usaba el desarrollo del evento desencadenante para verificar si el operador estaba bien, pero en la nueva implementación con la función genérica, se usa el desarrollo en trigger_data. Esto es problemático y causa un posible pánico en el kernel debido al hecho de que el desarrollador en trigger_data aún hace referencia al anterior, ya que el nuevo (pasado desde el evento desencadenante) aún debe retenerse y guardarse en la estructura trigger_data (hecho en el caso NETDEV_REGISTER). Al llamar a get_device_state(), se utiliza un net_dev no válido y esto provoca un pánico en el kernel. Para manejar esto correctamente, mueva la llamada a get_device_state() después de que el nuevo net_dev esté configurado correctamente en trigger_data (en el caso NETDEV_REGISTER) y analice correctamente el nuevo dev.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27080)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: corrige la ejecución al detectar rangos de delalloc durante fiemap Para fiemap recientemente dejamos de bloquear el rango de extensión objetivo durante toda la duración de la llamada a fiemap, para evitar un punto muerto en un escenario donde el búfer fiemap resulta ser un rango mapeado en memoria del mismo archivo. Es muy poco probable que este caso de uso sea útil en la práctica, pero puede activarse mediante pruebas difusas (syzbot, etc.). Sin embargo, esto introdujo una ejecución que nos hace perder rangos de delalloc para regiones de archivos que actualmente están vacías, por lo que quien llama a fiemap no sabrá que hay datos para algunas regiones de archivos. Esto puede ser bastante grave en algunos casos de uso; por ejemplo, en las versiones de Coreutils anteriores a la 9.0, el programa cp utilizaba fiemap para detectar agujeros y datos en el archivo de origen, copiando solo regiones con datos (extensiones o delalloc) del archivo de origen al destino. archivo para preservar los agujeros (consulte la documentación para conocer su opción de línea de comando --sparse). Esto significa que si se usó cp con un archivo de origen que tenía delalloc en un agujero, el archivo de destino podría terminar sin esos datos, lo que efectivamente es un problema de pérdida de datos, si llegara a la ejecución que se describe a continuación. La ejecución ocurre así: 1) Se llama a Fiemap, sin el indicador FIEMAP_FLAG_SYNC, para un archivo que tiene delalloc en el rango de archivos [64M, 65M[, que actualmente es un agujero; 2) Fiemap bloquea el inodo en modo compartido, luego comienza a iterar el árbol de subvolumen del inodo buscando elementos de extensión de archivo, sin tener todo el rango objetivo de fiemap bloqueado en el árbol io del inodo - el cambio introducido recientemente por el commit b0ad381fa769 ("btrfs: fix deadlock" con fiemap y bloqueo de extensión"). Solo bloquea rangos en el árbol io cuando encuentra un agujero o una extensión de asignación previa desde esa confirmación; 3) Tenga en cuenta que fiemap clona cada hoja antes de usarla, y esto es para evitar interbloqueos al bloquear un rango de archivos en el árbol io del inodo y el búfer de fiemap está asignado en memoria a algún archivo, porque escribir en la página con btrfs_page_mkwrite() esperará en cualquier extensión ordenada para el rango de la página y la extensión ordenada necesita bloquear el rango y puede necesitar modificar la misma hoja, lo que lleva a un punto muerto en la hoja; 4) Mientras se iteran los elementos de extensión del archivo en la hoja clonada antes de encontrar el hueco en el rango [64M, 65M[, la delalloc en ese rango se vacía y su extensión ordenada se completa, lo que significa que el elemento de extensión del archivo correspondiente está en el árbol de subvolumen del inodo. , pero no está presente en la hoja clonada sobre la que fiemap está iterando; 5) Cuando fiemap encuentra el agujero en el rango [64M, 65M[ al ver el espacio en la hoja clonada (o un elemento de extensión de archivo con disk_bytenr == 0 en caso de que la función NO_HOLES no esté habilitada), bloqueará ese rango de archivos. en el árbol io del inodo y luego busque delalloc verificando el bit EXTENT_DELALLOC en el árbol io para ese rango y extensiones ordenadas (con btrfs_find_delalloc_in_range()). Pero no encuentra nada ya que la delalloc en ese rango ya se vació y la extensión ordenada se completó y desapareció; como resultado, fiemap no informará que hay delalloc o una extensión para el rango [64M, 65M[, por lo que el espacio del usuario será engañoso a pensar que hay un agujero en ese rango. En realidad, esto podría activarse esporádicamente con el caso de prueba generic/094 de fstests, que informa que falta un rango de extensión/delalloc como este: generic/094 2s ... - falta de coincidencia de salida (consulte /home/fdmanana/git/hub/xfstests/results //generic/094.out.bad) ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27389)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pstore: inode: solo se necesita d_invalidate(). La descarga de un backend modular de pstore con registros en pstorefs activaría la advertencia de doble caída de dput(): ADVERTENCIA: CPU: 0 PID: 2569 en fs/dcache.c:762 dput.part.0+0x3f3/0x410 Usar la combinación de d_drop()/dput() (como se menciona en Documentation/filesystems/vfs.rst) no es el enfoque correcto aquí, y conduce al problema de recuento de referencias visto anteriormente. Utilice d_invalidate() y actualice el código para no molestarse en buscar códigos de error que nunca sucederán. ---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27390)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: mcast: elimina una barrera de sincronización_net() en ipv6_mc_down() Como se discutió en el pasado (commit 2d3916f31891 ("ipv6: corrige caídas de skb en igmp6_event_query() e igmp6_event_report()" )) Creo que la llamada sincronizar_net() en ipv6_mc_down() no es necesaria. Bajo carga, sincronizar_net() puede durar entre 200 usos y 5 ms. KASAN parece estar de acuerdo también.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27391)
  Severidad: MEDIA
  Fecha de publicación: 01/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: wilc1000: no reasignar la cola de trabajo cada vez que se agrega una interfaz. Commit 09ed8bfc5215 ("wilc1000: cambiar el nombre de la cola de trabajo de "WILC_wq" a "NETDEV-wq"") movió la creación de la cola de trabajo en wilc_netdev_ifc_init para configurar el nombre de la interfaz en el nombre de la cola de trabajo. Sin embargo, aunque el controlador solo necesita una cola de trabajo, se llama a wilc_netdev_ifc_init cada vez que agregamos una interfaz a través de un phy, lo que a su vez sobrescribe la cola de trabajo con una nueva. Esto se puede observar con los siguientes comandos: for i in $(seq 0 10) do iw phy phy0 interfaz add wlan1 tipo administrado iw dev wlan1 del done ps -eo pid,comm|grep wlan 39 kworker/R-wlan0 98 kworker/ R-wlan1 102 ktrabajador/R-wlan1 105 ktrabajador/R-wlan1 108 ktrabajador/R-wlan1 111 ktrabajador/R-wlan1 114 ktrabajador/R-wlan1 117 ktrabajador/R-wlan1 120 ktrabajador/R-wlan1 123 ktrabajador/R- wlan1 126 kworker/R-wlan1 129 kworker/R-wlan1 Solucione esta fuga volviendo a colocar la asignación hif_workqueue en wilc_cfg80211_init. Con respecto al nombre de la cola de trabajo, es relevante establecerlo en minúsculas; sin embargo, no está adjunto a un netdev específico, por lo que hacer cumplir el nombre de netdev en el nombre no es tan relevante. Aún así, enriquezca el nombre con el nombre de wiphy para dejar claro qué phy está usando la cola de trabajo.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47532)
  Severidad: MEDIA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/devfreq: corrige la fuga de referencia de OPP
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47533)
  Severidad: ALTA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vc4: kms: borre el puntero de commit FIFO de HVS una vez realizado. El commit 9ec03d7f1ed3 ("drm/vc4: kms: espere a los usuarios FIFO anteriores antes de una confirmación") introdujo una espera en el commit anterior realizada en un HVS FIFO determinado. Sin embargo, nunca borramos ese puntero una vez hecho. Dado que drm_crtc_commit_put puede liberar la estructura drm_crtc_commit directamente si fuéramos el último usuario, esto significa que puede llevar a un use-after free si duplicáramos el estado, y ese puntero obsoleto incluso se copiaría al nuevo estado. Establezca el puntero en NULL una vez que hayamos terminado con la espera para que no transfiramos un puntero a una estructura liberada.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47536)
  Severidad: ALTA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/smc: corrige list_del incorrecto en smc_lgr_cleanup_early smc_lgr_cleanup_early() pretendía eliminar el grupo de enlaces de la lista de grupos de enlaces, pero eliminó el encabezado de la lista por error. Esto puede causar daños en la memoria ya que no eliminamos el grupo de enlaces real de la lista y luego integramos la estructura del grupo de enlaces. Recibimos un pánico de corrupción de lista al realizar la prueba: [ 231.277259] list_del corruption. prev->next should be ffff8881398a8000, but was 0000000000000000 [ 231.278222] ------------[ cut here ]------------ [ 231.278726] kernel BUG at lib/list_debug.c:53! [ 231.279326] invalid opcode: 0000 [#1] SMP NOPTI [ 231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435 [ 231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014 [ 231.281248] Workqueue: events smc_link_down_work [ 231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90 [ 231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c 60 82 e8 6c cc 6a 00 0f 0b 48 89 fe 48 c7 c7 c0 4c 60 82 e8 5b cc 6a 00 <0f> 0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc [ 231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292 [ 231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000 [ 231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040 [ 231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001 [ 231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001 [ 231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003 [ 231.288337] FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 [ 231.289160] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0 [ 231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 231.291940] Call Trace: [ 231.292211] smc_lgr_terminate_sched+0x53/0xa0 [ 231.292677] smc_switch_conns+0x75/0x6b0 [ 231.293085] ? update_load_avg+0x1a6/0x590 [ 231.293517] ? ttwu_do_wakeup+0x17/0x150 [ 231.293907] ? update_load_avg+0x1a6/0x590 [ 231.294317] ? newidle_balance+0xca/0x3d0 [ 231.294716] smcr_link_down+0x50/0x1a0 [ 231.295090] ? __wake_up_common_lock+0x77/0x90 [ 231.295534] smc_link_down_work+0x46/0x60 [ 231.295933] process_one_work+0x18b/0x350
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47538)
  Severidad: MEDIA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rxrpc: corrigió la fuga de rxrpc_local en rxrpc_lookup_peer() Es necesario llamar a rxrpc_put_local() para el candidato par antes de kfree(), ya que contiene una referencia a rxrpc_local. [DH: v2: modificado para abstraer el código de liberación del par en una función]
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47539)
  Severidad: MEDIA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rxrpc: corrige la fuga de rxrpc_peer en rxrpc_look_up_bundle() Es necesario llamar a rxrpc_put_peer() para el paquete candidato antes de kfree(), ya que contiene una referencia a rxrpc_peer. [DH: v2: modificado para abstraer el código de liberación del paquete en una función]
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47544)
  Severidad: MEDIA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tcp: corregir corrupción de fragmentos de página en falla de página Steffen informó una corrupción de flujo TCP para solicitudes HTTP atendidas por el servidor web Apache usando un punto de montaje cifs y mapeando la memoria del archivo relevante. La causa raíz es bastante similar a la abordada por el commit 20eb4f29b602 ("net: fix sk_page_frag() recursividad desde la recuperación de memoria"). Aquí, el acceso anidado al fragmento de la página de tareas se debe a un error de página en el búfer de memoria del espacio de usuario (mapeado) proveniente del archivo cifs. El controlador de errores de página realiza una transacción smb en un socket diferente, dentro del mismo contexto de proceso. Dado que sk->sk_allaction para dicho socket no impide el uso de task_frag, la asignación anidada modifica "bajo el capó" el fragmento de página en uso por la llamada externa sendmsg, corrompiendo la secuencia. El seguimiento general de la pila relevante se parece al siguiente: httpd 78268 [001] 3461630.850950: probe:tcp_sendmsg_locked: fffffff91461d91 tcp_sendmsg_locked+0x1 ffffffff91462b57 tcp_sendmsg+0x27 sock_sendmsg+0x3e ffffffffc06dfe1d smb_send_kvec+0x28 [...] ffffffffc06cfaf8 cifs_readpages+0x213 ffffffff90e83c4b read_pages+0x6b ffffffff90e83f31 __do_page_cache_readahead+0x1c1 ffffffff90e79e98 filemap_fault+0x788 ffffffff90eb0458 __do_fault+0x38 ffffffff90eb5280 do_fault+0x1a0 ffffffff90eb7c84 x4d4 ffffffff90eb8093 handle_mm_fault+0xc3 ffffffff90c74f6d __do_page_fault+0x1ed ffffffff90c75277 do_page_fault+0x37 ffffffff9160111e page_fault+0x1e ffffffff9109e7b5 copyin+0x25 9109eb40 _copia_de_iter_full+0xe0 ffffffff91462370 tcp_sendmsg_locked+0x5e0 ffffffff91462370 tcp_sendmsg_locked +0x5e0 ffffffff91462b57 tcp_sendmsg+0x27 ffffffff9139815c sock_sendmsg+0x4c ffffffff913981f7 sock_write_iter+0x97 ffffffff90f2cc56 do_iter_readv_writev+0x156 0 do_iter_write+0x80 ffffffff90f2e1c3 vfs_writev+0xa3 ffffffff90f2e27c do_writev+0x5c ffffffff90c042bb do_syscall_64+0x5b ffffffff916000ad Entry_SYSCALL_64_after_hwframe+0x65 El sistema de archivos cifs establece correctamente sk_allocations a GFP_NOFS, podemos evitar el anidamiento utilizando el fragmento de página sk para la asignación que carece del indicador __GFP_FS. No defina un mm-helper adicional para eso, ya que está estrictamente vinculado al uso del fragmento de página sk. v1 -> v2: - use una verificación estricta de sk_page_frag() en lugar de reordenar el código (Eric)
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47553)
  Severidad: ALTA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched/scs: restablecer el estado de la pila de tareas en Bringup_cpu() Para desconectar en caliente una CPU, la tarea inactiva en esa CPU llama a algunas capas de código C antes de abandonar finalmente el kernel. Cuando KASAN está en uso, se deja una sombra envenenada para cada uno de los marcos de pila activos y cuando las pilas de llamadas de sombra están en uso. Cuando se utilizan pilas de llamadas ocultas (SCS), el SCS SP guardado de la tarea se deja apuntando a un punto arbitrario dentro de la pila de llamadas ocultas de la tarea. Cuando una CPU está desconectada y luego conectada nuevamente al kernel, este estado obsoleto puede afectar negativamente la ejecución. La sombra de KASAN obsoleta puede generar alias en nuevos marcos de pila y generar advertencias de KASAN falsas. Un SCS SP obsoleto es efectivamente una pérdida de memoria e impide que se utilice una parte de la pila de llamadas ocultas. Después de varios ciclos de conexión en caliente, toda la pila de llamadas ocultas de la tarea inactiva puede quedar inutilizable. Anteriormente solucionamos el problema de KASAN en el commit: e1b77c92981a5222 ("sched/kasan: eliminar el veneno de KASAN obsoleto después de la conexión en caliente")... eliminando cualquier veneno de pila de KASAN obsoleto inmediatamente antes de conectar una CPU. Posteriormente, en El commit: f1a0a376ca0c4ef1 ("sched/core: Inicialice la tarea inactiva con la preferencia deshabilitada")... la refactorización dejó la limpieza de KASAN y SCS en un código de inicialización de subproceso inactivo de una sola vez en lugar de algo invocado antes de que cada CPU se conectara. rompiendo ambos como arriba. Arreglamos SCS (pero no KASAN) en El commit: 63acd42c0d4942f7 ("sched/scs: restablecer la pila de sombra cuando idle_task_exit")... pero como esto se ejecuta en el contexto de la tarea inactiva que está fuera de línea, es potencialmente frágil. Para solucionar estos problemas de manera consistente y más sólida, restablezca la sombra SCS SP y KASAN de la tarea inactiva de una CPU inmediatamente antes de conectar esa CPU en Bringup_cpu(). Esto garantiza que la tarea inactiva siempre tenga un estado consistente cuando se está ejecutando y elimina la necesidad de tenerlo al salir de una tarea inactiva. Siempre que se crea un subproceso, dup_task_struct() le dará a la tarea una pila que está libre de sombra KASAN e inicializará el SP SCS de la tarea, por lo que no hay necesidad de inicializar especialmente ninguno de los subprocesos inactivos dentro de init_idle(), ya que esto solo era necesario para manejar ciclos de conexión en caliente. Probé esto en arm64 con: * gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK * clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK ... offlining and onlining CPUS with: | while true; do | for C in /sys/devices/system/cpu/cpu*/online; do | echo 0 > $C; | echo 1 > $C; | done | done
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47555)
  Severidad: MEDIA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: vlan: corrige el desbordamiento insuficiente para real_dev refcnt Inyecte el error antes de dev_hold(real_dev) en Register_vlan_dev() y ejecute el siguiente caso de prueba: ip link add dev dummy1 tipo dummy ip link add nombre dummy1.100 link dummy1 tipo vlan id 100 ip link del dev dummy1 Cuando se elimina el dispositivo de red ficticio, recibiremos una ADVERTENCIA como la siguiente: ===================== ==================================================== = refcount_t: decremento hit 0; pérdida de memoria. ADVERTENCIA: CPU: 2 PID: 0 en lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 y un bucle sin fin de: ======================== ================================================= unregister_netdevice: esperando que el dummy1 quede libre. Recuento de uso = -1073741824 Esto se debe a que dev_put(real_dev) en vlan_dev_free() se llama sin dev_hold(real_dev) en Register_vlan_dev(). Hace que el refcnt de real_dev se desborde. Mueva dev_hold(real_dev) a vlan_dev_init() que es la devolución de llamada de ndo_init(). Eso hace que dev_hold() y dev_put() para real_dev de vlan sean simétricos.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47558)
  Severidad: MEDIA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: stmmac: Deshabilitar las colas de Tx al reconfigurar la interfaz Las colas de Tx no se deshabilitaron en situaciones en las que el controlador necesitaba detener la interfaz para aplicar una nueva configuración. Esto podría provocar un pánico en el kernel al realizar cualquiera de las 3 acciones siguientes: * reconfigurar el número de colas (ethtool -L) * reconfigurar el tamaño de los búferes circulares (ethtool -G) * instalar/eliminar un programa XDP (ip l set dev ethX xdp) Evite el pánico asegurándose de que se llame a netif_tx_disable al detener una interfaz. Sin este parche, se puede observar el siguiente pánico del kernel al realizar cualquiera de las acciones anteriores: No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff80001238d040 [....] Seguimiento de llamadas: dwmac4_set_addr+0x8/0x10 dev_hard_start_xmit+0xe4/0x1ac sch_direct_xmit+ 0xe8/0x39c __dev_queue_xmit+0x3ec/0xaf0 dev_queue_xmit+0x14/0x20 [...] [fin de seguimiento 0000000000000002]---
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47561)
  Severidad: ALTA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i2c: virtio: deshabilita el manejo del tiempo de espera Si se alcanza un tiempo de espera, puede resultar en datos incorrectos en el bus I2C y/o daños en la memoria del invitado, ya que el dispositivo aún puede estar funcionando. en los buffers que se le dieron mientras el huésped los liberó. Aquí está, por ejemplo, el inicio de un splat slub_debug que se activó en la siguiente transferencia después de que se obligó a que una transferencia expirara estableciendo un punto de interrupción en el backend (rust-vmm/vhost-device): ERROR kmalloc-1k (No contaminado ): Veneno sobrescrito Primer byte 0x1 en lugar de 0x6b Asignado en virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29 __kmalloc+0xc2/0x1c9 virtio_i2c_xfer+0x65/0x35c __i2c_transfer+0x429/0x57d 0x115/0x134 i2cdev_ioctl_rdwr+0x16a/ 0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Liberado en virtio_i2c_xfer+0x32e/0x35c edad=244 cpu=0 pid=29 kfree+0x1bd/0x1cc x32e/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115 /0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 No existe una solución sencilla para esto (el controlador siempre tendría que crear búferes de rebote y conservarlos hasta que el dispositivo finalmente devuelva el búferes), así que simplemente deshabilite el soporte de tiempo de espera por ahora.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47565)
  Severidad: ALTA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: mpt3sas: solucionó el pánico del kernel durante la prueba de ciclo de energía de la unidad. Mientras se recorre la lista sdev de shost, es posible que una de las unidades se esté eliminando y su objeto sas_target se libere pero su objeto sdev permanece intacta. En consecuencia, puede ocurrir un pánico en el kernel mientras el controlador intenta acceder al campo sas_address del objeto sas_target sin verificar también si el objeto sas_target es NULL.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47566)
  Severidad: ALTA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: proc/vmcore: corrige el borrado del búfer del usuario usando correctamente clear_user() Para borrar un búfer de usuario no podemos simplemente usar memset, tenemos que usar clear_user(). Con un dispositivo virtio-mem que registra un vmcore_cb y tiene algo de memoria lógicamente desconectada dentro de un bloque de memoria de Linux agregado, puedo desencadenar fácilmente un ERROR copiando el vmcore a través de "cp": systemd[1]: Iniciando el servicio Kdump Vmcore Save. . kdump[420]: Kdump está utilizando el nivel de registro predeterminado (3). kdump[453]: guardar en /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: guardar vmcore-dmesg.txt en /sysroot/var/crash/127.0 .0.1-2021-11-11-14:59:22/ kdump[465]: guardar vmcore-dmesg.txt completo kdump[467]: guardar vmcore ERROR: no se puede manejar el error de página para la dirección: 00007f2374e01000 #PF: escritura del supervisor acceso en modo kernel #PF: error_code(0x0003) - violación de permisos PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Ups: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: p No contaminado 5.15.0+ # 6 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 01/04/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/ 0x86 Código: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 C7 44 05 F8 00 00 00 00 48 83 E7 F81 RSP: 0018: FFFFFC9000073BE08 EFLAGS: 00010212 RAX: 00000000000000001000 RBX: 000000002FD000 RCX: 00007F2374E RSI: 000000000000FFFFDFFF RDI: 00007F2374E01008 RBP: 000000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: 88807bd421e8 FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2 : 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Seguimiento de llamadas: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 do_syscall_64+0x3b/0x90 Entry_SYSCALL_64_after_hwframe+0x44/0xae Algunas CPU x86-64 tienen una función de CPU llamada "Prevención de acceso en modo supervisor (SMAP)", que se utiliza para detectar accesos incorrectos desde el kernel a los búferes de usuario como este: SMAP desencadena una violación de permisos en caso de acceso incorrecto. En la variante x86-64 de clear_user(), SMAP se maneja correctamente mediante clac()+stac(). Para solucionarlo, utilice correctamente clear_user() cuando estemos tratando con un búfer de usuario.
  
• Vulnerabilidad en kernel de Linux (CVE-2021-47567)
  Severidad: MEDIA
  Fecha de publicación: 24/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/32: corrige el bloqueo físico en el desbordamiento de la pila de vmap Desde El commit c118c7303ad5 ("powerpc/32: corrige la pila de vmap - No activar MMU antes de leer la estructura de la tarea") un desbordamiento de la pila de vmap resulta en un bloqueo duro. Esto se debe a que Emergency_ctx todavía se aborda con su dirección virtual, aunque la MMU de datos ya no esté activa en ese momento. Solucionarlo utilizando una dirección física en su lugar.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36015)
  Severidad: ALTA
  Fecha de publicación: 29/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ppdev: agregue una verificación de errores en Register_device. En Register_device, el valor de retorno de ida_simple_get no está marcado, por lo que ida_simple_get usará un valor de índice no válido. Para solucionar este problema, se debe verificar el índice después de ida_simple_get. Cuando el valor del índice es anormal, se debe imprimir un mensaje de advertencia, se debe descartar el puerto y se debe registrar el valor.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36887)
  Severidad: MEDIA
  Fecha de publicación: 30/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: e1000e: cambie usleep_range a udelay en el acceso mdic de PHY. Esta es una reversión parcial de el commit 6dbdd4de0362 ("e1000e: solución alternativa para errores MDI esporádicos en sistemas Meteor Lake"). El commit a la que se hace referencia usó usleep_range dentro de las rutinas de acceso PHY, que a veces se llaman desde un contexto atómico. Esto puede provocar un pánico en el kernel en algunos escenarios, como la desconexión y reconexión de cables en sistemas vPro. Resuelva esto volviendo a cambiar las llamadas usleep_range a udelay.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36890)
  Severidad: MEDIA
  Fecha de publicación: 30/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slab: make __free(kfree) acepta punteros de error Actualmente, si una asignación liberada automáticamente es un puntero de error que provocará un bloqueo. Un ejemplo de esto está en wm831x_gpio_dbg_show(). 171 caracteres *etiqueta __free(kfree) = gpiochip_dup_line_label(chip, i); 172 if (IS_ERR(etiqueta)) { 173 dev_err(wm831x->dev, "Error al duplicar la etiqueta\n"); 174 continúan; 175 } La función de limpieza automática también debería comprobar si hay indicadores de error; de lo contrario, seguiremos teniendo problemas como este.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36892)
  Severidad: MEDIA
  Fecha de publicación: 30/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slub: evita poner a cero el puntero libre de objetos externos para un solo commit libre 284f17ac13fe ("mm/slub: maneja la liberación masiva y de objetos individuales por separado") divide la liberación de objetos únicos y masivos en dos funciones slab_free() y slab_free_bulk() lo que lleva a slab_free() a llamar a slab_free_hook() directamente en lugar de slab_free_freelist_hook(). Si se establece `init_on_free`, slab_free_hook() pone a cero el objeto. Luego, si se configuran `slub_debug=F` y `CONFIG_SLAB_FREELIST_HARDENED`, la ruta lenta do_slab_free() ejecuta comprobaciones de coherencia de la lista libre e intenta decodificar un freepointer puesto a cero, lo que conduce a una detección de "Freepointer corrupto" en check_object(). Durante la liberación masiva, slab_free_freelist_hook() no se ve afectado ya que siempre establece el puntero libre de sus objetos usando set_freepointer() para mantener su lista libre reconstruida después de `init_on_free`. Para un solo libre, el puntero libre del objeto debe evitarse cuando se almacena fuera del objeto si está configurado "init_on_free". El puntero libre se deja como está, check_object() puede detectar más adelante un valor de puntero no válido debido a un desbordamiento de objetos. Para reproducir, configure `slub_debug=FU init_on_free=1 log_level=7` en la línea de comando de una compilación del kernel con `CONFIG_SLAB_FREELIST_HARDENED=y`. Registro de muestra de dmesg: [10.708715] ============================================ ================================== [10.710323] ERROR kmalloc-rnd-05-32 (Contaminado: GBT) : Freepointer corrupto [10.712695] -------------------------------------------- --------------------------------- [ 10.712695] [ 10.712695] Losa 0xffffd8bdc400d580 objetos=32 usados=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2) [ 10.716698] Objeto 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c [ 10.716698] [ 10.716698] Bytes b4 9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.720703] Objeto ffff9d9a80356600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [ 10.720703] Objeto ffff9d9a80356610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.724696] Relleno ffff9d9a8035666c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [ 10.724696] Relleno ffff9d9a8035667c: 00 00 00 00 .... [ 10.724696 ] FIX kmalloc-rnd-05-32: Objeto en 0xffff9d9a80356600 no liberado
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36895)
  Severidad: ALTA
  Fecha de publicación: 30/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: gadget: uvc: use el tamaño de búfer correcto al analizar listas de configfs. Este commit corrige la compatibilidad con gadgets uvc en plataformas de 32 bits. El commit 0df28607c5cb ("usb: gadget: uvc: Generalizar funciones auxiliares para su reutilización") introdujo una función auxiliar __uvcg_iter_item_entries() para ayudar con el análisis de listas de elementos en las tiendas de atributos de configfs. Esta función es una generalización de otra función muy similar, que utilizaba un búfer temporal de tamaño fijo asignado por la pila para cada elemento de la lista y utilizaba el operador sizeof() para comprobar posibles desbordamientos del búfer. La nueva función se cambió para asignar el búfer temporal ahora de tamaño variable en el montón, pero no se actualizó correctamente para verificar también el tamaño máximo del búfer usando el tamaño calculado en lugar del operador sizeof(). Como resultado, el tamaño máximo de elemento fue 7 (más terminador nulo) en plataformas de 64 bits y 3 en plataformas de 32 bits. Si bien 7 accidentalmente es apenas suficiente, 3 es definitivamente demasiado pequeño para algunos de los atributos de configuración de UVC. Por ejemplo, dwFrameInteval, especificado en unidades de 100 ns, normalmente tiene valores de elementos de 6 dígitos, por ejemplo, 166666 para 60 fps.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36898)
  Severidad: ALTA
  Fecha de publicación: 30/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: cdev: corrige kfifo no inicializado Si se solicita una línea con antirrebote, y eso resulta en un antirrebote en el software, y la línea se reconfigura posteriormente para habilitar la detección de bordes, entonces se realiza la asignación del Se pasa por alto kfifo para contener eventos de borde. Esto da como resultado que los eventos se escriban y lean desde un kfifo no inicializado. Los eventos leídos se devuelven al espacio de usuario. Inicialice el kfifo en el caso de que el software antirrebote ya esté activo.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36019)
  Severidad: ALTA
  Fecha de publicación: 30/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regmap: maple: corrige la corrupción de la caché en regcache_maple_drop() Cuando se mantiene el extremo superior de una entrada de bloque de caché, la matriz de entrada[] debe indexarse según el desplazamiento del registro base de el bloque, es decir, max - mas.index. El código indexaba la entrada [] solo por la dirección de registro, lo que generaba un acceso fuera de los límites que copiaba parte de la memoria del kernel sobre el contenido de la caché. Este error no fue detectado por la prueba regmap KUnit porque solo prueba con un bloque de registros que comienza en 0, por lo que mas.index == 0.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36025)
  Severidad: MEDIA
  Fecha de publicación: 30/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qla2xxx: arreglada por uno en qla_edif_app_getstats() La matriz app_reply->elem[] se asignó anteriormente en esta función y tiene elementos app_req.num_ports. Por lo tanto, esta > comparación necesita ser >= para evitar la corrupción de la memoria.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36027)
  Severidad: ALTA
  Fecha de publicación: 30/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: zonado: no marcar ZEROOUT en el búfer de extensión no sucio Btrfs borra el contenido de un búfer de extensión marcado como EXTENT_BUFFER_ZONED_ZEROOUT antes del envío de la biografía. Este mecanismo se introduce para evitar un agujero de escritura en un búfer de extensión, que una vez asignado, se marca como sucio, pero resulta innecesario y se limpia dentro de una operación de transacción. Actualmente, btrfs_clear_buffer_dirty() marca el búfer de extensión como EXTENT_BUFFER_ZONED_ZEROOUT y omite la función de entrada. Si esta llamada ocurre mientras el búfer está bajo IO (con el indicador WRITEBACK configurado, sin el indicador DIRTY), podemos agregar el indicador ZEROOUT y borrar el contenido del búfer justo antes de enviar una biografía. Como resultado: 1) puede provocar que se agregue un elemento de referencia retrasado defectuoso, lo que provoca un error de FS dañado (EUCLEAN), y 2) escribe el nodo del árbol borrado en el disco. El primer problema se analizó anteriormente en [1]. La corrupción ocurre cuando ejecuta una actualización de referencia retrasada. Por lo tanto, los datos en el disco están seguros. [1] https://lore.kernel.org/linux-btrfs/3f4f2a0ff1a6c818050434288925bdcf3cd719e5.1709124777.git.naohiro.aota@wdc.com/ Este último puede acceder a datos en disco. Pero, como ese nodo ya está procesado por btrfs_clear_buffer_dirty(), de todos modos se invalidará en la próxima confirmación de transacción. Por lo tanto, la posibilidad de combatir la corrupción es relativamente pequeña. De todos modos, debemos omitir marcar ZEROOUT en un búfer de extensión que no sea DIRTY, para mantener intacto el contenido bajo IO.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36028)
  Severidad: MEDIA
  Fecha de publicación: 30/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/hugetlb: corrija DEBUG_LOCKS_WARN_ON(1) cuando dissolve_free_hugetlb_folio() Cuando hice pruebas de falla de memoria recientemente, aparece la siguiente advertencia: DEBUG_LOCKS_WARN_ON(1) ADVERTENCIA: CPU: 8 PID: 1011 en kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0 Módulos vinculados en: mce_inject hwpoison_inject CPU: 8 PID: 1011 Comm: bash Kdump: cargado No contaminado 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3 Hardware nombre: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 01/04/2014 RIP: 0010:__lock_acquire+0xccb/0x1ca0 RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0 RBP: 1c6865d3280 R08: fffffffb0f570a8 R09: 0000000000009ffb R10: 0000000000000286 R11: fffffffb0f2ad50 R12: ffffa1c6865d3d10 R13: ffffa1c6865d3c70 : 0000000000000000 R15: 0000000000000004 FS: 00007ff9f32aa740( 0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff9f3134ba0 CR3: 00000008484e 4000 CR4: 00000000000006f0 Seguimiento de llamadas: lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages. part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_poison+0x9/0x70 Memory_failure+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/ 0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc /0x1d0 Entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 00007ff9f31d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 Pánico del kernel: no se sincroniza: kernel: pánico_on_warn configurado... CPU: 8 PID: 1011 Comm: bash Kdump: cargado No contaminado 6.9 .0-rc3-next-20240410-00012-gdb69f219f4be #3 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 01/04/2014 Llamada Seguimiento: pánico+0x326/0x350 check_panic_on_warn+0x4f/0x50 __warn+0x98/0x190 report_bug+0x18e/0x1a0 handle_bug+0x3d/0x70 exc_invalid_op+0x18/0x70 asm_exc_invalid_op+0x1a/0x20 RIP: 0010:__lock_adquirir+0xccb/0x1ca0 RSP : 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082 RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8 RDX: 00000000ffffffd8 RSI: 027 RDI: ffffa1ce5fc1c9c0 RBP: ffffa1c6865d3280 R08: fffffffb0f570a8 R09: 0000000000009ffb R10: 00000000000000286 R11: fffffffb0f2ad50 R12: ffffa1c6865d 3d10 R13: ffffa1c6865d3c70 R14: 0000000000000000 R15 : 0000000000000004 lock_acquire+0xbe/0x2d0 _raw_spin_lock_irqsave+0x3a/0x60 hugepage_subpool_put_pages.part.0+0xe/0xc0 free_huge_folio+0x253/0x3f0 dissolve_free_huge_page+0x147/0x210 __page_handle_ veneno+0x9/0x70 error_de_memoria+0x4e6/0x8c0 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/ 0x1d0 vfs_write+0x380/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xbc/0x1d0 Entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff9f3114887 RSP: 002b:00007ffecbacb4 58 EFLAGS: 00000246 ORIG_RAX: 00000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887 RDX: 000000000000000c RSI : 0000564494164e10 RDI: 0000000000000001 RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007ffffff R10: 0000000000000000 R11: 000000000000246 R12: 000000000000000c R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00 Después de que git divida e indague en el código, creo que la causa raíz es que el campo _deferred_list del folio está unido con el campo _hugetlb_subpool. En __update_and_free_hugetlb_folio(), folio->_deferred_ ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36032)
  Severidad: ALTA
  Fecha de publicación: 30/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: qca: corrige la fuga de información al recuperar el ID de compilación del firmware. Agregue las comprobaciones de cordura que faltan y mueva el búfer de ID de compilación de 255 bytes fuera de la pila para evitar la filtración de datos de la pila a través de debugfs en en caso de que la respuesta de información de compilación esté mal formada.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-36033)
  Severidad: ALTA
  Fecha de publicación: 30/05/2024
  Fecha de última actualización: 18/09/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: qca: corrige la fuga de información al obtener la identificación de la placa. Agregue la verificación de cordura que falta al recuperar la identificación de la placa para evitar fugas de datos de losa cuando luego solicite el firmware.
  
• Vulnerabilidad en Hibernate Validator (CVE-2025-35036)
  Severidad: MEDIA
  Fecha de publicación: 03/06/2025
  Fecha de última actualización: 18/09/2025
  Hibernate Validator, en versiones anteriores a la 6.2.0 y la 7.0.0, puede, de forma predeterminada y según su uso, interpolar la información proporcionada por el usuario en un mensaje de violación de restricciones con Expression Language. Esto podría permitir a un atacante acceder a información confidencial o ejecutar código Java arbitrario. Hibernate Validator, a partir de la 6.2.0 y la 7.0.0, ya no interpola mensajes personalizados de violación de restricciones con Expression Language y recomienda encarecidamente no permitir la información proporcionada por el usuario en dichos mensajes. CVE-2020-5245 y CVE-2025-4428 son ejemplos de vulnerabilidades relacionadas con la interpolación de datos proporcionados por el usuario en Expression Language.
  
• Vulnerabilidad en Redis de Yii 2 (CVE-2025-48493)
  Severidad: MEDIA
  Fecha de publicación: 05/06/2025
  Fecha de última actualización: 18/09/2025
  La extensión Redis de Yii 2 proporciona compatibilidad con el almacén de claves-valor de Redis para el framework Yii 2.0. Si falla la conexión, la extensión escribe la secuencia de comandos en los registros. Antes de la versión 2.0.20, los parámetros AUTH se escribían en texto plano, exponiendo el nombre de usuario y la contraseña. Esto podría ser un problema si un atacante tiene acceso a los registros. La versión 2.0.20 soluciona el problema.
  
• Vulnerabilidad en NVIDIA NVDebug (CVE-2025-23252)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 18/09/2025
  La herramienta NVIDIA NVDebug contiene una vulnerabilidad que podría permitir que un actor acceda a componentes restringidos. Explotar esta vulnerabilidad podría provocar la divulgación de información.
  
• Vulnerabilidad en urllib3 (CVE-2025-50181)
  Severidad: MEDIA
  Fecha de publicación: 19/06/2025
  Fecha de última actualización: 18/09/2025
  urllib3 es una librería cliente HTTP intuitiva para Python. Antes de la versión 2.5.0, era posible deshabilitar las redirecciones para todas las solicitudes instanciando un PoolManager y especificando reintentos para deshabilitarlas. Por defecto, las solicitudes y los usuarios de botocore no se ven afectados. Una aplicación que intente mitigar vulnerabilidades de SSRF o de redirección abierta deshabilitando las redirecciones a nivel de PoolManager seguirá siendo vulnerable. Este problema se ha corregido en la versión 2.5.0.
  
• Vulnerabilidad en poco (CVE-2025-6375)
  Severidad: MEDIA
  Fecha de publicación: 21/06/2025
  Fecha de última actualización: 18/09/2025
  Se encontró una vulnerabilidad en poco hasta la versión 1.14.1. Se ha clasificado como problemática. Este problema afecta a la función MultipartInputStream del archivo Net/src/MultipartReader.cpp. La manipulación provoca la desreferenciación de puntero nulo. El ataque debe abordarse localmente. Se ha hecho público el exploit y puede que sea utilizado. Actualizar a la versión 1.14.2 puede solucionar este problema. El parche se identifica como 6f2f85913c191ab9ddfb8fae781f5d66afccf3bf. Se recomienda actualizar el componente afectado.
  
• Vulnerabilidad en vstakhov libucl (CVE-2025-6499)
  Severidad: MEDIA
  Fecha de publicación: 23/06/2025
  Fecha de última actualización: 18/09/2025
  Se encontró una vulnerabilidad clasificada como problemática en vstakhov libucl hasta la versión 0.9.2. Esta vulnerabilidad afecta a la función ucl_parse_multiline_string del archivo src/ucl_parser.c. La manipulación provoca un desbordamiento del búfer en el montón. El ataque debe abordarse localmente. Se ha hecho público el exploit y puede que sea utilizado.
  
• Vulnerabilidad en IBM Sterling B2B Integrator e IBM Sterling File Gateway (CVE-2025-33008)
  Severidad: MEDIA
  Fecha de publicación: 19/08/2025
  Fecha de última actualización: 18/09/2025
  IBM Sterling B2B Integrator 6.2.1.0 e IBM Sterling File Gateway 6.2.1.0 son vulnerables a ataques de cross site scripting. Esta vulnerabilidad permite a un usuario autenticado incrustar código JavaScript arbitrario en la interfaz web, alterando así la funcionalidad prevista y pudiendo provocar la divulgación de credenciales en una sesión de confianza.
  
• Vulnerabilidad en Kapsch TrafficCom (CVE-2025-25733)
  Severidad: MEDIA
  Fecha de publicación: 26/08/2025
  Fecha de última actualización: 18/09/2025
  El control de acceso incorrecto en SPI Flash Chip of Kapsch TrafficCom RIS-9160 & RIS-9260 Roadside Units (RSUs) v3.2.0.829.23, v3.8.0.1119.42, y v4.6.0.1211.28 permite que atacantes físicamente próximos modifiquen arbitrariamente las regiones flash SPI, lo que lleva a una degradación de la postura de seguridad del dispositivo.
  
• Vulnerabilidad en NVIDIA NeMo Framework (CVE-2025-23312)
  Severidad: ALTA
  Fecha de publicación: 26/08/2025
  Fecha de última actualización: 18/09/2025
  NVIDIA NeMo Framework para todas las plataformas contiene una vulnerabilidad en el componente de servicios de recuperación, donde datos maliciosos creados por un atacante podrían provocar una inyección de código. Una explotación exitosa de esta vulnerabilidad podría provocar la ejecución de código, la escalada de privilegios, la divulgación de información y la manipulación de datos.
  
• Vulnerabilidad en NVIDIA NeMo Framework (CVE-2025-23313)
  Severidad: ALTA
  Fecha de publicación: 26/08/2025
  Fecha de última actualización: 18/09/2025
  NVIDIA NeMo Framework para todas las plataformas contiene una vulnerabilidad en el componente NLP, donde datos maliciosos creados por un atacante podrían causar un problema de inyección de código. Una explotación exitosa de esta vulnerabilidad podría provocar la ejecución de código, la escalada de privilegios, la divulgación de información y la manipulación de datos.
  
• Vulnerabilidad en NVIDIA NeMo Framework (CVE-2025-23314)
  Severidad: ALTA
  Fecha de publicación: 26/08/2025
  Fecha de última actualización: 18/09/2025
  NVIDIA NeMo Framework para todas las plataformas contiene una vulnerabilidad en el componente NLP, donde datos maliciosos creados por un atacante podrían causar un problema de inyección de código. Una explotación exitosa de esta vulnerabilidad podría provocar la ejecución de código, la escalada de privilegios, la divulgación de información y la manipulación de datos.
  
• Vulnerabilidad en NVIDIA NeMo Framework (CVE-2025-23315)
  Severidad: ALTA
  Fecha de publicación: 26/08/2025
  Fecha de última actualización: 18/09/2025
  NVIDIA NeMo Framework para todas las plataformas contiene una vulnerabilidad en el componente de exportación e implementación, donde los datos maliciosos creados por un atacante podrían causar un problema de inyección de código. Una explotación exitosa de esta vulnerabilidad podría provocar la ejecución de código, la escalada de privilegios, la divulgación de información y la manipulación de datos.