Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: DR, evitar la posible desreferencia del puntero de error La función dr_domain_add_vport_cap() generalmente devuelve NULL en caso de error, pero a veces queremos que devuelva ERR_PTR(-EBUSY) para que el autor de la llamada pueda volver a intentarlo. El problema aquí es que "ret" puede ser -EBUSY o -ENOMEM y si es y -ENOMEM, entonces el puntero de error se propaga de vuelta y finalmente se desreferencia en dr_ste_v0_build_src_gvmi_qpn_tag().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: se corrige la deref NULL en cleanup_bearer() syzbot encontró [1] que después de el commit culpada, ub->ubsock->sk era NULL al intentar atomic_dec() : atomic_dec(&tipc_net(sock_net(ub->ubsock->sk))->wq_count); Solucione esto almacenando en caché el puntero tipc_net. [1] Ups: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en el rango [0x000000000000030-0x0000000000000037] CPU: 0 UID: 0 PID: 5896 Comm: kworker/0:3 No contaminado 6.13.0-rc1-next-20241203-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 Cola de trabajo: eventos cleanup_bearer RIP: 0010:read_pnet include/net/net_namespace.h:387 [en línea] RIP: 0010:sock_net include/net/sock.h:655 [en línea] RIP: 0010:cleanup_bearer+0x1f7/0x280 net/tipc/udp_media.c:820 Código: 18 48 89 d8 48 c1 e8 03 42 80 3c 28 00 74 08 48 89 df e8 3c f7 99 f6 48 8b 1b 48 83 c3 30 e8 f0 e4 60 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 1a f7 99 f6 49 83 c7 e8 48 8b 1b RSP: 0018:ffffc9000410fb70 EFLAGS: 00010206 RAX: 0000000000000006 RBX: 0000000000000030 RCX: ffff88802fe45a00 RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffc9000410f900 RBP: ffff88807e1f0908 R08: ffffc9000410f907 R09: 1ffff92000821f20 R10: dffffc0000000000 R11: fffff52000821f21 R12: ffff888031d19980 R13: dffffc0000000000 R14: dffffc0000000000 R15: ffff88807e1f0918 FS: 0000000000000000(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556ca050b000 CR3: 0000000031c0c000 CR4: 00000000003526f0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: btmtk: evitar UAF en btmtk_process_coredump hci_devcd_append puede provocar la liberación del skb, por lo que no se puede acceder a él una vez que se llama. ===================================================================== ERROR: KASAN: slab-use-after-free en btmtk_process_coredump+0x2a7/0x2d0 [btmtk] Lectura de tamaño 4 en la dirección ffff888033cfabb0 por la tarea kworker/0:3/82 CPU: 0 PID: 82 Comm: kworker/0:3 Contaminado: GU 6.6.40-lockdep-03464-g1d8b4eb3060e #1 b0b3c1cc0c842735643fb411799d97921d1f688c Nombre del hardware: Google Yaviks_Ufs/Yaviks_Ufs, BIOS Google_Yaviks_Ufs.15217.552.0 07/05/2024 Cola de trabajo: eventos btusb_rx_work [btusb] Seguimiento de llamadas: dump_stack_lvl+0xfd/0x150 print_report+0x131/0x780 kasan_report+0x177/0x1c0 btmtk_process_coredump+0x2a7/0x2d0 [btmtk 03edd567dd71a65958807c95a65db31d433e1d01] btusb_recv_acl_mtk+0x11c/0x1a0 [btusb Asignado por la tarea 82: stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80 __kasan_slab_alloc+0x4e/0x60 kmem_cache_alloc+0x19f/0x360 skb_clone+0x132/0xf70 btusb_recv_acl_mtk+0x104/0x1a0 [btusb] btusb_rx_work+0x9e/0xe0 [btusb] subproceso de trabajo+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 Liberado por la tarea 1733: stack_trace_save+0xdc/0x190 kasan_set_track+0x4e/0x80 kasan_save_free_info+0x28/0xb0 ____kasan_slab_free+0xfd/0x170 kmem_cache_free+0x183/0x3f0 hci_devcd_rx+0x91a/0x2060 [bluetooth] worker_thread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 ret_from_fork+0x51/0x80 ret_from_fork_asm+0x1b/0x30 La dirección con errores pertenece al objeto en ffff888033cfab40 que pertenece al caché skbuff_head_cache de tamaño 232 La dirección con errores se encuentra 112 bytes dentro de la región liberada de 232 bytes [ffff888033cfab40, ffff888033cfac28) La dirección con errores pertenece a la página física: page:00000000a174ba93 refcount:1 mapcount:0 mapeo:0000000000000000 índice:0x0 pfn:0x33cfa encabezado:00000000a174ba93 orden:1 recuento_de_mapas_entero:0 nr_páginas_asignadas:0 recuento_de_pins:0 anon banderas: 0x4000000000000840(slab|head|zone=1) tipo_de_página: 0xffffffff() sin procesar: 4000000000000840 ffff888100848a00 0000000000000000 0000000000000001 sin procesar: 000000000000000 000000000080190019 00000001ffffffff 0000000000000000 página volcada porque: kasan: se detectó un acceso incorrecto Estado de la memoria alrededor de la dirección con errores: ffff888033cfaa80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888033cfab00: fc fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb fb fb >ffff888033cfab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888033cfac00: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc ffff888033cfac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb == ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/reg_sr: Eliminar el grupo de registros Esa implementación del grupo no funciona realmente: si el krealloc mueve la memoria y devuelve otra dirección, las entradas en el xarray dejan de ser válidas, lo que lleva a un use-after-free más adelante: ERROR: KASAN: slab-use-after-free en xe_reg_sr_apply_mmio+0x570/0x760 [xe] Lectura de tamaño 4 en la dirección ffff8881244b2590 por la tarea modprobe/2753 Asignado por la tarea 2753: kasan_save_stack+0x39/0x70 kasan_save_track+0x14/0x40 kasan_save_alloc_info+0x37/0x60 __kasan_kmalloc+0xc3/0xd0 __kmalloc_node_track_caller_noprof+0x200/0x6d0 krealloc_noprof+0x229/0x380 Simplifique el código para corregir el error. Es posible que se agregue una mejor estrategia de agrupamiento más adelante si es necesario. (seleccionada de el commit e5283bd4dfecbd3335f43b62a68e24dae23f59e4)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: defer final 'struct net' free en netns dismantle Ilya informó de un slab-use-after-free en dst_destroy [1] El problema está en xfrm6_net_init() y xfrm4_net_init(): copian xfrm[46]_dst_ops_template en net->xfrm.xfrm[46]_dst_ops. Pero la estructura net podría liberarse antes de que se llamen todas las devoluciones de llamadas dst. Entonces, cuando dst_destroy() llama más tarde: if (dst->ops->destroy) dst->ops->destroy(dst); dst->ops apunta al antiguo net->xfrm.xfrm[46]_dst_ops, que ha sido liberado. Consulte un problema relevante corregido en: ac888d58869b ("net: no demore dst_entries_add() en dst_release()") Una solución es poner en cola la 'struct net' para que se libere después de otra ronda cleanup_net() (y rcu_barrier() existente) [1] ERROR: KASAN: slab-use-after-free en dst_destroy (net/core/dst.c:112) Lectura de tamaño 8 en la dirección ffff8882137ccab0 por la tarea swapper/37/0 03 de diciembre 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: cargado No contaminado 6.12.0 #67 Nombre del hardware: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 01/04/2014 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:124) imprimir_dirección_descripción.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) imprimir_informe (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Código: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 00000000000000000 R08: 0000000000000001 R09: fffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminador 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? ¿__pfx_start_secondary (arch/x86/kernel/smpboot.c:232)? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414) 03 de diciembre 05:46:18 kernel: Asignado por la tarea 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) crear_nuevos_espacios_de_nombres ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: no aplazar la destrucción de la regla mediante call_rcu nf_tables_chain_destroy puede dormir, no se puede utilizar desde las devoluciones de llamadas call_rcu. Además, nf_tables_rule_release() solo es seguro para desenrollar errores, mientras se mantiene el mutex de transacción y la regla a destruir no se expuso ni al plano de datos ni a los volcados, ya que desactiva + libera sin elsynchronous_rcu() requerido en el medio. Las devoluciones de llamadas nft_rule_expr_deactivate() cambiarán ->use contadores de otras cadenas/conjuntos, consulte, por ejemplo, la devolución de llamada nft_lookup .deactivate, que se deben serializar mediante el mutex de transacción. Agregue también algunas afirmaciones lockdep para que esto sea más explícito. Llamar asynchronous_rcu() no es ideal, pero solucionar esto sin él es difícil y mucho más intrusivo. Tal como está, podemos obtener: ADVERTENCIA: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x.. Cola de trabajo: eventos nf_tables_trans_destroy_work RIP: 0010:nft_set_destroy+0x3fe/0x5c0 Rastreo de llamadas: nf_tables_trans_destroy_work+0x6b7/0xad0 process_one_work+0x64a/0xce0 worker_thread+0x613/0x10d0 En caso de que elsynchronous_rcu se convierta en un problema, podemos explorar alternativas. Una forma sería asignar objetos nft_trans_rule + un objeto nft_trans_chain, desactivar las reglas + la cadena y luego diferir la liberación a la cola de trabajo de destrucción de nft. Aún así, necesitaríamos mantener la ruta synchronization_rcu como respaldo para gestionar casos especiales de -ENOMEM.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/ipv6: liberación de la excepción dst expirada almacenada en caché en el socket. Los objetos Dst se filtran en ip6_negative_advice() cuando se ejecuta esta función para una ruta IPv6 expirada ubicada en la tabla de excepciones. Hay varias condiciones que deben cumplirse para que se produzca la fuga: * se recibe un paquete ICMPv6 que indica un cambio de la MTU para la ruta, lo que da como resultado la creación de un dst de excepción * una conexión TCP que utiliza el dst de excepción para enrutar paquetes debe comenzar a agotar el tiempo de espera para que TCP comience las retransmisiones * después de que el dst de excepción caduque, el recolector de basura FIB6 no debe ejecutarse antes de que TCP ejecute ip6_negative_advice() para el dst de excepción caducado Cuando TCP ejecuta ip6_negative_advice() para un dst de excepción que ha caducado y si ningún otro socket tiene una referencia al dst de excepción, el recuento de referencias del dst de excepción es 2, que corresponde al incremento realizado por dst_init() y el incremento realizado por el socket TCP para el que se agota el tiempo de espera de la conexión. El recuento de referencias realizado por el socket nunca se libera. El recuento de referencias del dst se reduce en sk_dst_reset() pero esa reducción se contrarresta con un dst_hold() colocado intencionalmente justo antes del sk_dst_reset() en ip6_negative_advice(). Después de que ip6_negative_advice() haya terminado, no hay otro objeto vinculado al dst. El socket perdió su referencia almacenada en sk_dst_cache y el dst ya no está en la tabla de excepciones. El dst de excepción se convierte en un objeto filtrado. Como resultado de esta filtración de dst, se informa un recuento de referencias desequilibrado para el dispositivo de bucle invertido de un espacio de nombres de red que se destruye en núcleos que no contienen e5f80fcf869a ("ipv6: dar un dev IPv6 a blackhole_netdev"): unregister_netdevice: esperando a que lo se libere. Recuento de uso = 2 Corrija la filtración de dst eliminando dst_hold() en ip6_negative_advice(). El parche que introdujo dst_hold() en ip6_negative_advice() fue 92f1655aa2b22 ("net: fix __dst_negative_advice() race"). Pero 92f1655aa2b22 simplemente refactorizó el código con respecto al recuento de referencias dst, por lo que el problema estaba presente incluso antes de 92f1655aa2b22. El error se introdujo en 54c1a859efd9f ("ipv6: Don't drop cache route entry sometimes expired.") donde la ruta en caché expirada se elimina y el miembro sk_dst_cache del socket se establece en NULL al llamar a dst_negative_advice(), pero el recuento de referencias que pertenece al socket se deja desequilibrado. La versión IPv4 - ipv4_negative_advice() - no se ve afectada por este error. Cuando se agota el tiempo de conexión TCP, ipv4_negative_advice() simplemente restablece el sk_dst_cache del socket mientras disminuye el recuento de referencias del dst de excepción.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: j1939_session_new(): corrige el conteo de referencias de skb Dado que j1939_session_skb_queue() realiza un skb_get() adicional para cada nuevo skb, haga lo mismo para el inicial en j1939_session_new() para evitar el desbordamiento del conteo de referencias. [mkl: limpia el mensaje de confirmación]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: evitar posible desreferencia NULL en modify_prefix_route() syzbot encontró una desreferencia NULL [1] en modify_prefix_route(), causada por un fib6_info sin un puntero fib6_table establecido. Esto puede suceder con net->ipv6.fib6_null_entry [1] Ups: error de protección general, probablemente para la dirección no canónica 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en el rango [0x000000000000030-0x0000000000000037] CPU: 1 UID: 0 PID: 5837 Comm: syz-executor888 No contaminado 6.12.0-syzkaller-09567-g7eef7e306d3c #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 RIP: 0010:__lock_acquire+0xe4/0x3c40 kernel/locking/lockdep.c:5089 Código: 08 84 d2 0f 85 15 14 00 00 44 8b 0d ca 98 f5 0e 45 85 c9 0f 84 b4 0e 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 96 2c 00 00 49 8b 04 24 48 3d a0 07 7f 93 0f 84 RSP: 0018:ffffc900035d7268 EFLAGS: 00010006 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 00000000000000006 RSI: 1ffff920006bae5f RDI: 0000000000000030 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff90608e17 R11: 0000000000000001 R12: 0000000000000030 R13: ffff888036334880 R14: 0000000000000000 R15: 0000000000000000 FS: 0000555579e90380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc59cc4278 CR3: 0000000072b54000 CR4: 00000000003526f0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5849 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [en línea] _raw_spin_lock_bh+0x33/0x40 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [en línea] modificar_prefijo_ruta+0x30b/0x8b0 net/ipv6/addrconf.c:4831 inet6_addr_modificar net/ipv6/addrconf.c:4923 [en línea] inet6_rtm_newaddr+0x12c7/0x1ab0 net/ipv6/addrconf.c:5055 rtnetlink_rcv_msg+0x3c7/0xea0 net/core/rtnetlink.c:6920 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2541 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [en línea] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [en línea] __sock_sendmsg net/socket.c:726 [en línea] ____sys_sendmsg+0xaaf/0xc90 net/socket.c:2583 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2637 __sys_sendmsg+0x16e/0x220 net/socket.c:2669 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fd1dcef8b79 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc59cc4378 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd1dcef8b79 RDX: 0000000000040040 RSI: 0000000020000140 RDI: 0000000000000004 RBP: 00000000000113fd R08: 0000000000000006 R09: 0000000000000006 R10: 00000000000000006 R11: 0000000000000246 R12: 00007ffc59cc438c R13: 431bde82d7b634db R14: 000000000000001 R15: 0000000000000001

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: Fix icmp host relookup triggering ip_rt_bug arp link failure may trigger ip_rt_bug while xfrm enabled, call trace is: ADVERTENCIA: CPU: 0 PID: 0 en net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20 Módulos vinculados en: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 No contaminado 6.12.0-rc6-00077-g2e1b3cc9d7f7 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 RIP: 0010:ip_rt_bug+0x14/0x20 Seguimiento de llamadas: ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 error de enlace ipv4+0xe2/0x1d0 informe de error arp+0x3c/0x50 invalidación vecinal+0x8d/0x100 controlador de temporizador vecinal+0x2e1/0x330 función de temporizador de llamada+0x21/0x120 __base de temporizador de ejecución.parte.0+0x1c9/0x270 temporizador de ejecución softirq+0x4c/0x80 controlador de softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90 El script a continuación reproduce este escenario: ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmp ip la veth1 type veth ip aa 192.168.141.111/24 dev veth0 ip ls veth0 up ping 192.168.141.155 -c 1 icmp_route_lookup() crea rutas de entrada para paquetes generados localmente mientras xfrm vuelve a buscar tráfico ICMP. Luego, establecerá la ruta de entrada (dst->out = ip_rt_bug) en skb para DESTUNREACH. Para el error ICMP activado por paquetes generados localmente, dst->dev de la ruta de salida es loopback. En general, no se requiere la verificación de rebúsqueda de xfrm en interfaces de bucle invertido (net.ipv4.conf.lo.disable_xfrm = 1). Omita la rebúsqueda de ICMP para paquetes generados localmente para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hsr: evitar un posible acceso fuera de los límites en fill_frame_info() syzbot puede enviar un paquete con 14 bytes, simulando que es uno de VLAN. Dado que fill_frame_info() ya depende de skb->mac_len, amplíe la comprobación para cubrir este caso. ERROR: KMSAN: valor no inicializado en fill_frame_info net/hsr/hsr_forward.c:709 [en línea] ERROR: KMSAN: valor no inicializado en hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [en línea] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [en línea] netdev_start_xmit incluir/linux/netdevice.h:5011 [en línea] xmit_one net/core/dev.c:3590 [en línea] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit incluir/linux/netdevice.h:3168 [en línea] paquete_xmit+0x9c/0x6c0 net/paquete/af_packet.c:276 paquete_snd net/paquete/af_packet.c:3146 [en línea] paquete_sendmsg+0x91ae/0xa6f0 net/paquete/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [en línea] __sock_sendmsg+0x30f/0x380 red/socket.c:726 __sys_sendto+0x594/0x750 red/socket.c:2197 __do_sys_sendto red/socket.c:2204 [en línea] __se_sys_sendto red/socket.c:2200 [en línea] __x64_sys_sendto+0x125/0x1d0 red/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit se creó en: slab_post_alloc_hook mm/slub.c:4091 [en línea] slab_alloc_node mm/slub.c:4134 [en línea] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [en línea] alloc_skb_with_frags+0xc8/0xd00 red/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 red/core/sock.c:2881 paquete_alloc_skb red/paquete/af_packet.c:2995 [en línea] paquete_snd red/paquete/af_packet.c:3089 [en línea] paquete_sendmsg+0x74c6/0xa6f0 red/paquete/af_packet.c:3178 sock_sendmsg_nosec red/socket.c:711 [en línea] __sock_sendmsg+0x30f/0x380 red/socket.c:726 __sys_sendto+0x594/0x750 red/socket.c:2197 __do_sys_sendto net/socket.c:2204 [en línea] __se_sys_sendto net/socket.c:2200 [en línea] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: enetc: No configure TC preemptibles si los SI no son compatibles Ambos controladores ENETC PF y VF comparten enetc_setup_tc_mqprio() para configurar MQPRIO. Y enetc_setup_tc_mqprio() llama a enetc_change_preemptible_tcs() para configurar TC preemptibles. Sin embargo, solo PF puede configurar TC preemptibles. Porque solo PF tiene registros relacionados, mientras que VF no tiene estos registros. Entonces, para VF, su puntero hw->port es NULL. Por lo tanto, VF accederá a un puntero no válido cuando acceda a un registro inexistente, lo que provocará un problema de bloqueo. El registro simplificado es el siguiente. root@ls1028ardb:~# tc qdisc add dev eno0vf0 parent root handle 100: \ mqprio num_tc 4 map 0 0 1 1 2 2 3 3 queues 1@0 1@1 1@2 1@3 hw 1 [ 187.290775] No se puede gestionar la solicitud de paginación del núcleo en la dirección virtual 0000000000001f00 [ 187.424831] pc : enetc_mm_commit_preemptible_tcs+0x1c4/0x400 [ 187.430518] lr : enetc_mm_commit_preemptible_tcs+0x30c/0x400 [ 187.511140] Rastreo de llamada: [ 187.513588] enetc_mm_commit_preemptible_tcs+0x1c4/0x400 [ 187.518918] enetc_setup_tc_mqprio+0x180/0x214 [ 187.523374] enetc_vf_setup_tc+0x1c/0x30 [ 187.527306] mqprio_enable_offload+0x144/0x178 [ 187.531766] mqprio_init+0x3ec/0x668 [ 187.535351] qdisc_create+0x15c/0x488 [ 187.539023] tc_modify_qdisc+0x398/0x73c [ 187.542958] rtnetlink_rcv_msg+0x128/0x378 [ 187.547064] netlink_rcv_skb+0x60/0x130 [ 187.550910] rtnetlink_rcv+0x18/0x24 [ 187.554492] netlink_unicast+0x300/0x36c [ 187.558425] netlink_sendmsg+0x1a8/0x420 [ 187.606759] ---[ fin de seguimiento 0000000000000000 ]--- Además, algunos PF tampoco admiten la configuración de TC interrumpibles, como eno1 y eno3 en LS1028A. No se bloqueará como ocurre con los VF, pero debemos evitar que estos PF accedan a estos registros no implementados.