Vulnerabilidades

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

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