Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> smb/servidor: llamar a ksmbd_session_rpc_close() en la ruta de error en create_smb2_pipe()<br /> <br /> Cuando ksmbd_iov_pin_rsp() falla, deberíamos llamar a ksmbd_session_rpc_close().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> riscv: Sanitizar la indexación de la tabla de llamadas al sistema bajo especulación<br /> <br /> El número de llamada al sistema es un valor controlado por el usuario utilizado para indexar la tabla de llamadas al sistema. Usar array_index_nospec() para restringir este valor después de la comprobación de límites para prevenir el acceso especulativo fuera de límites y la posterior fuga de datos a través de canales laterales de caché.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: mmp_pdma: Corrección de condición de carrera en mmp_pdma_residue()<br /> <br /> Añadir bloqueo adecuado en mmp_pdma_residue() para prevenir uso después de liberación al acceder a la lista de descriptores y al contenido del descriptor.<br /> <br /> La condición de carrera ocurre cuando múltiples hilos llaman a tx_status() mientras el tasklet en otra CPU está liberando descriptores completados:<br /> <br /> CPU 0 CPU 1<br /> ----- -----<br /> mmp_pdma_tx_status()<br /> mmp_pdma_residue()<br /> -&amp;gt; SIN BLOQUEO mantenido<br /> list_for_each_entry(sw, ..)<br /> Interrupción DMA<br /> dma_do_tasklet()<br /> -&amp;gt; spin_lock(&amp;amp;desc_lock)<br /> list_move(sw-&amp;gt;node, ...)<br /> spin_unlock(&amp;amp;desc_lock)<br /> | dma_pool_free(sw) &amp;lt;- ¡LIBERADO!<br /> -&amp;gt; acceso a sw-&amp;gt;desc &amp;lt;- ¡UAF!<br /> <br /> Este problema puede ser reproducido al ejecutar dmatest en el mismo canal con múltiples hilos (hilos_por_canal &amp;gt; 1).<br /> <br /> Solución protegiendo la iteración de la lista chain_running y el acceso al descriptor con el spinlock chan-&amp;gt;desc_lock.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: mac80211: ocb: omitir rx_no_sta cuando la interfaz no está unida<br /> <br /> ieee80211_ocb_rx_no_sta() asume un contexto de canal válido, el cual solo está presente después de JOIN_OCB.<br /> <br /> RX puede ejecutarse antes de que se ejecute JOIN_OCB, en cuyo caso la interfaz OCB no está operativa. Omitir el manejo de pares RX cuando la interfaz no está unida para evitar advertencias en la ruta RX.

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, 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 /> 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 /> flex_proportions: hacer que fprop_new_period() sea seguro para hardirq<br /> <br /> Bernd ha reportado un lockdep splat del código de proporciones flexibles que esencialmente se queja de la siguiente condición de carrera:<br /> <br /> <br /> run_timer_softirq - estamos en contexto de softirq<br /> call_timer_fn<br /> writeout_period<br /> fprop_new_period<br /> write_seqcount_begin(&amp;amp;p-&amp;gt;sequence);<br /> <br /> <br /> ...<br /> blk_mq_end_request()<br /> blk_update_request()<br /> ext4_end_bio()<br /> folio_end_writeback()<br /> __wb_writeout_add()<br /> __fprop_add_percpu_max()<br /> if (unlikely(max_frac &amp;lt; FPROP_FRAC_BASE)) {<br /> fprop_fraction_percpu()<br /> seq = read_seqcount_begin(&amp;amp;p-&amp;gt;sequence);<br /> - ve una secuencia impar por lo que entra en un bucle indefinido<br /> <br /> Tenga en cuenta que un interbloqueo como este solo es posible si el bdi ha configurado una fracción máxima de rendimiento de escritura, lo cual es muy raro en general pero frecuente, por ejemplo, para bdis FUSE. Para solucionar este problema, tenemos que asegurarnos de que la sección de escritura del contador de secuencia sea irqsafe.

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, 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: nfc: nci: Solucionar condición de carrera entre rfkill y nci_unregister_device(). syzbot informó del &amp;#39;splat&amp;#39; a continuación [0] sin una reproducción. Indica que la estructura nci_dev.cmd_wq había sido destruida antes de que se llamara a nci_close_device() a través de rfkill. nci_dev.cmd_wq solo se destruye en nci_unregister_device(), que (creo) fue llamada desde virtual_ncidev_close() cuando syzbot cerró un &amp;#39;fd&amp;#39; de virtual_ncidev. El problema es que nci_unregister_device() destruye nci_dev.cmd_wq primero y luego llama a nfc_unregister_device(), que elimina el dispositivo de rfkill mediante rfkill_unregister(). Así, el dispositivo sigue siendo visible a través de rfkill incluso después de que nci_dev.cmd_wq sea destruida. Desregistremos el dispositivo de rfkill primero en nci_unregister_device(). Tenga en cuenta que no podemos llamar a nfc_unregister_device() antes de nci_close_device() porque 1) nfc_unregister_device() llama a device_del() que libera toda la memoria asignada por devm_kzalloc() y vinculada a ndev-&amp;gt;conn_info_list 2) nci_rx_work() podría intentar encolar nci_conn_info a ndev-&amp;gt;conn_info_list lo que podría provocar una fuga de memoria Por lo tanto, nfc_unregister_device() se divide en dos funciones para que podamos eliminar las interfaces de rfkill solo antes de nci_close_device(). [0]: DEBUG_LOCKS_WARN_ON(1) ADVERTENCIA: kernel/locking/lockdep.c:238 en hlock_class kernel/locking/lockdep.c:238 [inline], CPU#0: syz.0.8675/6349 ADVERTENCIA: kernel/locking/lockdep.c:238 en check_wait_context kernel/locking/lockdep.c:4854 [inline], CPU#0: syz.0.8675/6349 ADVERTENCIA: kernel/locking/lockdep.c:238 en __lock_acquire+0x39d/0x2cf0 kernel/locking/lockdep.c:5187, CPU#0: syz.0.8675/6349 Módulos enlazados: CPU: 0 UID: 0 PID: 6349 Comm: syz.0.8675 No contaminado syzkaller #0 PREEMPT(full) Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline] RIP: 0010:check_wait_context kernel/locking/lockdep.c:4854 [inline] RIP: 0010:__lock_acquire+0x3a4/0x2cf0 kernel/locking/lockdep.c:5187 Código: 18 00 4c 8b 74 24 08 75 27 90 e8 17 f2 fc 02 85 c0 74 1c 83 3d 50 e0 4e 0e 00 75 13 48 8d 3d 43 f7 51 0e 48 c7 c6 8b 3a de 8d &amp;lt;67&amp;gt; 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f RSP: 0018:ffffc9000c767680 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000040000 RCX: 0000000000080000 RDX: ffffc90013080000 RSI: ffffffff8dde3a8b RDI: ffffffff8ff24ca0 RBP: 0000000000000003 R08: ffffffff8fef35a3 R09: 1ffffffff1fde6b4 R10: dffffc0000000000 R11: fffffbfff1fde6b5 R12: 00000000000012a2 R13: ffff888030338ba8 R14: ffff888030338000 R15: ffff888030338b30 FS: 00007fa5995f66c0(0000) GS:ffff8881256f8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7e72f842d0 CR3: 00000000485a0000 CR4: 00000000003526f0 Ruta de llamada: lock_acquire+0x106/0x330 kernel/locking/lockdep.c:5868 touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3940 __flush_workqueue+0x14b/0x14f0 kernel/workqueue.c:3982 nci_close_device+0x302/0x630 net/nfc/nci/core.c:567 nci_dev_down+0x3b/0x50 net/nfc/nci/core.c:639 nfc_dev_down+0x152/0x290 net/nfc/core.c:161 nfc_rfkill_set_block+0x2d/0x100 net/nfc/core.c:179 rfkill_set_block+0x1d2/0x440 net/rfkill/core.c:346 rfkill_fop_write+0x461/0x5a0 net/rfkill/core.c:1301 vfs_write+0x29a/0xb90 fs/read_write.c:684 ---truncado---