Vulnerabilidades

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 /> smb/servidor: corregir fuga de contador de referencias en parse_durable_handle_context()<br /> <br /> Cuando el comando es una operación de repetición y se devuelve -ENOEXEC,<br /> el contador de referencias de ksmbd_file debe ser liberado.

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 /> 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: wlcore: asegurar el headroom de skb antes de skb_push<br /> <br /> Esto evita Oops ocasionales de skb_under_panic de wl1271_tx_work. En este caso, el headroom es menor de lo necesario (típicamente 110 - 94 = 16 bytes).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> smb/server: corregir fuga de contador de referencias en smb2_open()<br /> <br /> Cuando ksmbd_vfs_getattr() falla, el contador de referencias de ksmbd_file debe ser liberado.

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 /> 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 /> 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