Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/imx/tve: solución a la fuga de dispositivo de sondeo<br /> <br /> Asegúrese de liberar la referencia tomada al dispositivo DDC durante el sondeo en caso de fallo del sondeo (p. ej., aplazamiento del sondeo) y al desvincular el controlador.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bonding: corrige el uso después de liberación debido a un fallo de enslave después de la actualización del array de esclavos<br /> <br /> Corrige un uso después de liberación que ocurre debido a un fallo de enslave después de que el nuevo esclavo ha sido añadido al array. Dado que el nuevo esclavo puede ser usado para Tx inmediatamente, podemos usarlo después de que ha sido liberado por la ruta de limpieza de errores de enslave que libera la memoria del esclavo asignada. Se supone que la actualización del array de esclavos debe ser llamada al final cuando no se esperan más fallos de enslave. Muévelo después de la configuración de xdp para evitar cualquier problema.<br /> <br /> Es muy fácil reproducir el problema con un programa xdp_pass simple:<br /> ip l add bond1 type bond mode balance-xor<br /> ip l set bond1 up<br /> ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass<br /> ip l add dumdum type dummy<br /> <br /> Luego ejecuta en paralelo:<br /> while :; do ip l set dumdum master bond1 1&amp;gt;/dev/null 2&amp;gt;&amp;amp;1; done;<br /> mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp &amp;#39;dp=1-1023, flags=syn&amp;#39;<br /> <br /> El fallo ocurre casi inmediatamente:<br /> [ 605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI<br /> [ 605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf]<br /> [ 605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G B 6.19.0-rc6+ #21 PREEMPT(voluntary)<br /> [ 605.602979] Tainted: [B]=BAD_PAGE<br /> [ 605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210<br /> [ 605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 &amp;lt;80&amp;gt; 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89<br /> [ 605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213<br /> [ 605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000<br /> [ 605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be<br /> [ 605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c<br /> [ 605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000<br /> [ 605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84<br /> [ 605.603286] FS: 00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000<br /> [ 605.603319] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0<br /> [ 605.603373] Call Trace:<br /> [ 605.603392] <br /> [ 605.603410] __dev_queue_xmit+0x448/0x32a0<br /> [ 605.603434] ? __pfx_vprintk_emit+0x10/0x10<br /> [ 605.603461] ? __pfx_vprintk_emit+0x10/0x10<br /> [ 605.603484] ? __pfx___dev_queue_xmit+0x10/0x10<br /> [ 605.603507] ? bond_start_xmit+0xbfb/0xc20 [bonding]<br /> [ 605.603546] ? _printk+0xcb/0x100<br /> [ 605.603566] ? __pfx__printk+0x10/0x10<br /> [ 605.603589] ? bond_start_xmit+0xbfb/0xc20 [bonding]<br /> [ 605.603627] ? add_taint+0x5e/0x70<br /> [ 605.603648] ? add_taint+0x2a/0x70<br /> [ 605.603670] ? end_report.cold+0x51/0x75<br /> [ 605.603693] ? bond_start_xmit+0xbfb/0xc20 [bonding]<br /> [ 605.603731] bond_start_xmit+0x623/0xc20 [bonding]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: wwan: t7xx: corrige un potencial desbordamiento de skb-&amp;gt;frags en la ruta RX<br /> <br /> Al recibir datos en la ruta RX de DPMAIF, la función t7xx_dpmaif_set_frag_to_skb() añade fragmentos de página a un skb sin comprobar si el número de fragmentos ha excedido MAX_SKB_FRAGS. Esto podría conducir a un desbordamiento de búfer en el array skb_shinfo(skb)-&amp;gt;frags[], corrompiendo memoria adyacente y potencialmente causando fallos del kernel u otro comportamiento indefinido.<br /> <br /> Este problema fue identificado a través de análisis de código estático comparando con una vulnerabilidad similar corregida en el commit b102f0c522cf del controlador mt76 (&amp;#39;mt76: corrige el desbordamiento del array al recibir demasiados fragmentos para un paquete&amp;#39;).<br /> <br /> La vulnerabilidad podría ser activada si el firmware del módem envía paquetes con fragmentos excesivos. Si bien bajo condiciones normales del protocolo (MTU 3080 bytes, búfer BAT 3584 bytes), un solo paquete no debería requerir fragmentos adicionales, el kernel no debería confiar ciegamente en el comportamiento del firmware. Firmware malicioso, con errores o comprometido podría potencialmente crear paquetes con más fragmentos de los que el kernel espera.<br /> <br /> Solucione esto añadiendo una comprobación de límites antes de llamar a skb_add_rx_frag() para asegurar que nr_frags no exceda MAX_SKB_FRAGS.<br /> <br /> La comprobación debe realizarse antes de desmapear para evitar una fuga de página y un doble desmapeo DMA durante el desmontaje del dispositivo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/mlx5e: TC, eliminar flujos solo para pares existentes<br /> <br /> Al eliminar flujos de direccionamiento TC, iterar solo sobre pares devcom reales en lugar de asumir que todos los puertos posibles existen. Esto evita tocar pares no existentes y asegura que la limpieza se limite a los dispositivos a los que el controlador está conectado actualmente.<br /> <br /> ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000008<br /> #PF: acceso de escritura de supervisor en modo kernel<br /> #PF: error_code(0x0002) - página no presente<br /> PGD 133c8a067 P4D 0<br /> Oops: Oops: 0002 [#1] SMP<br /> CPU: 19 UID: 0 PID: 2169 Comm: tc No contaminado 6.18.0+ #156 NINGUNO<br /> Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:mlx5e_tc_del_fdb_peers_flow+0xbe/0x200 [mlx5_core]<br /> Código: 00 00 a8 08 74 a8 49 8b 46 18 f6 c4 02 74 9f 4c 8d bf a0 12 00 00 4c 89 ff e8 0e e7 96 e1 49 8b 44 24 08 49 8b 0c 24 4c 89 ff &amp;lt;48&amp;gt; 89 41 08 48 89 08 49 89 2c 24 49 89 5c 24 08 e8 7d ce 96 e1 49<br /> RSP: 0018:ff11000143867528 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: dead000000000122 RCX: 0000000000000000<br /> RDX: ff11000143691580 RSI: ff110001026e5000 RDI: ff11000106f3d2a0<br /> RBP: dead000000000100 R08: 00000000000003fd R09: 0000000000000002<br /> R10: ff11000101c75690 R11: ff1100085faea178 R12: ff11000115f0ae78<br /> R13: 0000000000000000 R14: ff11000115f0a800 R15: ff11000106f3d2a0<br /> FS: 00007f35236bf740(0000) GS:ff110008dc809000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000008 CR3: 0000000157a01001 CR4: 0000000000373eb0<br /> Traza de Llamada:<br /> <br /> mlx5e_tc_del_flow+0x46/0x270 [mlx5_core]<br /> mlx5e_flow_put+0x25/0x50 [mlx5_core]<br /> mlx5e_delete_flower+0x2a6/0x3e0 [mlx5_core]<br /> tc_setup_cb_reoffload+0x20/0x80<br /> fl_reoffload+0x26f/0x2f0 [cls_flower]<br /> ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]<br /> ? mlx5e_tc_reoffload_flows_work+0xc0/0xc0 [mlx5_core]<br /> tcf_block_playback_offloads+0

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mptcp: corrección de condición de carrera en mptcp_pm_nl_flush_addrs_doit()<br /> <br /> syzbot y Eulgyu Kim reportaron fallos en mptcp_pm_nl_get_local_id() y/o mptcp_pm_nl_is_backup()<br /> <br /> La causa raíz es list_splice_init() en mptcp_pm_nl_flush_addrs_doit() que no está preparada para RCU.<br /> <br /> list_splice_init_rcu() no puede ser llamada aquí mientras se mantiene el spinlock pernet-&amp;gt;lock.<br /> <br /> Muchas gracias a Eulgyu Kim por proporcionar una reproducción y probar nuestros parches.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> perf: sched: Soluciona el fallo de perf con la nueva función auxiliar is_user_task()<br /> <br /> Para realizar un seguimiento de pila (stacktrace) del espacio de usuario, la tarea actual debe ser una tarea de usuario que se haya ejecutado en el espacio de usuario. Solía ser posible comprobar si una tarea es una tarea de usuario o no simplemente verificando el campo mm de task_struct. Si no era NULL, era una tarea de usuario y si no, era una tarea del kernel.<br /> <br /> Pero las cosas han cambiado con el tiempo, y algunas tareas del kernel ahora tienen su propio campo mm.<br /> <br /> Se propuso la idea de probar PF_KTHREAD en su lugar y se utilizaron dos funciones para encapsular esta verificación en caso de que se volviera más complejo probar si una tarea era una tarea de usuario o no[1]. Pero esto fue rechazado y el código C simplemente verificó PF_KTHREAD directamente.<br /> <br /> Más tarde se descubrió que no todos los hilos del kernel establecen PF_KTHREAD. Los auxiliares de io-uring, en cambio, establecen PF_USER_WORKER y esto también necesitaba ser añadido.<br /> <br /> Pero verificar las banderas (flags) todavía no es suficiente. Hay una ventana muy pequeña cuando una tarea sale en la que libera su campo mm y este se vuelve a establecer en NULL. Si perf se activara en este momento, la prueba de las banderas diría que es una tarea del espacio de usuario, pero cuando perf leyera el campo mm, fallaría con una desreferencia de puntero NULL.<br /> <br /> Ahora hay banderas que se pueden usar para probar si una tarea está saliendo, pero se establecen en áreas que perf aún podría querer perfilar en la tarea del espacio de usuario (para ver dónde salió). La única prueba real es verificar tanto las banderas como el campo mm.<br /> <br /> En lugar de realizar esta modificación en cada ubicación, cree una nueva función auxiliar is_user_task() que realice todas las pruebas necesarias para saber si es seguro leer la memoria del espacio de usuario o no.<br /> <br /> [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> octeon_ep: Corrección de fuga de memoria en octep_device_setup()<br /> <br /> En octep_device_setup(), si octep_ctrl_net_init() falla, la función retorna directamente sin desmapear los recursos mapeados y liberar la memoria de configuración asignada.<br /> <br /> Esto se corrige saltando a la etiqueta unsupported_dev, la cual realiza la limpieza necesaria. Esto se alinea con la lógica de manejo de errores de otras rutas en esta función.<br /> <br /> Probado únicamente en compilación. Problema encontrado usando una herramienta prototipo de análisis estático y revisión de código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> mm/shmem, swap: corrige la condición de carrera entre el truncamiento y la división de entradas de swap<br /> <br /> La función auxiliar para la liberación de swap de shmem no está manejando correctamente el orden de las entradas de swap. Utiliza xa_cmpxchg_irq para borrar la entrada de swap, pero obtiene el orden de la entrada antes de eso usando xa_get_order sin protección de bloqueo, y puede obtener un valor de orden obsoleto si la entrada se divide o cambia de otras maneras después de xa_get_order y antes de xa_cmpxchg_irq.<br /> <br /> Y además, el orden podría crecer y ser mayor de lo esperado, y causar que el truncamiento borre datos más allá del límite final. Por ejemplo, si la entrada objetivo y las entradas siguientes se intercambian (swap in) o se liberan, y luego se añadió un folio grande en su lugar y se intercambió (swap out), usando la misma entrada, el xa_cmpxchg_irq seguirá teniendo éxito, aunque es muy poco probable que ocurra.<br /> <br /> Para solucionar eso, se implementa directamente el cmpxchg de Xarray y se coloca la recuperación del orden y la verificación del valor en la misma sección crítica. Además, se asegura que el orden no exceda el límite final, se omite si la entrada cruza el límite.<br /> <br /> Omitir entradas de swap grandes que cruzan el límite final es seguro aquí. El truncamiento de shmem itera el rango dos veces; en la primera iteración, find_lock_entries ya filtró dichas entradas, y shmem intercambiará (swap in) las entradas que cruzan el límite final y truncará parcialmente el folio (dividirá el folio o al menos pondrá a cero parte de él). Así que, en el segundo bucle aquí, si vemos una entrada de swap que cruza el orden final, al menos ya debe tener su contenido borrado.<br /> <br /> Observé bloqueos aleatorios de swapoff y &amp;#39;kernel panics&amp;#39; al realizar pruebas de estrés de ZSWAP con shmem. Después de aplicar este parche, todos los problemas desaparecieron.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/xe/nvm: Corrige doble liberación en fallo de adición de aux<br /> <br /> Después de una exitosa auxiliary_device_init(), aux_dev-&amp;gt;dev.release (xe_nvm_release_dev()) es responsable de la kfree(nvm). Cuando hay un fallo con auxiliary_device_add(), el controlador llamará a auxiliary_device_uninit(), que llama a put_device(). De modo que la devolución de llamada .release se activará para liberar la memoria asociada con el auxiliary_device.<br /> <br /> Mueve la kfree(nvm) a la ruta de fallo de auxiliary_device_init() y elimina la ruta err goto para corregir el error a continuación.<br /> <br /> [ 13.232905] ==================================================================<br /> [ 13.232911] BUG: KASAN: double-free in xe_nvm_init+0x751/0xf10 [xe]<br /> [ 13.233112] Free of addr ffff888120635000 by task systemd-udevd/273<br /> <br /> [ 13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd Not tainted 6.19.0-rc2-lgci-xe-kernel+ #225 PREEMPT(voluntary)<br /> ...<br /> [ 13.233125] Call Trace:<br /> [ 13.233126] <br /> [ 13.233127] dump_stack_lvl+0x7f/0xc0<br /> [ 13.233132] print_report+0xce/0x610<br /> [ 13.233136] ? kasan_complete_mode_report_info+0x5d/0x1e0<br /> [ 13.233139] ? xe_nvm_init+0x751/0xf10 [xe]<br /> ...<br /> <br /> v2: elimina la ruta err goto. (Alexander)<br /> <br /> (seleccionado de la confirmación a3187c0c2bbd947ffff97f90d077ac88f9c2a215)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amdgpu: corrige la desreferenciación de puntero NULL en amdgpu_gmc_filter_faults_remove<br /> <br /> En APUs como Raven y Renoir (GC 9.1.0, 9.2.2, 9.3.0), los búferes de anillo de interrupción ih1 e ih2 no están inicializados. Esto es intencional, ya que estos anillos IH secundarios solo están disponibles en GPUs discretas. Véase vega10_ih_sw_init() que explícitamente omite la inicialización de ih1/ih2 cuando AMD_IS_APU está configurado.<br /> <br /> Sin embargo, amdgpu_gmc_filter_faults_remove() usa incondicionalmente ih1 para obtener la marca de tiempo de la última entrada de interrupción. Cuando las fallas de reintento están habilitadas en APUs (noretry=0), esta función es llamada desde la ruta de recuperación de fallas de página SVM, lo que resulta en una desreferenciación de puntero NULL cuando amdgpu_ih_decode_iv_ts_helper() intenta acceder a ih-&amp;gt;ring[].<br /> <br /> El fallo se manifiesta como:<br /> <br /> BUG: desreferenciación de puntero NULL del kernel, dirección: 0000000000000004<br /> RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu]<br /> Call Trace:<br /> amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu]<br /> svm_range_restore_pages+0xae5/0x11c0 [amdgpu]<br /> amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu]<br /> gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu]<br /> amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu]<br /> amdgpu_ih_process+0x84/0x100 [amdgpu]<br /> <br /> Este problema fue expuesto por el commit 1446226d32a4 (&amp;#39;drm/amdgpu: Eliminar GC HW IP 9.3.0 de noretry=1&amp;#39;) que cambió el valor predeterminado para la APU Renoir de noretry=1 a noretry=0, habilitando el manejo de fallas de reintento y, por lo tanto, ejercitando la ruta de código defectuosa.<br /> <br /> Solucione esto añadiendo una comprobación para ih1.ring_size antes de intentar usarlo. También restaure el soporte soft_ih del commit dd299441654f (&amp;#39;drm/amdgpu: Reestructurar la eliminación de fallas de reintento&amp;#39;). Esto es necesario si el hardware no soporta anillos IH de hardware secundarios.<br /> <br /> v2: actualizaciones adicionales (Alex)<br /> <br /> (seleccionado de commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> rocker: corregir fuga de memoria en rocker_world_port_post_fini()<br /> <br /> En rocker_world_port_pre_init(), rocker_port-&amp;gt;wpriv se asigna con kzalloc(wops-&amp;gt;port_priv_size, GFP_KERNEL). Sin embargo, en rocker_world_port_post_fini(), la memoria solo se libera cuando la devolución de llamada wops-&amp;gt;port_post_fini está establecida:<br /> <br /> si (!wops-&amp;gt;port_post_fini)<br /> retornar;<br /> wops-&amp;gt;port_post_fini(rocker_port);<br /> kfree(rocker_port-&amp;gt;wpriv);<br /> <br /> Dado que rocker_ofdpa_ops no implementa la devolución de llamada port_post_fini (es NULL), la memoria wpriv asignada para cada puerto nunca se libera cuando se eliminan los puertos. Esto conduce a una fuga de memoria de sizeof(struct ofdpa_port) bytes por puerto en cada eliminación de dispositivo.<br /> <br /> Solucione esto llamando siempre a kfree(rocker_port-&amp;gt;wpriv) independientemente de si existe la devolución de llamada port_post_fini.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> sfc: soluciona interbloqueo en la lectura de configuración RSS<br /> <br /> Desde el commit citado, el núcleo bloquea el rss_lock del net_device al manejar el comando ethtool -x, por lo que la implementación del controlador no debería bloquearlo de nuevo. Eliminar esto último.