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 sirv.Com Image Optimizer, Resizer y CDN – Sirv (CVE-2024-27949)
  Severidad: MEDIA
  Fecha de publicación: 01/03/2024
  Fecha de última actualización: 17/12/2025
  Vulnerabilidad de Server-Side Request Forgery (SSRF) en sirv.Com Image Optimizer, Resizer y CDN – Sirv. Este problema afecta a Image Optimizer, Resizer y CDN – Sirv: desde n/a hasta 7.2.0.
  
• Vulnerabilidad en sirv.Com Image Optimizer, Resizer y CDN – Sirv (CVE-2024-27950)
  Severidad: MEDIA
  Fecha de publicación: 01/03/2024
  Fecha de última actualización: 17/12/2025
  Vulnerabilidad de autorización faltante en sirv.Com Image Optimizer, Resizer y CDN – Sirv. Este problema afecta a Image Optimizer, Resizer y CDN – Sirv: desde n/a hasta 7.2.0.
  
• Vulnerabilidad en Parse Server (CVE-2024-29027)
  Severidad: CRÍTICA
  Fecha de publicación: 19/03/2024
  Fecha de última actualización: 17/12/2025
  Parse Server es un backend de código abierto que se puede implementar en cualquier infraestructura que pueda ejecutar Node.js. Antes de las versiones 6.5.5 y 7.0.0-alpha.29, llamar a un nombre de función de nube de Parse Server o un nombre de trabajo de nube no válido bloquea el servidor y puede permitir la inyección de código, la manipulación interna del almacén o la ejecución remota de código. El parche en las versiones 6.5.5 y 7.0.0-alpha.29 agregó saneamiento de cadenas para el nombre de la función en la nube y el nombre del trabajo en la nube. Como workaround, desinfecte el nombre de la función en la nube y el nombre del trabajo en la nube antes de que llegue al servidor Parse.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27410)
  Severidad: MEDIA
  Fecha de publicación: 17/05/2024
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: rechazar cambio de tipo con cambio de ID de malla Actualmente es posible cambiar el ID de malla cuando la interfaz aún no está en modo malla, al mismo tiempo que se cambia a modo malla. Esto lleva a una sobrescritura de datos en la unión wdev->u para el tipo de interfaz que tiene actualmente, causando que cfg80211_change_iface() haga cosas incorrectas al cambiar. Probablemente podríamos permitir configurar una interfaz para malla mientras configuramos la ID de malla al mismo tiempo haciendo un orden diferente de operaciones aquí, pero en realidad no hay ningún espacio de usuario que vaya a hacer esto, así que simplemente no permita cambios en iftype al configurar la ID de malla.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27412)
  Severidad: MEDIA
  Fecha de publicación: 17/05/2024
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: alimentación: suministro: bq27xxx-i2c: no liberar IRQ no existente Es posible que el cliente bq27xxx i2c no tenga una IRQ, en cuyo caso client->irq será 0. bq27xxx_battery_i2c_probe( ) ya tiene una verificación if (cliente->irq) que envuelve request_threaded_irq(). Pero bq27xxx_battery_i2c_remove() llama incondicionalmente a free_irq(cliente->irq) lo que lleva a: [190.310742] ------------[ cortar aquí ]------------ [ 190.310843] Intentando liberar IRQ 0 [190.310861] que ya está libre ADVERTENCIA: CPU: 2 PID: 1304 en kernel/irq/manage.c:1893 free_irq+0x1b8/0x310 Seguido de un seguimiento al desvincular el controlador. Agregue un if (cliente->irq) a bq27xxx_battery_i2c_remove() mirroring probe() para solucionar este problema.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27413)
  Severidad: MEDIA
  Fecha de publicación: 17/05/2024
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: efi/capsule-loader: corrige el tamaño de asignación incorrecto gcc-14 advierte que la asignación con sizeof(void) en arquitecturas de 32 bits no es suficiente para phys_addr_t: drivers de 64 bits /firmware/efi/capsule-loader.c: En función 'efi_capsule_open': drivers/firmware/efi/capsule-loader.c:295:24: error: asignación de tamaño '4' insuficiente para el tipo 'phys_addr_t' {alias ' long long unsigned int'} con tamaño '8' [-Werror=alloc-size] 295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL); | ^ Utilice el tipo correcto aquí.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27414)
  Severidad: MEDIA
  Fecha de publicación: 17/05/2024
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtnetlink: corrige la lógica de error de la reescritura de IFLA_BRIDGE_FLAGS En el commit d73ef2d69c0d ("rtnetlink: let rtnl_bridge_setlink comprueba la longitud de IFLA_BRIDGE_MODE"), se realizó un ajuste a la lógica de bucle anterior en la función ` rtnl_bridge_setlink` para permitir que el bucle también verifique la longitud del atributo IFLA_BRIDGE_MODE. Sin embargo, este ajuste eliminó la declaración "break" y generó una lógica de error en la escritura de los indicadores al final de esta función. if (have_flags) memcpy(nla_data(attr), &flags, sizeof(flags)); // attr debería apuntar a IFLA_BRIDGE_FLAGS NLA !!! Antes de la confirmación mencionada, se concede que el `attr` sea IFLA_BRIDGE_FLAGS. Sin embargo, esto no es necesariamente cierto ahora, ya que el bucle actualizado permitirá que el atributo apunte al último NLA, incluso un NLA no válido que podría causar escrituras desbordadas. Este parche introduce una nueva variable `br_flag` para guardar el puntero NLA que apunta a IFLA_BRIDGE_FLAGS y lo usa para resolver la lógica de error mencionada.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-27416)
  Severidad: MEDIA
  Fecha de publicación: 17/05/2024
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: hci_event: Corrige el manejo de HCI_EV_IO_CAPA_REQUEST Si recibimos HCI_EV_IO_CAPA_REQUEST mientras HCI_OP_READ_REMOTE_EXT_FEATURES aún no se ha respondido, supongamos que el control remoto admite SSP ya que, de lo contrario, este evento no debería generarse.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-35807)
  Severidad: MEDIA
  Fecha de publicación: 17/05/2024
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corregida la corrupción durante el cambio de tamaño en línea Observamos una corrupción durante el cambio de tamaño en línea de un sistema de archivos de más de 16 TiB con un tamaño de bloque de 4k. Al tener más de 2 ^ 32 bloques, mke2fs desactiva resize_inode de forma predeterminada. El problema se puede reproducir en un sistema de archivos más pequeño por conveniencia desactivando explícitamente resize_inode. Un cambio de tamaño en línea a través de un límite de 8 GiB (el tamaño de un grupo de metabloques en esta configuración) conduce a una corrupción: dev=/dev/ # debería ser >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # soltar caché de página para forzar la recarga del bloque desde el disco echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test 2^21 = 2^15*2^6 equivale a 8 GiB de los cuales 2^15 es el número de bloques por grupo de bloques y 2^6 es el número de grupos de bloques que forman un metagrupo de bloques. La última suma de comprobación puede ser diferente dependiendo de cómo esté distribuido el archivo en los bloques físicos. La corrupción real ocurre en el bloque físico 63*2^15 = 2064384, que sería la ubicación de la copia de seguridad del descriptor de bloque del grupo de metabloques. Durante el cambio de tamaño en línea, el sistema de archivos se convertirá a meta_bg comenzando en s_first_meta_bg, que en el ejemplo es 2, es decir, todos los grupos de bloques después de 16 GiB. Sin embargo, en ext4_flex_group_add podríamos agregar grupos de bloques que aún no forman parte del primer metagrupo de bloques. En el reproductor logramos esto restando el tamaño de un grupo de bloques completo desde el punto donde comenzaría el grupo de metabloques. Esto debe tenerse en cuenta al actualizar los descriptores del grupo de bloques de respaldo para que sigan el diseño que no es meta_bg. La solución es agregar una prueba de si el grupo a agregar ya forma parte del grupo de metabloques o no.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-35819)
  Severidad: MEDIA
  Fecha de publicación: 17/05/2024
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: soc: fsl: qbman: use spinlock sin formato para cgr_lock smp_call_function siempre ejecuta su devolución de llamada en un contexto IRQ duro, incluso en PREEMPT_RT, donde los spinlocks pueden dormir. Por lo tanto, necesitamos usar un spinlock sin formato para cgr_lock para asegurarnos de que no estamos esperando una tarea inactiva. Aunque este error ha existido por un tiempo, no fue evidente hasta la confirmación ef2a8d5478b9 ("net: dpaa: Ajustar la profundidad de la cola al cambiar la velocidad") que invoca smp_call_function_single a través de qman_update_cgr_safe cada vez que un enlace sube o baja.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-35822)
  Severidad: MEDIA
  Fecha de publicación: 17/05/2024
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: udc: elimina la advertencia cuando la cola está deshabilitada ep Es posible que se active el siguiente mensaje de advertencia desde la función de almacenamiento masivo, ADVERTENCIA: CPU: 6 PID: 3839 en drivers/usb/gadget/udc /core.c:294 usb_ep_queue+0x7c/0x104 pc: usb_ep_queue+0x7c/0x104 lr: fsg_main_thread+0x494/0x1b3c La causa principal es que la función de almacenamiento masivo intenta poner en cola la solicitud desde el hilo principal, pero es posible que otro hilo ya deshabilite ep cuando la función se deshabilita. Como no hay ningún fallo de función en el controlador, para evitar el esfuerzo de corregir la advertencia, cambie WARN_ON_ONCE() en usb_ep_queue() a pr_debug().
  
• Vulnerabilidad en kernel de Linux (CVE-2024-35825)
  Severidad: MEDIA
  Fecha de publicación: 17/05/2024
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: ncm: corregido el manejo de paquetes de longitud de bloque cero Al conectarnos a un host Linux con CDC_NCM_NTB_DEF_SIZE_TX configurado en 65536, se ha observado que recibimos paquetes cortos, que vienen en intervalo de 5 a 10 segundos a veces y tiene una longitud de bloque cero, pero aún contiene 1 o 2 datagramas válidos presentes. Según la especificación NCM: "Si wBlockLength = 0x0000, el bloque finaliza con un paquete corto. En este caso, la transferencia USB aún debe ser más corta que dwNtbInMaxSize o dwNtbOutMaxSize. Si se envían exactamente bytes dwNtbInMaxSize o dwNtbOutMaxSize, y el tamaño es un múltiplo de wMaxPacketSize para la pipe dada, entonces no se enviará ningún ZLP. wBlockLength= 0x0000 debe usarse con extremo cuidado, debido a la posibilidad de que el host y el dispositivo no estén sincronizados y debido a problemas de prueba con wBlockLength = 0x0000. permite al remitente reducir la latencia comenzando a enviar un NTB muy grande y luego acortándolo cuando el remitente descubre que no hay datos suficientes para justificar el envío de un NTB grande". Sin embargo, existe un problema potencial con la implementación actual, ya que verifica para la aparición de múltiples NTB en una sola devolución verificando si los bytes sobrantes a procesar son cero o no. Si la longitud del bloque es cero, procesaríamos el mismo NTB infinitamente porque los bytes sobrantes nunca son cero y provocan un bloqueo. Solucione este problema rescatando si la longitud del bloque es cero.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-35830)
  Severidad: MEDIA
  Fecha de publicación: 17/05/2024
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: tc358743: registre el dispositivo asíncrono v4l2 solo después de una configuración exitosa Asegúrese de que el dispositivo se haya configurado correctamente antes de registrar el dispositivo asíncrono v4l2, permitiendo así el acceso al espacio de usuario.
  
• Vulnerabilidad en kernel de Linux (CVE-2024-35837)
  Severidad: MEDIA
  Fecha de publicación: 17/05/2024
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: mvpp2: borre el grupo de BM antes de la inicialización. El valor del registro persiste después de iniciar el kernel usando kexec, lo que genera pánico en el kernel. Por lo tanto, borre los registros del grupo BM antes de la inicialización para solucionar el problema.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-37949)
  Severidad: MEDIA
  Fecha de publicación: 20/05/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xenbus: Usar kref para rastrear el tiempo de vida de req. Marek informó haber visto un fallo de puntero nulo en la pila de llamadas xenbus_thread: ERROR: desreferencia de puntero nulo del kernel, dirección: 0000000000000000 RIP: e030:__wake_up_common+0x4c/0x180 Rastreo de llamadas: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0 process_msg+0x18e es req->cb(req). req->cb está configurado como xs_wake_up(), una envoltura ligera alrededor de wake_up(), o xenbus_dev_queue_reply(). Parece que en este caso era xs_wake_up(). Parece que req pudo haber despertado xs_wait_for_reply(), que liberó la solicitud. Cuando xenbus_thread se reanuda, falla en los datos con ceros. La segunda edición de los controladores de dispositivos de Linux indica: «Normalmente, una llamada wake_up puede provocar una reprogramación inmediata, lo que significa que otros procesos podrían ejecutarse antes de que wake_up regrese». ... lo cual coincidiría con el comportamiento observado. Se recomienda mantener dos krefs en cada solicitud: uno para el que realiza la llamada y otro para xenbus_thread. Cada uno ejecutará kref_put() al finalizar, y el último lo liberará. Este uso de kref coincide con la descripción en Documentation/core-api/kref.rst.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-37951)
  Severidad: MEDIA
  Fecha de publicación: 20/05/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Agregar trabajo a la lista de pendientes si se omitió el reinicio Cuando se agota el tiempo de espera de un trabajo CL/CSD, verificamos si la GPU ha progresado desde el último tiempo de espera. Si es así, en lugar de reiniciar el hardware, omitimos el reinicio y dejamos que el temporizador se reactive. Esto les da a los trabajos de larga ejecución la oportunidad de completarse. Sin embargo, cuando se llama a `timedout_job()`, el trabajo en cuestión se elimina de la lista de pendientes, lo que significa que no se liberará automáticamente a través de `free_job()`. En consecuencia, cuando omitimos el reinicio y mantenemos el trabajo en ejecución, el trabajo no se liberará cuando finalmente se complete. Esta situación conduce a una fuga de memoria, como se expone en [1] y [2]. De manera similar a el commit 704d3d60fec4 ("drm/etnaviv: no bloquee el programador cuando la GPU aún esté activa"), este parche garantiza que el trabajo se vuelva a colocar en la lista de pendientes al extender el tiempo de espera.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-37953)
  Severidad: MEDIA
  Fecha de publicación: 20/05/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sch_htb: hacer que htb_deactivate() sea idempotente. Alan informó una desreferencia de puntero NULL en htb_next_rb_node() después de que htb_qlen_notify() fuera idempotente. Resulta que en el siguiente caso introdujo alguna regresión: htb_dequeue_tree(): |-> fq_codel_dequeue() |-> qdisc_tree_reduce_backlog() |-> htb_qlen_notify() |-> htb_deactivate() |-> htb_next_rb_node() |-> htb_deactivate() Para htb_next_rb_node(), después de llamar al primer htb_deactivate(), el clprio[prio]->ptr podría estar ya establecido en NULL, lo que significa que htb_next_rb_node() es vulnerable aquí. Para htb_deactivate(), aunque verificamos qlen antes de llamarlo, en caso de qlen==0 después de qdisc_tree_reduce_backlog(), podemos llamarlo nuevamente, lo que activa la advertencia interna. Para solucionar estos problemas, necesitamos: 1) Hacer que htb_deactivate() sea idempotente, es decir, que simplemente regrese si ya lo llamamos. 2) Hacer que htb_next_rb_node() sea seguro contra ptr==NULL. Muchas gracias a Alan por las pruebas y por el reproductor.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38001)
  Severidad: MEDIA
  Fecha de publicación: 06/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: hfsc: Dirección de cola reentrante que añade clase a eltree dos veces. Savino afirma: "Les escribimos para informarles que este parche reciente (141d34391abbb315d68556b7c67ad97885407547) [1] se puede omitir, y aún puede producirse una UAF cuando se utiliza HFSC con NETEM. El parche solo comprueba el campo cl->cl_nactive para determinar si es la primera inserción o no [2], pero este campo solo se incrementa con init_vf [3]. Al usar HFSC_RSC (que utiliza init_ed) [4], es posible omitir la comprobación e insertar la clase dos veces en eltree. En condiciones normales, esto provocaría un bucle infinito en hfsc_dequeue por las razones que ya explicamos en este informe [5]. Sin embargo, si TBF se añade como qdisc raíz y es Configurado con una tasa muy baja, puede utilizarse para evitar que los paquetes se desencolan. Este comportamiento puede aprovecharse para realizar inserciones posteriores en el eltree de HFSC y provocar un UAF. Para solucionar tanto el UAF como el bucle infinito, con netem como elemento secundario de hfsc, compruebe explícitamente en hfsc_enqueue si la clase ya está en el eltree cuando se activa el indicador HFSC_RSC. [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38003)
  Severidad: MEDIA
  Fecha de publicación: 08/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: bcm: añadir protección de lectura rcu faltante para el contenido de procfs. Cuando se genera el contenido de procfs para un bcm_op que se va a eliminar, la salida de procfs podría mostrar datos no fiables (UAF). Dado que la eliminación de bcm_op ya está implementada con la gestión de rcu, este parche añade el rcu_read_lock() faltante y garantiza que las entradas de la lista se eliminen correctamente bajo la protección de rcu.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38004)
  Severidad: ALTA
  Fecha de publicación: 08/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: bcm: añadir bloqueo para actualizaciones en tiempo de ejecución de bcm_op El gestor de difusión CAN (CAN BCM) puede enviar una secuencia de tramas CAN a través de hrtimer. El contenido y también la longitud de la secuencia se pueden cambiar o reducir en tiempo de ejecución, donde el contador 'currframe' se establece entonces en cero. Aunque esto parecía ser una operación segura, las actualizaciones de 'currframe' se pueden activar desde el espacio de usuario y el contexto de hrtimer en bcm_can_tx(). Anderson Nascimento creó una prueba de concepto que activó un acceso de lectura fuera de los límites de KASAN slab que se puede prevenir con un spin_lock_bh. En la reelaboración de bcm_can_tx() la variable 'count' se ha movido a la sección protegida ya que esta variable también se puede modificar desde ambos contextos.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38005)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: ti: k3-udma: Agregar bloqueo faltante Los kernels recientes se quejan de un bloqueo faltante en k3-udma.c cuando el validador de bloqueo está habilitado: [ 4.128073] ADVERTENCIA: CPU: 0 PID: 746 en drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238 [ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 No contaminado 6.12.9-arm64 #28 [ 4.144867] Nombre del hardware: pp-v12 (DT) [ 4.148648] Cola de trabajo: eventos events udma_check_tx_completion [ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.160834] pc : udma_start.isra.0+0x34/0x238 [ 4.165227] lr : udma_start.isra.0+0x30/0x238 [ 4.169618] sp : ffffffc083cabcf0 [ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005 [ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000 [ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670 [ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030 [ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048 [ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001 [ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68 [ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8 [ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000 [ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000 [ 4.244986] Call trace: [ 4.247463] udma_start.isra.0+0x34/0x238 [ 4.251509] udma_check_tx_completion+0xd0/0xdc [ 4.256076] process_one_work+0x244/0x3fc [ 4.260129] process_scheduled_works+0x6c/0x74 [ 4.264610] worker_thread+0x150/0x1dc [ 4.268398] kthread+0xd8/0xe8 [ 4.271492] ret_from_fork+0x10/0x20 [ 4.275107] irq event stamp: 220 [ 4.278363] hardirqs last enabled at (219): [] _raw_spin_unlock_irq+0x38/0x50 [ 4.287183] hardirqs last disabled at (220): [] el1_dbg+0x24/0x50 [ 4.294879] softirqs last enabled at (182): [] handle_softirqs+0x1c0/0x3cc [ 4.303437] softirqs last disabled at (177): [] __do_softirq+0x1c/0x28 [ 4.311559] ---[ fin del seguimiento 0000000000000000 ]--- Esta confirmación agrega el bloqueo faltante.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38007)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: uclogic: Añadir comprobación de valores NULL en uclogic_input_configured(). Devm_kasprintf() devuelve NULL cuando falla la asignación de memoria. Actualmente, uclogic_input_configured() no comprueba este caso, lo que provoca una desreferencia de puntero NULL. Añadir comprobación de valores NULL después de devm_kasprintf() para evitar este problema.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38009)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: deshabilitar NAPI al eliminar el controlador. Una advertencia al eliminar el controlador comenzó a aparecer después de el commit 9dd05df8403b ("net: advertir si la instancia de NAPI no se apagó"). Desactive la transacción NAPI antes de eliminarla en mt76_dma_cleanup(). ADVERTENCIA: CPU: 4 PID: 18828 en net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe No contaminado 6.15.0-rc4 #4 PREEMPT(lazy) Nombre del hardware: Nombre del producto del sistema ASUS/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Rastreo de llamadas: mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Se probó con mt7921e, pero el mismo patrón se puede aplicar a otros controladores mt76 que invoquen mt76_dma_cleanup() durante la eliminación. Tx napi está habilitado en sus funciones *_dma_init() y solo se activa y desactiva dentro de sus rutas de suspensión/reinicio/reinicio. Por lo tanto, debería ser aceptable deshabilitar tx napi de forma genérica. Encontrado por el Centro de Verificación de Linux (linuxtesting.org).
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38015)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: idxd: se corrige una fuga de memoria en la ruta de gestión de errores de idxd_alloc. La memoria asignada a idxd no se libera si se produce un error durante idxd_alloc(). Para solucionarlo, libere la memoria asignada en orden inverso a la asignación antes de salir de la función en caso de error.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38018)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/tls: corrección del pánico del kernel cuando alloc_page falla. No se puede establecer frag_list como un puntero nulo cuando alloc_page falla. Se usará en tls_strp_check_queue_ok la próxima vez que se invoque tls_strp_read_sock. Esto se debe a que no se restablece full_len en tls_strp_flush_anchor_copy(), por lo que la ruta de recepción intentará continuar gestionando el registro parcial en la siguiente llamada, pero se ha desvinculado el rcvq de la lista de fragmentos. Una solución alternativa sería restablecer full_len. No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000028 Rastreo de llamadas: tls_strp_check_rcv+0x128/0x27c tls_strp_data_ready+0x34/0x44 tls_data_ready+0x3c/0x1f0 tcp_data_ready+0x9c/0xe4 tcp_data_queue+0xf6c/0x12d0 tcp_rcv_established+0x52c/0x798
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38020)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Deshabilitar la descarga de MACsec para el perfil de representante de enlace ascendente. La descarga de MACsec no es compatible con el modo switchdev para los representantes de enlace ascendente. Al cambiar al perfil de representante de enlace ascendente, se debe desactivar la función de descarga de MACsec de las características del dispositivo de red. Si se deja activada, los intentos de agregar descargas resultan en una desreferencia de puntero nulo, ya que el representante de enlace ascendente no admite la descarga de MACsec, aunque el bit de característica permanezca activado. Desactive NETIF_F_HW_MACSEC en mlx5e_fix_uplink_rep_features(). Registro del núcleo: Ups: fallo de protección general, probablemente para dirección no canónica 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref en el rango [0x000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip No contaminado 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x128/0x1dd0 Código: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 000000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: fffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 00000000000000000 R12: 00000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Rastreo de llamadas: ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38023)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs: fallo en el manejo de nfs_get_lock_context en la ruta de desbloqueo. Cuando la memoria es insuficiente, la asignación de nfs_lock_context en nfs_get_lock_context() falla y devuelve -ENOMEM. Si por error tratamos una estructura nfs4_unlockdata (cuyo miembro l_ctx se ha establecido en -ENOMEM) como válida y procedemos a ejecutar rpc_run_task(), se activará una desreferencia de puntero NULL en nfs4_locku_prepare. Por ejemplo: ERROR: desreferencia de puntero NULL del núcleo, dirección: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpc_async_schedule RIP: 0010:nfs4_locku_prepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in: CR2: 000000000000000c [ fin de seguimiento 0000000000000000 ]--- Libera el nfs4_unlockdata asignado cuando nfs_get_lock_context() falla y devuelve NULL para finalizar la rpc_run_task posterior, lo que evita la desreferencia del puntero NULL.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38024)
  Severidad: ALTA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rxe: Corrección del error de lectura slab-use-after-free en rxe_queue_cleanup Seguimiento de llamadas: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f En la función rxe_create_cq, cuando rxe_cq_from_init falla, se llamará a la función rxe_cleanup para gestionar los recursos asignados. De hecho, ya se han liberado algunos recursos de memoria en la función rxe_cq_from_init. Por lo tanto, se producirá este problema. La solución es dejar que rxe_cleanup haga todo el trabajo.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38034)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corregir el orden de los argumentos prelim_ref en btrfs__prelim_ref. btrfs_prelim_ref() llama a las variables de referencia antiguas y nuevas en un orden incorrecto. Esto provoca una desreferencia de puntero nulo, ya que oldref se pasa como nulo a trace_btrfs_prelim_ref_insert(). Tenga en cuenta que trace_btrfs_prelim_ref_insert() se llama con newref como oldref (y oldref como nulo) a propósito para imprimir los valores de newref. Para reproducir: echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable. Realice algunas operaciones de escritura diferida. Backtrace: BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000018 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress No contaminado 6.15.0-rc2-tester+ #47 PREEMPT(voluntario) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 01/04/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Código: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 CR2: 000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Rastreo de llamadas: prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38035)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet-tcp: no restaurar el valor nulo de sk_state_change. La función queue->state_change se configura como parte de nvmet_tcp_set_queue_sock(), pero si la conexión TCP no se establece al llamar a nvmet_tcp_set_queue_sock(), la función queue->state_change no se configura y la función sock->sk->sk_state_change no se reemplaza. Por lo tanto, no es necesario restaurar sock->sk->sk_state_change si la función queue->state_change es nula. Esto evita desreferencias de puntero NULL como esta: [ 286.462026][ C0] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000000 [ 286.462814][ C0] #PF: obtención de instrucción de supervisor en modo núcleo [ 286.463796][ C0] #PF: error_code(0x0010) - página no presente [ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0 [ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI [ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme No contaminado 6.15.0-rc2+ #11 PREEMPT(voluntario) [ 286.466393][ C0] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 01/04/2014 [ 286.467147][ C0] RIP: 0010:0x0 [ 286.467420][ C0] Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. [ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246 [ 286.468425][ C0] RAX: 000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43 [ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 000000000000008 RDI: ffff88813fd34100 [ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c [ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3 [ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268 [ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000 [ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0 [ 286.473500][ C0] DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 [ 286.474467][C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 286.475453][ C0] Rastreo de llamadas: [ 286.476102][ C0] [ 286.476719][ C0] tcp_fin+0x2bb/0x440 [ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60 [ 286.478174][ C0] ? __build_skb_around+0x234/0x330 [ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10 [ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0 [ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30 [ 286.482769][ C0] ? ktime_get+0x66/0x150 [ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050 [ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0 [ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10 [ 286.486917][ C0] ? lock_release+0x217/0x2c0 [ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0 [ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30 [ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0 [ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10 [ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10 [ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack] [ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0 [ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370 [ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420 [ 286.494268][ C0] ip_local_deliver+0x168/0x430 [ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10 [ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10 [ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20 [ 286.496806][ C0] ? lock_release+0x217/0x2c0 [ 286.497414][ C0] ip_rcv+0x455/0x6e0 [ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10 ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38043)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_ffa: Establecer dma_mask para dispositivos ffa Establecer dma_mask para dispositivos FFA, de lo contrario la asignación de DMA mediante el puntero del dispositivo genera la siguiente advertencia: ADVERTENCIA: CPU: 1 PID: 1 en kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38044)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: cx231xx: se estableció device_caps para 417. El dispositivo de video del codificador MPEG no estableció device_caps. Añada esto; de lo contrario, el dispositivo de video no se podrá registrar (en su lugar, se obtendrá un WARN_ON). No se había observado antes, ya que la compatibilidad con 417 está deshabilitada, pero lo encontré al experimentar con él.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38048)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_ring: corrige la ejecución de datos etiquetando event_triggered como racy para KCSAN syzbot informa una ejecución de datos al acceder a event_triggered, aquí está la pila simplificada cuando ocurrió el problema: ===================================================================== ERROR: KCSAN: ejecución de datos en virtqueue_disable_cb / virtqueue_enable_cb_delayed escribe en 0xffff8881025bc452 de 1 byte por la tarea 3288 en la CPU 0: virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264 __netdev_start_xmit include/linux/netdevice.h:5151 [en línea] netdev_start_xmit include/linux/netdevice.h:5160 [en línea] xmit_one net/core/dev.c:3800 [en línea] lectura a 0xffff8881025bc452 de 1 byte por interrupción en la CPU 1: virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [en línea] virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566 skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158 handle_irq_event_percpu kernel/irq/handle.c:193 [inline] valor cambiado: 0x01 -> 0x00 ===================================================================== Cuando ocurre la ejecución de datos, la función virtqueue_enable_cb_delayed() establece event_triggered en falso, y virtqueue_disable_cb_split/packed() lo lee como falso debido a la condición de ejecución. Dado que event_triggered es una indicación poco fiable utilizada para la optimización, esto solo debería provocar que el controlador sugiera temporalmente que el dispositivo no envíe una notificación de interrupción cuando se utilice el índice de evento. Solucione este problema de ejecución de datos informado por KCSAN etiquetando explícitamente el acceso como data_racy.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38051)
  Severidad: ALTA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: Se corrige el use-after-free en cifs_fill_dirent Hay una condición de ejecución en el proceso de concurrencia readdir, que puede acceder al búfer rsp después de que se haya liberado, lo que activa la siguiente advertencia KASAN. ======================================================================== ERROR: KASAN: slab-use-after-free en cifs_fill_dirent+0xb03/0xb60 [cifs] Lectura de tamaño 4 en la dirección ffff8880099b819c por la tarea a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out No contaminado 6.15.0-rc6+ #240 PREEMPT(full) Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e La dirección con errores pertenece al objeto en ffff8880099b8000 que pertenece a la caché cifs_request de tamaño 16588 La dirección con errores se encuentra a 412 bytes dentro de la región liberada de 16588 bytes [ffff8880099b8000, ffff8880099bc0cc) La dirección con errores pertenece a la página física: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== La prueba de concepto (POC) está disponible en el enlace [1]. El proceso que desencadena el problema es el siguiente: Proceso 1 Proceso 2 ----------------------------------- ---truncado---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38052)
  Severidad: ALTA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/tipc: corrección de lectura slab-use-after-free en tipc_aead_encrypt_done Syzbot informó de una lectura slab-use-after-free con el siguiente seguimiento de llamada: ======================================================================= ERROR: KASAN: slab-use-after-free en tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Lectura de tamaño 8 en la dirección ffff88807a733000 por la tarea kworker/1:0/25 Seguimiento de llamada: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Asignado por la tarea 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Liberado por la tarea 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Después de liberar la transacción tipc_crypto al eliminar el espacio de nombres, tipc_aead_encrypt_done aún puede visitarla en cryptd_queue_worker workqueue. Reproduzco este problema mediante: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disabled media eth dev veth1 ip netns del ns1 La clave de reproducción es que simd_aead_encrypt se interrumpe, lo que lleva a que crypto_simd_usable() devuelva falso. Por lo tanto, se activa cryptd_queue_worker y se visita la transacción tipc_crypto. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // cifrar() simd_aead_encrypt // crypto_simd_usable() es falso child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // cifrar() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // desencadenador cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work) Solucione esto manteniendo el recuento de referencias de red antes de cifrar.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38063)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm: se corrige la limitación de E/S incondicional causada por REQ_PREFLUSH Cuando se envía una biografía con REQ_PREFLUSH a dm, __send_empty_flush() genera una flush_bio con REQ_OP_WRITE | REQ_PREFLUSH | REQ_SYNC, lo que hace que wbt_wait() limite la flush_bio. Un ejemplo de v5.4, también existe un problema similar en upstream: crash> bt 2091206 PID: 2091206 TAREA: ffff2050df92a300 CPU: 109 COMANDO: "kworker/u260:0" #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4 #10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs] #11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs] #12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs] #13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs] #14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs] #15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs] #16 [ffff800084a2fdb0] process_one_work at ffff800040111d08 #17 [ffff800084a2fe00] worker_thread at ffff8000401121cc #18 [ffff800084a2fe70] kthread at ffff800040118de4. Tras el commit 2def2845cc33 ("xfs: no permitir la limitación de la E/S del registro"), los metadatos enviados por xlog_write_iclog() no deberían limitarse. Sin embargo, debido a la existencia de la capa dm, limitar la ejecución de flush_bio provoca indirectamente la limitación de los metadatos bio. Solucione esto agregando condicionalmente REQ_IDLE a flush_bio.bi_opf, lo que hace que wbt_should_throttle() devuelva falso para evitar wbt_wait().
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38065)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: orangefs: No truncar el tamaño del archivo. 'len' se utiliza para almacenar el resultado de i_size_read(), por lo que hacer que 'len' sea un size_t da como resultado un truncamiento a 4 GiB en sistemas de 32 bits.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38066)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm cache: impide BUG_ON bloqueando los reintentos en reinicios de dispositivos fallidos. Un dispositivo de caché que no se reanuda debido a errores de mapeo no debe reintentarse, ya que el fallo deja un objeto de política parcialmente inicializado. Repetir la operación de reanudación corre el riesgo de activar BUG_ON al recargar los mapeos de caché en el objeto de política incompleto. Reproducir los pasos: 1. Crear metadatos de caché que consten de 512 o más bloques de caché, con algunos mapeos almacenados en el primer bloque de la matriz de mapeo. Aquí usamos cache_restore v1.0 para generar los metadatos. cat <<> cmeta.xml EOF dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta 2. wipe the second array block of the mapping array to simulate data degradations. mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock 3. try bringing up the cache device. The resume is expected to fail due to the broken array block. dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dmsetup create cache --notable dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup resume cache 4. Intente reanudar la caché de nuevo. Se activa un BUG_ON inesperado al cargar las asignaciones de caché. dmsetup resume cache Registros del kernel: (snip) ------------[ cortar aquí ]------------ ¡ERROR del kernel en drivers/md/dm-cache-policy-smq.c:752! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup No contaminado 6.13.4 #3 RIP: 0010:smq_load_mapping+0x3e5/0x570 Se soluciona no permitiendo operaciones de reanudación para dispositivos que fallaron en el intento inicial.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38067)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rseq: Arreglar violación de segmentación en el registro cuando rseq_cs no es cero El campo rseq_cs está documentado como establecido a 0 por el espacio de usuario antes del registro, sin embargo esto no es aplicado actualmente por el kernel. Esto puede resultar en una violación de segmentación al regresar al espacio de usuario si el valor almacenado en el campo rseq_cs no apunta a una estructura rseq_cs válida. La solución correcta para esto sería fallar el registro de rseq cuando el campo rseq_cs no es cero. Sin embargo, algunas versiones anteriores de glibc reutilizarán el área rseq de subprocesos anteriores sin borrar el campo rseq_cs y también terminarán el proceso si el registro de rseq falla en un subproceso secundario. Esto no fue detectado en las pruebas porque en este caso el rseq_cs restante apunta a una estructura rseq_cs válida. Lo que podemos hacer es borrar el campo rseq_cs durante el registro cuando no sea cero, lo que evitará errores de segmentación en el registro y no dañará las versiones de glibc que reutilizan áreas rseq en la creación de subprocesos.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38068)
  Severidad: ALTA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: lzo - Corrección de saturación del búfer de compresión. A diferencia del código de descompresión, el código de compresión de LZO nunca verifica si hay saturaciones de salida. En su lugar, asume que quien llama siempre proporciona suficiente espacio en el búfer, sin tener en cuenta la longitud del búfer proporcionada por él. Se ha añadido una interfaz de compresión segura que verifica el final del búfer antes de cada escritura. Se ha utilizado la interfaz segura en crypto/lzo.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38071)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/mm: Verificar el valor de retorno de memblock_phys_alloc_range(). Al menos con CONFIG_PHYSICAL_START=0x100000, si hay < 4 MiB de memoria libre contigua disponible en este punto, el kernel se bloqueará porque memblock_phys_alloc_range() devuelve 0 en caso de fallo, lo que provoca que memblock_phys_free() descarte los primeros 4 MiB de memoria física. Como mínimo, debería fallar correctamente con un diagnóstico significativo, pero de hecho todo parece funcionar correctamente sin la extraña asignación de reserva.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38072)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: libnvdimm/labels: Corregir error de división en nd_label_data_init() Si un dispositivo de memoria CXL defectuoso devuelve un tamaño LSA cero roto en su información de dispositivo de memoria (Identificar dispositivo de memoria (Opcode 4000h), especificación CXL 3.1, 8.2.9.9.1.1), se produce un error de división en el controlador libnvdimm: Oops: error de división: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm] Código y flujo: 1) El comando CXL 4000h devuelve tamaño LSA = 0 2) config_size se asigna a tamaño LSA cero (controlador pmem CXL): drivers/cxl/pmem.c: .config_size = mds->lsa_size, 3) max_xfer se establece en cero (controlador nvdimm): drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size); 4) Un DIV_ROUND_UP() posterior provoca una división por cero: drivers/nvdimm/label.c: /* Hacer que nuestro tamaño de lectura inicial sea un múltiplo del tamaño max_xfer */ drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size); Solucione esto comprobando el parámetro de tamaño de configuración extendiendo una comprobación existente.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38074)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vhost-scsi: proteger vq->log_used con vq->mutex La ruta de finalización de vhost-scsi puede acceder a vq->log_base cuando vq->log_used ya está configurado como falso. vhost-thread QEMU-thread vhost_scsi_complete_cmd_work() -> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU deshabilita vq->log_used mediante VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex); QEMU gfree(vq->log_base) log_used() -> log_write(vq->log_base) Suponiendo que el VMM es QEMU. La ruta vq->log_base proviene del espacio de usuario de QEMU y se puede recuperar mediante gfree(). Como resultado, esto provoca escrituras de memoria no válidas en el espacio de usuario de QEMU. La ruta de la cola de control presenta el mismo problema.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38077)
  Severidad: ALTA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86: dell-wmi-sysman: Evitar el desbordamiento de búfer en current_password_store(). Si la matriz 'buf' recibida del usuario contiene una cadena vacía, la variable 'length' será cero. Acceder al elemento de la matriz 'buf' con el índice 'length - 1' provocará un desbordamiento de búfer. Se ha añadido una comprobación para cadenas vacías. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38078)
  Severidad: MEDIA
  Fecha de publicación: 18/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: Corrección de la ejecución de acceso al búfer en la capa PCM OSS. La capa PCM OSS intenta borrar el búfer con los datos de silencio durante la inicialización (o reconfiguración) de un flujo mediante la llamada explícita a snd_pcm_format_set_silence() con runtime->dma_area. Sin embargo, esto puede generar una UAF, ya que el acceso a runtime->dma_area podría liberarse simultáneamente, ya que se realiza fuera de las operaciones PCM. Para evitarlo, mueva el código al núcleo PCM y ejecútelo dentro del bloqueo de acceso al búfer, de modo que no se modifique durante la operación.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38088)
  Severidad: ALTA
  Fecha de publicación: 30/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/powernv/memtrace: Se solucionó un problema de sobreexceso de los límites en memtrace mmap. Este parche corrige este problema comprobando que el tamaño de la región de mapeo solicitada se mantenga dentro del tamaño de la región asignada.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38090)
  Severidad: MEDIA
  Fecha de publicación: 30/06/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers/rapidio/rio_cm.c: impide la posible sobrescritura del montón. En riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send(), cm_chan_msg_send() comprueba que el espacio de usuario no haya enviado demasiados datos, pero riocm_ch_send() no pudo comprobar que el espacio de usuario enviara datos suficientes. El resultado es que riocm_ch_send() puede escribir en campos del rio_ch_chan_hdr que estaban fuera de los límites del espacio que cm_chan_msg_send() asignó. Solucione esto enseñándole a riocm_ch_send() que compruebe que todo el rio_ch_chan_hdr se copió desde el espacio de usuario.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38112)
  Severidad: MEDIA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: Se solucionó el problema de TOCTOU en sk_is_readable(). sk->sk_prot->sock_is_readable es un puntero a función válido cuando sk reside en un mapa de sockets. Tras el último sk_psock_put() (que suele ocurrir al eliminar un socket de un mapa de sockets), sk->sk_prot se restaura y sk->sk_prot->sock_is_readable se convierte en NULL. Esto hace que sk_is_readable() sea arriesgado si el valor de sk->sk_prot se recarga después de la comprobación inicial. Esto, a su vez, puede provocar una desreferencia de puntero nulo. Asegúrese de que el puntero a función no se convierta en NULL después de la comprobación.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38113)
  Severidad: MEDIA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: CPPC: Se corrige la desreferencia de punteros nulos al usar nosmp. Con nosmp en la línea de comandos, no se inician otras CPU, dejando su cpc_desc_ptr en NULL. La iteración de la CPU0 mediante for_each_possible_cpu() desreferencia estos punteros nulos, lo que provoca pánico. Seguimiento de pánico: [0.401123] No se puede gestionar la desreferencia de punteros nulos del kernel en la dirección virtual 0000000000000b8 ... [0.403255] [] cppc_allow_fast_switch+0x6a/0xd4 ... Pánico del kernel: no se sincroniza: ¡Se intentó detener la inicialización! [rjw: Nuevo asunto]
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38115)
  Severidad: MEDIA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: sch_sfq: se corrige un posible fallo en la gestión de gso_skb. SFQ asume que siempre puede poner en cola al menos un paquete. Sin embargo, tras la confirmación responsable, sch->q.len puede inflarse con paquetes en sch->gso_skb, y una operación enqueue() en una qdisc SFQ vacía puede ir seguida de un descarte inmediato. Corrija sfq_drop() para que borre correctamente q->tail en esta situación. ip netns add lb ip link add dev to-lb type veth peer name in-lb netns lb ethtool -K to-lb tso off # force qdisc to requeue gso_skb ip netns exec lb ethtool -K in-lb gro on # enable NAPI ip link set dev to-lb up ip -netns lb link set dev in-lb up ip addr add dev to-lb 192.168.20.1/24 ip -netns lb addr add dev in-lb 192.168.20.2/24 tc qdisc replace dev to-lb root sfq limit 100 ip netns exec lb netserver netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 & netperf -H 192.168.20.2 -l 100 &
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38118)
  Severidad: ALTA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: MGMT: Reparar UAF en mgmt_remove_adv_monitor_complete Esto reelabora MGMT_OP_REMOVE_ADV_MONITOR para que no use mgmt_pending_add para evitar fallos como los siguientes: ===================================================================== ERROR: KASAN: slab-use-after-free en mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 Lectura de tamaño 8 en la dirección ffff88801c53f318 por la tarea kworker/u5:5/5341 CPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 No contaminado 6.15.0-syzkaller-10402-g4cb6c8af8591 #0 PREEMPT(full) Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Cola de trabajo: hci0 hci_cmd_sync_work Rastreo de llamadas: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 hci_cmd_sync_work+0x261/0x3a0 net/bluetooth/hci_sync.c:334 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 5987: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x240 net/bluetooth/mgmt_util.c:252 mgmt_pending_add+0x34/0x120 net/bluetooth/mgmt_util.c:279 remove_adv_monitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x548/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5989: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2380 [inline] slab_free mm/slub.c:4642 [inline] kfree+0x18e/0x440 mm/slub.c:4841 mgmt_pending_foreach+0xc9/0x120 net/bluetooth/mgmt_util.c:242 mgmt_index_removed+0x10d/0x2f0 net/bluetooth/mgmt.c:9366 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314 __sys_bind_socket net/socket.c:1810 [inline] __sys_bind+0x2c3/0x3e0 net/socket.c:1841 __do_sys_bind net/socket.c:1846 [inline] __se_sys_bind net/socket.c:1844 [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1844 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38119)
  Severidad: MEDIA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: ufs: Se corrige un bloqueo en el gestor de errores cuando ufshcd_err_handling_prepare() invoca ufshcd_rpm_get_sync(). Esta última función solo funciona correctamente si UFSHCD_EH_IN_PROGRESS no está configurado, ya que la reanudación implica el envío de un comando SCSI y ufshcd_queuecommand() devuelve SCSI_MLQUEUE_HOST_BUSY si UFSHCD_EH_IN_PROGRESS está configurado. Para solucionar este bloqueo, configure UFSHCD_EH_IN_PROGRESS después de invocar ufshcd_rpm_get_sync() en lugar de antes. Rastreo inverso: __switch_to+0x174/0x338 __schedule+0x600/0x9e4 schedule+0x7c/0xe8 schedule_timeout+0xa4/0x1c8 io_schedule_timeout+0x48/0x70 wait_for_common_io+0xa8/0x160 //waiting on START_STOP wait_for_completion_io_timeout+0x10/0x20 blk_execute_rq+0xe4/0x1e4 scsi_execute_cmd+0x108/0x244 ufshcd_set_dev_pwr_mode+0xe8/0x250 __ufshcd_wl_resume+0x94/0x354 ufshcd_wl_runtime_resume+0x3c/0x174 scsi_runtime_resume+0x64/0xa4 rpm_resume+0x15c/0xa1c __pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing ufshcd_err_handler+0x1a0/0xd08 process_one_work+0x174/0x808 worker_thread+0x15c/0x490 kthread+0xf4/0x1ec ret_from_fork+0x10/0x20 [ bvanassche: se reescribió la descripción del parche ]
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38120)
  Severidad: MEDIA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_set_pipapo_avx2: corrección del relleno inicial del mapa. Si el primer campo no cubre todo el mapa inicial, debemos poner a cero el resto; de lo contrario, filtraremos esos bits al mapa de la siguiente ronda de coincidencia. La corrección inicial estaba incompleta y solo corrigió la implementación genérica de C. Un parche posterior añade un caso de prueba a nft_concat_range.sh.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38122)
  Severidad: MEDIA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gve: se ha añadido la comprobación de valores nulos (NULL) faltante para gve_alloc_pending_packet() en TX DQO. gve_alloc_pending_packet() puede devolver valores nulos (NULL), pero gve_tx_add_skb_dqo() no los comprobaba antes de desreferenciar el puntero devuelto. Se ha añadido una comprobación de valores nulos (NULL) faltante para evitar una posible desreferencia de punteros nulos cuando falla la asignación. Esto mejora la robustez en escenarios con poca memoria.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38124)
  Severidad: MEDIA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fix udp gso skb_segment after pull from frag_list. El commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from frag_list") detectó una geometría no válida en los skbs de frag_list y los redirige de skb_segment_list a un skb_segment más robusto. Sin embargo, algunos paquetes con geometría modificada también pueden presentar errores en ese código. Desconocemos cuántos casos de este tipo existen. Abordar cada uno por separado también requiere modificar el complejo código de skb_segment, lo que podría introducir errores en otros tipos de skbs. En su lugar, se linealizan todos los paquetes que no cumplen con las invariantes básicas en los skbs de fraglist gso. Esto es más robusto. Si solo se extrae una parte de el payload de fraglist en head_skb, siempre se generará una excepción al dividir los skbs por skb_segment. Para obtener información detallada de la pila de llamadas, consulte a continuación. SKB_GSO_FRAGLIST skbs válidos: constan de dos o más segmentos: head_skb contiene los encabezados de protocolo más el primer gso_size: uno o más frag_list skbs contienen exactamente un segmento; todos, excepto el último, deben ser gso_size Los ganchos de ruta de datos opcionales, como NAT y BPF (bpf_skb_pull_data), pueden modificar fraglist skbs, rompiendo estos invariantes. En casos extremos, extraen una parte de los datos en skb lineal. Para UDP, esto hace que se extraigan tres payloads con longitudes de (11,11,10) bytes para convertirse en (12,10,10) bytes. El skbs ya no cumple con las condiciones SKB_GSO_FRAGLIST anteriores porque el payload se extrajo en head_skb; debe linealizarse antes de pasarse a skb_segment regular. skb_segment+0xcd0/0xd14 __udp_gso_segment+0x334/0x5f4 udp4_ufo_fragment+0x118/0x15c inet_gso_segment+0x164/0x338 skb_mac_gso_segment+0xc4/0x13c __skb_gso_segment+0xc4/0x124 validate_xmit_skb+0x9c/0x2c0 validate_xmit_skb_list+0x4c/0x80 sch_direct_xmit+0x70/0x404 __dev_queue_xmit+0x64c/0xe5c neigh_resolve_output+0x178/0x1c4 ip_finish_output2+0x37c/0x47c __ip_finish_output+0x194/0x240 ip_finish_output+0x20/0xf4 ip_output+0x100/0x1a0 NF_HOOK+0xc4/0x16c ip_forward+0x314/0x32c ip_rcv+0x90/0x118 __netif_receive_skb+0x74/0x124 process_backlog+0xe8/0x1a4 __napi_poll+0x5c/0x1f8 net_rx_action+0x154/0x314 handle_softirqs+0x154/0x4b8 [118.376811] [C201134] rxq0_pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0_pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0_pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0_pus: [name:mrdump&]PHYS_OFFSET: 0x40000000 [118.470827] [C201134] rxq0_pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0_pus: [name:mrdump&]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14 [118.470900] [C201134] rxq0_pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14 [118.470928] [C201134] rxq0_pus: [name:mrdump&]sp : ffffffc008013770
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38126)
  Severidad: MEDIA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: asegúrese de que ptp_rate no sea 0 antes de configurar el sellado de tiempo. Los controladores de la plataforma stmmac que no incluyen en código abierto el valor clk_ptp_rate tras obtener el predeterminado del árbol de dispositivos pueden terminar con 0 en clk_ptp_rate (ya que clk_get_rate puede devolver 0). Esto se propagará hasta la inicialización de PTP al iniciar la interfaz, lo que provocará una división por 0: División por cero en el kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 No contaminado 6.12.30-00001-g48313bd5768a #22 Nombre del hardware: STM32 (Compatibilidad con árbol de dispositivos) Rastreo de llamadas: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8) Evite esta división por 0 sumando Una comprobación explícita y un registro de errores sobre el problema. Mientras tanto, elimine la misma comprobación de stmmac_ptp_register, que se convierte en un duplicado.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38131)
  Severidad: ALTA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: coresight: impide la desactivación de la configuración activa al habilitarla. Al habilitar la configuración activa mediante cscfg_csdev_enable_active_config(), esta podría desactivarse mediante la interfaz sysfs de configfs. Esto podría generar un problema de UAF en el siguiente escenario: CPU0 CPU1 (habilitación sysfs) carga el módulo cscfg_load_config_sets() activa la configuración. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) // aquí carga la configuración activada por CPU1 unlock(csdev->cscfg_csdev_lock) desactiva la configuración // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() descarga el módulo // acceso a config_desc que se liberó // mientras se descargaba el módulo. cscfg_csdev_enable_config Para solucionar esto, utilice active_cnt de cscfg_config_desc como un recuento de referencia que se mantendrá cuando: - active la configuración. - habilite la configuración activada y coloque la referencia del módulo cuando config_active_cnt == 0.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38135)
  Severidad: MEDIA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: Se corrige la posible desreferencia de puntero nulo en mlb_usio_probe(). devm_ioremap() puede devolver NULL en caso de error. Actualmente, mlb_usio_probe() no verifica este caso, lo que podría provocar una desreferencia de puntero NULL. Agregue una comprobación de NULL después de devm_ioremap() para evitar este problema.
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38136)
  Severidad: MEDIA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: renesas_usbhs: Reordenar el manejo del reloj y la administración de energía en la sonda Reordenar la secuencia de inicialización en `usbhs_probe()` para habilitar PM en tiempo de ejecución antes de acceder a los registros, lo que evita posibles fallos debido a relojes no inicializados. Actualmente, en la ruta de la sonda, se accede a los registros antes de habilitar los relojes, lo que lleva a un aborto externo síncrono en el SoC RZ/V2H. El flujo de llamada problemático es el siguiente: usbhs_probe() usbhs_sys_clock_ctrl() usbhs_bset() usbhs_write() iowrite16() <-- Acceso a registros antes de habilitar los relojes Dado que `iowrite16()` se realiza sin garantizar que los relojes requeridos estén habilitados, esto puede llevar a errores de acceso. Para solucionar esto, habilite el tiempo de ejecución de PM temprano en la función de sonda y asegúrese de que los relojes se adquieran antes del acceso al registro, lo que evita fallos como el siguiente en RZ/V2H: [13.272640] Error interno: aborto externo síncrono: 0000000096000010 [#1] PREEMPT SMP [13.280814] Módulos vinculados: cec renesas_usbhs(+) drm_kms_helper fuse drm backlight ipv6 [13.289088] CPU: 1 UID: 0 PID: 195 Comm: (udev-worker) Not tainted 6.14.0-rc7+ #98 [13.296640] Nombre del hardware: Renesas RZ/V2H EVK Board based on r9a09g057h44 (DT) [13.303834] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [13.310770] pc : usbhs_bset+0x14/0x4c [renesas_usbhs] [13.315831] lr : usbhs_probe+0x2e4/0x5ac [renesas_usbhs] [13.321138] sp : ffff8000827e3850 [13.324438] x29: ffff8000827e3860 x28: 0000000000000000 x27: ffff8000827e3ca0 [13.331554] x26: ffff8000827e3ba0 x25: ffff800081729668 x24: 0000000000000025 [13.338670] x23: ffff0000c0f08000 x22: 0000000000000000 x21: ffff0000c0f08010 [13.345783] x20: 0000000000000000 x19: ffff0000c3b52080 x18: 00000000ffffffff [13.352895] x17: 000000000000000 x16: 000000000000000 x15: ffff8000827e36ce [13.360009] x14: 00000000000003d7 x13: 000000000000003d7 x12: 0000000000000000 [13.367122] x11: 0000000000000000 x10: 0000000000000aa0 x9: ffff8000827e3750 [13.374235] x8: ffff0000c1850b00 x7: 0000000003826060 x6: 000000000000001c [13.381347] x5 : 000000030d5fcc00 x4 : ffff8000825c0000 x3 : 0000000000000000 [13.388459] x2 : 0000000000000400 x1 : 0000000000000000 x0 : ffff0000c3b52080 [13.395574] Rastreo de llamadas: [13.398013] usbhs_bset+0x14/0x4c [renesas_usbhs] (P) [13.403076] platform_probe+0x68/0xdc [13.406738] really_probe+0xbc/0x2c0 [13.410306] __driver_probe_device+0x78/0x120 [13.414653] driver_probe_device+0x3c/0x154 [13.418825] __driver_attach+0x90/0x1a0 [13.422647] bus_for_each_dev+0x7c/0xe0 [13.426470] driver_attach+0x24/0x30 [13.430032] bus_add_driver+0xe4/0x208 [13.433766] driver_register+0x68/0x130 [13.437587] __platform_driver_register+0x24/0x30 [13.442273] renesas_usbhs_driver_init+0x20/0x1000 [renesas_usbhs] [13.448450] do_one_initcall+0x60/0x1d4 [13.452276] do_init_module+0x54/0x1f8 [13.456014] load_module+0x1754/0x1c98 [13.459750] init_module_from_file+0x88/0xcc [13.464004] __arm64_sys_finit_module+0x1c4/0x328 [13.468689] invoke_syscall+0x48/0x104 [13.472426] el0_svc_common.constprop.0+0xc0/0xe0 [13.477113] do_el0_svc+0x1c/0x28 [13.480415] el0_svc+0x30/0xcc [13.483460] el0t_64_sync_handler+0x10c/0x138 [13.487800] el0t_64_sync+0x198/0x19c [13.491453] Code: 2a0103e1 12003c42 12003c63 8b010084 (79400084) [13.497522] ---[ fin de seguimiento 0000000000000000 ]---
  
• Vulnerabilidad en kernel de Linux (CVE-2025-38138)
  Severidad: MEDIA
  Fecha de publicación: 03/07/2025
  Fecha de última actualización: 17/12/2025
  En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: ti: Añadir comprobación de valores NULL en udma_probe(). Devm_kasprintf() devuelve NULL cuando falla la asignación de memoria. Actualmente, udma_probe() no comprueba este caso, lo que provoca una desreferencia de puntero NULL. Añadir comprobación de valores NULL después de devm_kasprintf() para evitar este problema.