Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: wfx: corrige la pérdida de memoria al iniciar AP Kmemleak informó este error: objeto sin referencia 0xd73d1180 (tamaño 184): comm "wpa_supplicant", pid 1559, jiffies 13006305 (edad 964.245 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................ rastreo inverso: [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac [<127bdd74>] __alloc_skb+0x144/0x170 [] __netdev_alloc_skb +0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] 8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+ 0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] 130 [<6b7c977a>] genl_rcv+0x34/0x44 [ <66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] b4 [<69954f45>] __sys_sendmsg+0x64/0xa8 sin referencia Objeto 0xCE087000 (tamaño 1024): Comm "WPA_Supplicant", PID 1559, Jiffies 13006305 (Edad 964.246s) Volcado hexagonal (Primero 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... ............ 10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ retroceso: [<9a993714> ] __kmalloc_track_caller+0x230/0x600 [] kmalloc_reserve.constprop.0+0x30/0x74 [] __alloc_skb+0xa0/0x170 [] __netdev_alloc_skb+0x50/0x180 9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [ mac80211] [] nl80211_start_ap+0x76c /0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4 Sin embargo, dado que el kernel está optimizado, parece que la pila no es precisa. Parece que el problema está relacionado con wfx_set_mfp_ap(). El problema es obvio en esta función: la memoria asignada por ieee80211_beacon_get() nunca se libera. Arreglar esta fuga hace feliz a kmemleak.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: aoe: soluciona el posible problema de use-after-free en aoecmd_cfg_pkts. Este parche es contra CVE-2023-6270. La descripción de cve es: Se encontró una falla en el controlador ATA sobre Ethernet (AoE) en el kernel de Linux. La función aoecmd_cfg_pkts() actualiza incorrectamente el refcnt en `struct net_device`, y se puede activar un use-after-free corriendo entre lo libre en la estructura y el acceso a través de la cola global `skbtxq`. Esto podría provocar una condición de denegación de servicio o una posible ejecución de código. En aoecmd_cfg_pkts(), siempre llama a dev_put(ifp) cuando finaliza el código inicial de skb. Pero el ifp net_device todavía se usará en tx()->dev_queue_xmit() posterior en kthread. Lo que significa que NO se debe llamar a dev_put(ifp) en la ruta exitosa del código inicial de skb en aoecmd_cfg_pkts(). De lo contrario, tx() puede ejecutar use-after-free porque el net_device está liberado. Este parche eliminó dev_put(ifp) en la ruta de éxito en aoecmd_cfg_pkts() y agregó dev_put() después de skb xmit en tx().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: soluciona el punto muerto entre bd_link_disk_holder y el análisis de partición. 'open_mutex' de gendisk se utiliza para proteger dispositivos de bloqueo de apertura/cierre. Pero en bd_link_disk_holder(), se utiliza para proteger la creación de un enlace simbólico entre el disco de retención y el bdev esclavo, lo que introduce algunos problemas. Cuando se llama a bd_link_disk_holder(), el controlador generalmente está en el proceso de inicialización/modificación y puede suspender el envío de io. En este momento, cualquier retención de io 'open_mutex', como escanear particiones, puede causar interbloqueos. Por ejemplo, en raid: T1 T2 bdev_open_by_dev lock open_mutex [1] ... efi_partition ... md_submit_bio md_ioctl mddev_syspend -> suspender todo io md_add_new_disk bind_rdev_to_array bd_link_disk_holder try lock open_mutex [2] md_handle_request -> esperar mddev_resume T1 escanear partición, agregar un Nuevo dispositivo para atacar. T1 espera a que T2 reanude mddev, pero T2 espera a open_mutex retenido por T1. Se produce un punto muerto. Solucionarlo introduciendo un mutex local 'blk_holder_mutex' para reemplazar 'open_mutex'.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md: corrige kmemleak de rdev->serial Si kobject_add() falla en bind_rdev_to_array(), 'rdev->serial' se asignará y no se liberará, y se produce kmemleak. objeto sin referencia 0xffff88815a350000 (tamaño 49152): comm "mdadm", pid 789, jiffies 4294716910 volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso (crc f773277a): [<0000000058b0a453> ] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] loc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [< 0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [< 0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<00000 0008b0ad622>] entrada_SYSCALL_64_after_hwframe+0x6c/0x74

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: do_sys_name_to_handle(): use kzalloc() para reparar kernel-infoleak syzbot identificó una vulnerabilidad de fuga de información del kernel en do_sys_name_to_handle() y emitió el siguiente informe [1]. [1] "ERROR: KMSAN: kernel-infoleak en instrument_copy_to_user include/linux/instrumented.h:114 [en línea] ERROR: KMSAN: kernel-infoleak en _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/ instrumented.h:114 [en línea] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [en línea] do_sys_name_to_handle fs/fhandle.c:73 [en línea] __do_sys_name_to_handle_at fs/fhandle.c :112 [en línea] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit se creó en: slab_post_alloc_hook+0x129/0xa70 mm/slab.h: 768 losa_alloc_nodo mm/slub.c:3478 [en línea] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [en línea] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/ slab.h:604 [en línea] do_sys_name_to_handle fs/fhandle.c:39 [en línea] __do_sys_name_to_handle_at fs/fhandle.c:112 [en línea] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 _handle_at+0xe4/0x140 fs/fhandle .c:94 ... Los bytes 18-19 de 20 no están inicializados El acceso a la memoria de tamaño 20 comienza en ffff888128a46380 Datos copiados a la dirección de usuario 0000000020000240" Según la sugerencia de Chuck Lever, use kzalloc() en lugar de kmalloc() para resolver el problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath9k: retrasa todo ath9k_wmi_event_tasklet() hasta que se complete el inicio. El ath9k_wmi_event_tasklet() usado en ath9k_htc supone que todas las estructuras de datos se han inicializado por completo en el momento de su ejecución. Sin embargo, debido al orden en que se inicializan las cosas, no se garantiza que este sea el caso, porque el dispositivo queda expuesto al subsistema USB antes de que se complete la inicialización del controlador ath9k. Ya cometimos una solución parcial para esto en la confirmación: 8b3046abc99e ("ath9k_htc: corrige la desreferencia del puntero NULL en ath9k_htc_tx_get_packet()") Sin embargo, esa confirmación solo abortó el comando WMI_TXSTATUS_EVENTID en el tasklet de eventos, emparejándolo con un bit de "inicialización completa" en la estructura TX. Parece que syzbot también logró activar la carrera para uno de los otros comandos, así que simplemente movamos el bit de sincronización existente para cubrir todo el tasklet (configurándolo al final de ath9k_htc_probe_device() en lugar de dentro de ath9k_tx_init()).

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/bridge: adv7511: corrige el fallo en irq durante la sonda Se movió el registro de IRQ al final de adv7511_probe(). Si ya hay una IRQ pendiente durante adv7511_probe (antes de adv7511_cec_init), entonces cec_received_msg_ts podría fallar usando datos no inicializados: No se puede manejar la lectura del kernel desde memoria ilegible en la dirección virtual 00000000000003d5 Error interno: Ups: 96000004 [#1] PREEMPT_RT SMP Seguimiento de llamadas: _ts+0x48 /0x990 [cec] adv7511_cec_irq_process+0x1cc/0x308 [adv7511] adv7511_irq_process+0xd8/0x120 [adv7511] adv7511_irq_handler+0x1c/0x30 [adv7511] irq_thread_fn+0x30/0xa0 leer+0x14c/0x238 khilo+0x190/0x1a8

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cuota: corrige una posible desreferencia del puntero NULL La siguiente carrera puede causar una desreferencia del puntero NULL P1 P2 dquot_free_inode quote_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[tipo] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... Si dquot_free_inode(u otras rutinas) verifica los punteros de cuota del inodo (1) antes de que cuota_off lo establezca a NULL(2) y usarlo (3) después de eso, se activará la desreferencia del puntero NULL. Entonces, solucionémoslo usando un puntero temporal para evitar este problema.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: clk: meson: Agregar relojes faltantes a axg_clk_regmaps Faltaban algunos relojes en axg_clk_regmaps, lo que provocó pánico en el kernel durante cat /sys/kernel/debug/clk/clk_summary [ 57.349402] No se puede manejar Kernel Null Pointer Derferencia en la dirección virtual 0000000000000001FC ... [57.430002] PState: 6000000005 (NZCV DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE = -) [57.436900] PC: RegMap_read+0x1c/0x888 [57.44060608] CLK_REGMAP_GATE_IS_Enabled+0x3c/0xb0 [57.445611] SP: FFFFF800082F1B690 [57.448888] x29: ffff800082f1b690 x28: 0000000000000000000000000000808080B9A70 [57. 000000000007 x25: 000000000000000016 X24: 000000000000000000 [57.463033] X23: FFFF800080E8B488 X22: 000000000000000015 X21: FFFFFF00000E7E7000 [57.470106] X20: FFFF00000400EC00 X19: 000000000000000000 X18: FFFFFFFFFFFFFFF [57.477178] x17: 00000000000000000000000016: 000000000000000000 X15: FFFFFFFF0000042A3000 [57.484251] X14 2fec x12: 000000000005F5E100 [57.491323] x11: ABCC77118461CEFD x10: 0000000000000020 X9: FFFF8000805E4B24 [57.498396] x8: FFFF0000028063C0 X7: FFFF800082F1B710 X6: FFFF800082F1B710 [57.505468] x5: 0000000000ffffd0 x4: ffffff800082f1b6e0 x3: 00000000001000 [57.512541] 0000000000012C x0: 000000000000000000 [57.519615] Traza de llamada: [57.522030] regMap_read+0x1c/0x88 [57.525393] clk_regmap_gate_is_enabled+ 0x3c/0xb0 [ 57.530050] clk_core_is_enabled+0x44/0x120 [ 57.534190] clk_summary_show_subtree+0x154/0x2f0 [ 57.538847] clk_summary_show_subtree+0x220/0x2f0 [ 57.543505 ] clk_summary_show_subtree+0x220/0x2f0 [ 57.548162] clk_summary_show_subtree+0x220/0x2f0 [ 57.552820] clk_summary_show_subtree+0x220/ 0x2f0 [ 57.557477] clk_summary_show_subtree+0x220/0x2f0 [ 57.562135] clk_summary_show_subtree+0x220/0x2f0 [ 57.566792] clk_summary_show_subtree+0x220/0x2f0 [ 57.571450] cl k_summary_show+0x84/0xb8 [ 57.575245] seq_read_iter+0x1bc/0x4b8 [ 57.578954] seq_read+0x8c/0xd0 [ 57.582059] full_proxy_read+0x68/0xc8 [ 57.585767] vfs_read+0xb0/0x268 [ 57.588959] ksys_read+0x70/0x108 [ 57.592236] __arm64_sys_read+0x24/0x38 [ 57.59 6031] invoke_syscall+0x50/0x128 [ 57.599740] el0_svc_common.constprop.0+0x48/ 0xf8 [ 57.604397] do_el0_svc+0x28/0x40 [ 57.607675] el0_svc+0x34/0xb8 [ 57.610694] el0t_64_sync_handler+0x13c/0x158 [ 57.615006] /0x198 [ 57.618635] Código: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00) [ 57.624668] -- -[ seguimiento final 0000000000000000 ]--- [jbrunet: agregar etiqueta de correcciones faltantes]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: paquete: anotar carreras de datos alrededor de ignore_outgoing ignore_outgoing se lee sin bloqueo desde dev_queue_xmit_nit() y paquete_getsockopt() Agregue las anotaciones READ_ONCE()/WRITE_ONCE() apropiadas. syzbot informó: ERROR: KCSAN: carrera de datos en dev_queue_xmit_nit/packet_setsockopt escribir en 0xffff888107804542 de 1 bytes por tarea 22618 en la CPU 0: paquete_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003 do_sock_setsockopt net/socket.c :2311 [ en línea] __sys_setsockopt+0x1d8/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [en línea] __se_sys_setsockopt net/socket.c:2340 [en línea] __x64_sys_setsockopt+0x66/0x80 :2340 do_syscall_64+ 0xd3/0x1d0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 leído en 0xffff888107804542 de 1 byte por tarea 27 en la CPU 1: dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248 xmit_one net/core/dev.c:3527 línea] dev_hard_start_xmit+ 0xcc/0x3f0 net/core/dev.c:3547 __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [en línea] batadv_send_skb_packet+0x264/0x300 net/batman-adv/ send.c:108 batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [en línea] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [en línea ] batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700 Process_one_work kernel/workqueue.c:3254 [en línea] Process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335 trabajador_thread+0x526/0x730 núcleo/cola de trabajo.c :3416 kthread+0x1d1/0x210 kernel/kthread.c:388 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 valor cambiado: 0x00 -> 0x01 Reportado por Kernel Concurrency Sanitizer en: CPU: 1 PID: 27 Comm: kworker/u8:1 Contaminado: GW 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 29/02/2024 Cola de trabajo: bat_events batadv_iv_send_outstanding_bat_ogm_packet

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hsr: corrigió el acceso a valores uninit en hsr_get_node() KMSAN informó el siguiente problema de acceso a valores uninit [1]: ============== ======================================= ERROR: KMSAN: valor uninit en hsr_get_node+0xa2e /0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [en línea] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c :615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c :3548 [en línea] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [en línea] paquete_xmit+0x9c/ 0x6b0 net/packet/af_packet.c:276 paquete_snd net/packet/af_packet.c:3087 [en línea] paquete_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg neto /socket.c:745 [en línea] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [en línea] __se_sys_sendto net/socket.c:2199 [en línea] __x64_sys_sendto+0x125/0x1c0 socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit se creó en slab_post_alloc_hook+0x129/ 0xa70 mm/slab.h: 768 slab_alloc_node mm/slub.c: 3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c: 3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c: 560 __b.biloc. 740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [en línea] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 paquete_alloc_skb net/packet/af_packet.c:2936 [en línea] paquete_snd net/packet/af_packet.c:3030 [en línea] paquete_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [en línea ] __sock_sendmsg net/socket.c:745 [en línea] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [en línea] __se_sys_sendto net/socket.c:2199 [en línea] x125/ 0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 ============== ======================================== Si el campo ID de tipo de paquete en el encabezado Ethernet es ETH_P_PRP o ETH_P_HSR, pero no va seguido de una etiqueta HSR, hsr_get_skb_sequence_nr() lee un valor no válido como un número de secuencia. Esto causa el problema anterior. Este parche soluciona el problema al devolver NULL si el encabezado Ethernet no va seguido de una etiqueta HSR.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: corrige el manejo de refcnt en __inet_hash_connect(). syzbot informó una advertencia en sk_nulls_del_node_init_rcu(). La confirmación 66b60b0c8c4a ("dccp/tcp: Unhash sk de ehash para falla de asignación de tb2 después de check_estalblished().") intentó solucionar un problema por el cual un socket no conectado ocupa una entrada de ehash cuando falla la asignación de bhash2. En tal caso, necesitamos revertir los cambios realizados por check_establecido(), que no retiene refcnt al insertar el socket en ehash. Entonces, para revertir el cambio, necesitamos __sk_nulls_add_node_rcu() en lugar de sk_nulls_add_node_rcu(). De lo contrario, sock_put() provocará un desbordamiento insuficiente y filtrará el socket. [0]: ADVERTENCIA: CPU: 0 PID: 23948 en include/net/sock.h:799 sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799 Módulos vinculados en: CPU: 0 PID: 23948 Comm: syz- executor.2 No contaminado 6.8.0-rc6-syzkaller-00159-gc055fc00c07b #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 RIP: 0010:sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/ calcetín.h:799 Código: e8 7f 71 c6 f7 83 fb 02 7c 25 e8 35 6d c6 f7 4d 85 f6 0f 95 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 1b 6d c6 f7 90 < 0f> 0b 90 eb b2 e8 10 6d c6 f7 4c 89 e7 be 04 00 00 00 e8 63 e7 d2 RSP: 0018:ffffc900032d7848 EFLAGS: 00010246 RAX: ffffffff89cd0035 RBX: 00001 RCX: 0000000000040000 RDX: ffffc90004de1000 RSI: 000000000003ffff RDI: 0000000000040000 RBP : 1ffff1100439ac26 R08: ffffffff89ccffe3 R09: 1ffff1100439ac28 R10: dffffc0000000000 R11: ffffed100439ac29 R12: ffff888021cd6140 R13: dffffc0000000000 ff ff88802a9bf5c0 R15: ffff888021cd6130 FS: 00007f3b823f16c0(0000) GS:ffff8880b9400000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3b823f0ff8 CR3: 000000004674a000 CR4: 00000000003506f0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __inet_hash_connect+0x140f/0x20b0 net/ipv4/inet_hashtables.c:1139 dccp_v6_connect+0xcb9/0x1480 net/dccp/ipv6.c:956 __inet_stream_connect+0x262/0xf30 net/ipv4/af_inet.c:678 inet_stream_connect+0x65/0xa0 net/ipv4/af_inet.c:749 __sys_connect_file net/socket.c:2048 [en línea] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [en línea] __se_sys_connect net/socket.c:2072 [en línea] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 +0xf9/0x240 Entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f3b8167dda9 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 4 8 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3b823f10c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 00007f3b817abf80 RCX : 00007f3b8167dda9 RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007f3b823f1120 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000000b R14: 00007f3b817abf80 00007ffd3beb57b8