Vulnerabilidades

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: Bluetooth: hci_event: Se solucionó el uso de rcu_read_(un)lock durante la iteración El uso de rcu_read_(un)lock mientras se está dentro de list_for_each_entry_rcu no es seguro ya que en la mayor parte de los casos las entradas obtenidas de esta manera se tratarán como rcu_dereference: Tenga en cuenta que el valor devuelto por rcu_dereference() solo es válido dentro de la sección crítica del lado de lectura de RCU [1]_. Por ejemplo, lo siguiente **no** es legal:: rcu_read_lock(); p = rcu_dereference(head.next); rcu_read_unlock(); x = p->address; /* ¡ERROR! */ rcu_read_lock(); y = p->data; /* ¡ERROR! */ rcu_read_unlock();

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: bnxt_en: Arreglar la máscara de ID de agregación para evitar errores en los chips 5760X La interfaz HW GRO/LRO del chip 5760X (P7) es muy similar a la de la generación anterior (5750X o P5). Sin embargo, los campos de ID de agregación en las estructuras de finalización en P7 se han redefinido de 16 bits a 12 bits. Los 4 bits liberados se redefinen para parte de los metadatos, como el ID de VLAN. La máscara de ID de agregación no se modificó al agregar soporte para chips P7. Incluir los 4 bits adicionales para el ID de agregación puede hacer que el controlador almacene o busque el encabezado del paquete de paquetes GRO/LRO en el búfer TPA incorrecto. Puede alcanzar la condición BUG() en __skb_pull() porque el SKB no contiene un encabezado de paquete válido: ¡ERROR del kernel en include/linux/skbuff.h:2766! Ups: código de operación no válido: 0000 1 PREEMPT SMP NOPTI CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Kdump: cargado Contaminado: G OE 6.12.0-rc2+ #7 Contaminado: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Nombre del hardware: Dell Inc. PowerEdge R760/0VRV9X, BIOS 1.0.1 27/12/2022 RIP: 0010:eth_type_trans+0xda/0x140 Código: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 d0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a y siguientes 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 y siguientes 74 eb 31 f6 b9 02 00 00 00 48 RSP: 0018:ff615003803fcc28 EFLAGS: 00010283 RAX: 00000000000022d2 RBX: 0000000000000003 RCX: ff2e8c25da334040 RDX: 0000000000000040 RSI: ff2e8c25c1ce8000 RDI: RBP: ff2e8c258c31c000 R08: ff2e8c25da334000 R09: 0000000000000001 R10: ff2e8c25da3342c0 R11: ff2e8c25c1ce89c0 R12: ff2e8c258e0990b0 R13: ff2e8c25bb120000 R14: ff2e8c25c1ce89c0 R15: ff2e8c25869f9000 FS: 0000000000000000(0000) GS:ff2e8c34be300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f05317e4c8 CR3: 000000108bac6006 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Rastreo de llamadas: ? die+0x33/0x90 ? do_trap+0xd9/0x100 ? eth_type_trans+0xda/0x140 ? do_error_trap+0x65/0x80 ? eth_type_trans+0xda/0x140 ? exc_invalid_op+0x4e/0x70 ? eth_type_trans+0xda/0x140 ? asm_exc_invalid_op+0x16/0x20 ? eth_type_trans+0xda/0x140 bnxt_tpa_end+0x10b/0x6b0 [bnxt_en] ? bnxt_tpa_start+0x195/0x320 [bnxt_es] bnxt_rx_pkt+0x902/0xd90 [bnxt_es] ? __bnxt_tx_int.constprop.0+0x89/0x300 [bnxt_es] ? kmem_cache_free+0x343/0x440 ? __bnxt_tx_int.constprop.0+0x24f/0x300 [bnxt_es] __bnxt_poll_work+0x193/0x370 [bnxt_es] bnxt_poll_p5+0x9a/0x300 [bnxt_es] ? try_to_wake_up+0x209/0x670 __napi_poll+0x29/0x1b0 Solucione el problema redefiniendo la máscara de ID de agregación para los chips P5_PLUS para que sea de 12 bits. Esto funcionará porque la ID de agregación máxima es menor que 4096 en todos los chips P5_PLUS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: control: Evitar WARN() para errores de enlaces simbólicos El uso de WARN() para mostrar el error de creación de enlaces simbólicos no proporciona más información que la de indicar que algo va mal, ya que la ruta de código habitual es una devolución de llamada lregister desde cada creación de elemento de control. Lo que es peor, el uso de WARN() confunde bastante a fuzzer como si se tratara de problemas graves. Este parche degrada los mensajes de advertencia para utilizar el dev_err() normal en lugar de WARN(). Para que quede más claro, añade también el nombre de la función al prefijo.

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: net: lapb: increment LAPB_HEADER_LEN No está claro si el código net/lapb debería estar listo para 8021q. Al menos podemos evitar fallos como el siguiente: skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2 ------------[ corte aquí ]------------ ¡ERROR del kernel en net/core/skbuff.c:206! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd No contaminado 6.12.0-rc7-syzkaller-00144-g66418447d27b #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 30/10/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [en línea] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Código: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282 RAX: 000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600 RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000 RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60 R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140 R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016 FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: skb_push+0xe5/0x100 net/core/skbuff.c:2636 nr_header+0x36/0x320 net/netrom/nr_dev.c:69 dev_hard_header include/linux/netdevice.h:3148 [en línea] vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83 dev_hard_header include/linux/netdevice.h:3148 [en línea] lapbeth_data_transmit+0x1f6/0x2a0 controladores/red/wan/lapbether.c:257 transmisión_datos_lapb+0x91/0xb0 red/lapb/lapb_iface.c:447 búfer_transmisión_lapb+0x168/0x1f0 red/lapb/lapb_out.c:149 establecimiento_enlace_datos_lapb+0x84/0xd0 evento_dispositivo_lapb+0x4e0/0x670 cadena_llamada_notificador+0x19f/0x3e0 kernel/notificador.c:93 indicadores_notificación_dev_dev+0x207/0x400 indicadores_cambio_dev_dev+0xf0/0x1a0 red/core/dev.c:8922 ioctl_devinet+0xa4e/0x1aa0 red/ipv4/devinet.c:1188 inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x158/0x460 net/socket.c:1227 sock_ioctl+0x626/0x8e0 net/socket.c:1346 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:907 [en línea] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83

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: 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: 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.

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