Vulnerabilidades

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: dccp: Se corrige la pérdida de memoria en dccp_feat_change_recv Si dccp_feat_push_confirm() falla después de que se aceptó un nuevo valor para la característica SP sin conciliación (rama 'entry == NULL'), la memoria asignada para ese valor con dccp_feat_clone_sp_val() nunca se libera. Aquí está la pila kmemleak para esto: objeto sin referencia 0xffff88801d4ab488 (tamaño 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (edad 41.666s) volcado hexadecimal (primeros 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [en línea] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [en línea] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [en línea] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [en línea] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 red/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 red/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv incluir/net/sock.h:1041 [en línea] [<00000000a6c24128>] __release_sock+0x139/0x3b0 red/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] espera_de_conexión inet net/ipv4/af_inet.c:603 [en línea] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] archivo_de_conexión_sys+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 red/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect red/socket.c:1892 [en línea] [<00000000f4cb3815>] __se_sys_connect red/socket.c:1889 [en línea] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 red/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1 Limpia la memoria asignada en caso de que dccp_feat_push_confirm() falle y se resuelve con un código de reinicio de error. Encontrado por Linux Verification Center (linuxtesting.org) con Syzkaller.

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