Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: auditoría: mejora la solidez del manejo de la cola de auditoría. Si el daemon de auditoría alguna vez se atascara en un estado detenido, kauditd_thread() del kernel podría bloquearse al intentar enviar registros de auditoría al espacio de usuario. daemon de auditoría. Con el subproceso del núcleo bloqueado, es posible que la cola de auditoría crezca sin límites, ya que ciertos eventos que generan registros de auditoría deben estar exentos de los límites de la cola, de lo contrario, el sistema entrará en un estado de bloqueo. Este parche resuelve este problema reduciendo el tiempo de espera de envío del socket del subproceso del núcleo de MAX_SCHEDULE_TIMEOUT a HZ/10 y modifica la función kauditd_send_queue() para gestionar mejor las distintas colas de auditoría cuando se producen problemas de conexión entre el núcleo y el daemon de auditoría. Con este parche, el trabajo pendiente puede crecer temporalmente más allá de los límites definidos cuando se detiene el daemon de auditoría y el sistema está bajo una fuerte presión de auditoría, pero kauditd_thread() continuará progresando y drenando las colas como lo haría con otros problemas de conexión. Por ejemplo, con el daemon de auditoría en estado detenido y el sistema configurado para auditar cada llamada al sistema, aún era posible apagar el sistema sin pánico en el kernel, interbloqueo, etc.; Por supuesto, el sistema tardó en cerrarse, pero eso es de esperarse dada la presión extrema de registrar cada llamada al sistema. El valor de tiempo de espera de HZ/10 se eligió principalmente a través de la experimentación y el "instinto" de este desarrollador. Probablemente no exista un valor perfecto, pero como este escenario tiene un alcance limitado (se necesitarían privilegios de root para enviar SIGSTOP al daemon de auditoría), probablemente no valga la pena exponerlo como un ajuste ajustable en este momento. Esto siempre se puede hacer en una fecha posterior si resulta necesario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vduse: verifique que el desplazamiento esté dentro de los límites en get_config() Esta condición verifica "len" pero no verifica "desplazamiento" y eso podría resultar en una lectura fuera de los límites si " desplazamiento > dev->config_size". El problema es que, dado que ambas variables no están firmadas, la resta "dev->config_size - offset" daría como resultado un valor sin firmar muy alto. Creo que estas comprobaciones podrían no ser necesarias porque se supone que "len" y "offset" ya se han validado mediante la función vhost_vdpa_config_validate(). Pero no conozco el código a la perfección y me gusta estar seguro.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: corrige la pérdida de memoria en __add_inode_ref() La línea 1169 (#3) asigna un fragmento de memoria para victim_name mediante kmalloc(), pero cuando la función regresa en la línea 1184 (#4) victim_name asignado por la línea 1169 (#3) no se libera, lo que provocará una pérdida de memoria. Hay un fragmento de código similar en esta función para asignar un fragmento de memoria para victim_name en la línea 1104 (n.º 1), así como para liberar la memoria en la línea 1116 (n.º 2). Deberíamos kfree() victim_name cuando el valor de retorno de backref_in_log() sea menor que cero y antes de que la función regrese en la línea 1184 (#4). 1057 static inline int __add_inode_ref(struct btrfs_trans_handle *trans, 1058 struct btrfs_root *root, 1059 struct btrfs_path *path, 1060 struct btrfs_root *log_root, 1061 struct btrfs_inode *dir, 1062 struct btrfs_inode *inode, 63 u64 inode_objectid, u64 parent_objectid, 1064 u64 ref_index, char *nombre, int nombrelen, 1065 int *search_done) 1066 { 1104 nombre_víctima = kmalloc(nombre_víctima_len, GFP_NOFS); // #1: kmalloc (nombre_víctima-1) 1105 if (!nombre_víctima) 1106 return -ENOMEM; 1112 ret = backref_in_log(log_root, &search_key, 1113 parent_objectid, victim_name, 1114 victim_name_len); 1115 if (ret < 0) { 1116 kfree(nombre_víctima); // #2: kfree (nombre_víctima-1) 1117 return ret; 1118 } else if (!ret) { 1169 nombre_víctima = kmalloc(nombre_víctima_len, GFP_NOFS); // #3: kmalloc (nombre_víctima-2) 1170 if (!nombre_víctima) 1171 return -ENOMEM; 1180 ret = backref_in_log(log_root, &search_key, 1181 parent_objectid, victim_name, 1182 victim_name_len); 1183 si (ret < 0) { 1184 retorno ret; // #4: falta kfree (nombre_víctima-2) 1185 } else if (!ret) { 1241 return 0; 1242 }

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: dwmac-rk: fix oob read in rk_gmac_setup KASAN informa una lectura fuera de los límites en rk_gmac_setup en la línea: while (ops->regs[i]) { Esto sucede en la mayoría de las plataformas, ya que el miembro de la matriz flexible regs está vacío, por lo que aquí se lee la memoria después de la estructura de operaciones. Parece que la mayor parte de esto contiene cero de todos modos, así que tenemos suerte y todo sigue funcionando. Para evitar agregar datos redundantes a casi todas las estructuras de operaciones, agregue un nuevo indicador para indicar si el campo regs es válido y evite este bucle cuando no lo sea.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: systemport: agregue bloqueo global para el ciclo de vida del descriptor. La lista de descriptores es un recurso compartido entre todas las colas de transmisión y el mecanismo de bloqueo que se usa hoy solo protege la concurrencia en una cola de transmisión determinada. entre la transmisión y la recuperación. Esto crea una oportunidad para que el hardware de SYSTEMPORT funcione con descriptores corruptos si tenemos varios productores a la vez, como es el caso cuando utilizamos varias colas de transmisión. Esto fue particularmente notable cuando se usaban múltiples flujos/colas de transmisión y se mostró de manera interesante en que los paquetes UDP obtendrían una suma de verificación de encabezado UDP correcta al calcularse sobre una longitud de paquete incorrecta. De manera similar, los paquetes TCP obtendrían una suma de verificación igualmente correcta calculada por el hardware en una longitud de paquete incorrecta. El hardware de SYSTEMPORT mantiene una lista de descriptores internos que reorganiza cuando el controlador produce un nuevo descriptor cada vez que escribe en los registros WRITE_PORT_{HI,LO}. Sin embargo, hay cierto retraso en el hardware para reorganizar sus descriptores y es Es posible que las colas de TX simultáneas eventualmente rompan este esquema de asignación interna hasta el punto en que la parte de longitud/estado del descriptor se use para un búfer de datos incorrecto. La solución es imponer una serialización global para todas las colas de TX en la sección corta donde escribimos en los registros WRITE_PORT_{HI,LO}, lo que resuelve la corrupción incluso cuando se utilizan varias colas de TX simultáneas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sit: no llame a ipip6_dev_free() desde sit_init_net() ipip6_dev_free es sit dev->priv_destructor, ya llamado por Register_netdevice() si algo sale mal. La alternativa sería hacer que ipip6_dev_free() sea robusto contra múltiples invocaciones, pero otros controladores no implementan esta estrategia. syzbot informó: dst_release underflow ADVERTENCIA: CPU: 0 PID: 5059 en net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173 Módulos vinculados en: CPU: 1 PID: 5059 Comm: syz -executor.4 Not tainted 5.16.0-rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c :173 Código: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48 RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246 RAX: d6894a925dd15a00 RBX: RCX: 0000000000040000 RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: 0000000000000000 R08 : ffffffff816a1f42 R09: ffffed1017344f2c R10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358 R13: 1ffffffff1bfd305 R14: ffffe8ffffcb135 8 R15: dffffc0000000000 FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 50033 CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160 ipip6_dev_free net/ ipv6/sit.c:1414 [en línea] sit_init_net+0x229/0x550 net/ipv6/sit.c:1936 ops_init+0x313/0x430 net/core/net_namespace.c:140 setup_net+0x35b/0x9d0 net/core/net_namespace.c :326 copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470 create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226 ksys_unshare+0x57d/0xb50 .c :3075 __do_sys_unshare kernel/fork.c:3146 [en línea] __se_sys_unshare kernel/fork.c:3144 [en línea] __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144 do_syscall_x64 arch/x86/entry/common.c:50 [en línea ] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f66c882ce99 Código: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 1f 40 00 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 bc ff ff ff f7 d8 64 89 01 48 RSP:00 007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99 RDX: 0000000000000000 RSI: 0000000000 000000 RDI: 0000000048040200 RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000 00246 R12: 0000000000000000 R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igbvf: corrige double free en `igbvf_probe` En `igbvf_probe`, si Register_netdev() falla, el programa irá a la etiqueta err_hw_init y luego a la etiqueta err_ioremap. En free_netdev(), que está justo debajo de la etiqueta err_ioremap, están `list_for_each_entry_safe` y `netif_napi_del` que tienen como objetivo eliminar todas las entradas en `dev->napi_list`. El programa ha agregado una entrada `adapter->rx_ring->napi` que se agrega mediante `netif_napi_add` en igbvf_alloc_queues(). Sin embargo, adaptador->rx_ring se ha liberado debajo de la etiqueta err_hw_init. Entonces esto es una UAF. En términos de cómo solucionar el problema, podemos consultar igbvf_remove() y eliminar la entrada antes de `adapter->rx_ring`. Los registros de KASAN son los siguientes: [35.126075] ERROR: KASAN: use-after-free en free_netdev+0x1fd/0x450 [35.127170] Lectura de tamaño 8 en la dirección ffff88810126d990 mediante la tarea modprobe/366 [35.128360] [35.128643] CPU: 1 PID : 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14 [ 35.129789] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01 /2014 [35.131749] Seguimiento de llamadas: [35.132199] dump_stack_lvl+0x59/0x7b [35.132865] print_address_description+0x7c/0x3b0 [35.133707] ? free_netdev+0x1fd/0x450 [ 35.134378] __kasan_report+0x160/0x1c0 [ 35.135063] ? free_netdev+0x1fd/0x450 [ 35.135738] kasan_report+0x4b/0x70 [ 35.136367] free_netdev+0x1fd/0x450 [ 35.137006] igbvf_probe+0x121d/0x1a10 [igbvf] [ 35.137808 ] ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf] [ 35.138751] local_pci_probe+0x13c/0x1f0 [ 35.139461] pci_device_probe+0x37e/0x6c0 [ 35.165526] [ 35.165806] por tarea 366: [35.166414] ____kasan_kmalloc+0xc4/0xf0 [35.167117] foo_kmem_cache_alloc_trace+0x3c/ 0x50 [igbvf] [ 35.168078] igbvf_probe+0x9c5/0x1a10 [igbvf] [ 35.168866] local_pci_probe+0x13c/0x1f0 [ 35.169565] pci_device_probe+0x37e/0x6c0 [ 35.179713 ] [35.179993] Liberado por la tarea 366: [35.180539] kasan_set_track+0x4c/0x80 [ 35.181211] kasan_set_free_info+0x1f/0x40 [ 35.181942] ____kasan_slab_free+0x103/0x140 [ 35.182703] kfree+0xe3/0x250 [ 35.183239] igbvf_probe+0x1173/0x1a10 vf] [35.184040] local_pci_probe+0x13c/0x1f0

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mptcp: corrige el punto muerto en __mptcp_push_pending() __mptcp_push_pending() puede llamar a mptcp_flush_join_list() con el bloqueo del socket de subflujo retenido. Si dicha llamada llega a mptcp_sockopt_sync_all(), posteriormente __mptcp_sockopt_sync() podría intentar bloquear el socket de subflujo por sí mismo, provocando un punto muerto. sysrq: Mostrar estado bloqueado tarea: estado del servidor ss: D pila: 0 pid: 938 ppid: 1 banderas: 0x00000000 Seguimiento de llamadas: __schedule+0x2d6/0x10c0? __mod_memcg_state+0x4d/0x70 ? csum_partial+0xd/0x20? _raw_spin_lock_irqsave+0x26/0x50 horario+0x4e/0xc0 __lock_sock+0x69/0x90 ? do_wait_intr_irq+0xa0/0xa0 __lock_sock_fast+0x35/0x50 mptcp_sockopt_sync_all+0x38/0xc0 __mptcp_push_pending+0x105/0x200 mptcp_sendmsg+0x466/0x490 sock_sendmsg+0x57/0x60 __sys_sendto+0xf0/0x160? do_wait_intr_irq+0xa0/0xa0? fpregs_restore_userregs+0x12/0xd0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x38/0x90 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f9ba546c2d0 RSP: dc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0 RDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234 RBP: 0000000000cc57f0 R08: 0000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060 R13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8 Solucione el problema usando __mptcp_flush_join_list() en su lugar de mptcp_flush_join_list() simple dentro __mptcp_push_pending(), como sugiere Florian. La sincronización de sockopt se aplazará a la cola de trabajo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mptcp: elimina el soporte de tcp ulp setsockopt TCP_ULP setsockopt no se puede usar para mptcp porque ya se usa internamente para conectar sockets de subflujo (tcp) a la capa mptcp. syzbot logró desencadenar un bloqueo para las conexiones mptcp que están en modo alternativo: KASAN: null-ptr-deref en el rango [0x0000000000000020-0x0000000000000027] CPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2- syzkaller #0 RIP: 0010:tls_build_proto net/tls/tls_main.c:776 [en línea] [..] __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [en línea] tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c: 160 do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391 mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638 Elimina la compatibilidad con TCP_ULP setsockopt.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: stmmac: corrija la eliminación de flores tc para la dirección Rx con prioridad de VLAN Para replicar el problema: - 1) Agregue 1 filtro de flores para la dirección de cuadros basada en prioridad de VLAN: - $ IFDEVNAME=eth0 $ tc qdisc agregar dev $IFDEVNAME ingreso $ tc qdisc agregar dev $IFDEVNAME raíz mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0 0 \ colas 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc filter add dev $IFDEVNAME parent ffff: protocolo 802.1Q \ flower vlan_prio 0 hw_tc 0 2) Obtener el id 'pref' $ tc filter show dev $IFDEVNAME ingress 3 ) Eliminar un registro de flor tc específico (digamos pref 49151) $ tc filter del dev $IFDEVNAME parent ffff: pref 49151 Desde dmesg, observaremos el puntero NULL del kernel ooops [ 197.170464] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000000 [ 197.171367] #PF: acceso de lectura de supervisor en modo kernel [ 197.171367] #PF: error_code(0x0000) - página no presente [ 197.171367] PGD 0 P4D 0 [ 197.171367] Ups: 0000 [#1] PREEMPT SMP NOPTI [ 197.171367] RIP: 0010:tc_setup_cls+0x20b/0x4a0 [stmmac] [ 197.171367] Seguimiento de llamadas: [ 197.171367] [ 197.171367] ? __stmmac_disable_all_queues+0xa8/0xe0 [stmmac] [ 197.171367] stmmac_setup_tc_block_cb+0x70/0x110 [stmmac] [ 197.171367] tc_setup_cb_destroy+0xb3/0x180 [ 197.171367] destroy_filter+0x94/0xc0 [cls_flower] El problema anterior se debe a una implementación anterior incorrecta de tc_del_vlan_flow( ), que se muestra a continuación, que usa flow_cls_offload_flow_rule() para obtener la estructura flow_rule *rule que ya no es válida para la operación de eliminación del filtro tc. estructura flow_rule *regla = flow_cls_offload_flow_rule(cls); estructura flow_dissector *dissector = regla->match.dissector; Por lo tanto, para garantizar que tc_del_vlan_flow() elimine el registro VLAN cls correcto para la cola RX configurada anteriormente (configurada por hw_tc) en tc_add_vlan_flow(), este parche introduce stmmac_rfs_entry como registro flow_cls_offload del lado del controlador para la flor tc 'Dirección de trama RX', actualmente utilizada para Prioridad de VLAN. La implementación ha tenido en cuenta una futura ampliación para incluir otro tipo de dirección de bastidor RX, como la basada en EtherType. v2: - Limpiar el rastreo demasiado extenso y reescribir el mensaje de git para explicar mejor el problema del puntero NULL del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: borrar el indicador 'kern' de los sockets de reserva La extensión mptcp ULP depende de que sk->sk_sock_kern esté configurado correctamente: impide que setsockopt(fd, IPPROTO_TCP, TCP_ULP, "mptcp", 6); de funcionar para sockets tcp simples (cualquier socket expuesto al espacio de usuario). Pero en caso de respaldo, aceptar() puede devolver un sk tcp simple. En tal caso, sk todavía está etiquetado como 'kernel' y setsockopt funcionará. Esto bloqueará el kernel. La extensión de subflujo tiene un socket NULL ctx->conn mptcp: ERROR: KASAN: null-ptr-deref en subflow_data_ready+0x181/0x2b0 Seguimiento de llamadas: tcp_data_ready+0xf8/0x370 [..]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: nunca permitir que el PM cierre un subflujo de escucha Actualmente, al eliminar un endpoint, el PM de netlink atraviesa todos los sockets MPTCP locales, independientemente de su estado. Si un socket de escucha MPTCP está vinculado a la IP que coincide con el endpoint de eliminación, el socket TCP de escucha se cerrará. Esto es inesperado, el PM solo debería afectar los subflujos de datos. Además, syzbot pudo activar una desreferencia de ptr NULL debido a lo anterior: falla de protección general, probablemente para la dirección no canónica 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref en el rango [0x0000000000000018-0x0000000000000001f] CPU: 1 PID: 6550 Comm: syz-executor122 No contaminado 5.16.0-rc4-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897 Código: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff RSP: 0018:ffffc90001f2f818 EFLAGS: 00010016 RAX: 00 RBX: 0000000000000018 RCX: 0000000000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 000000000000000 a R12: 0000000000000000 R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001 FS: 00007f177cd3d700(0000) GS:ffff8880b9d00000 (0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0 Seguimiento de llamadas: lock_acquire kernel/locking/lockdep.c:5637 [en línea] +0x1ab/0x510 kernel/locking/lockdep.c:5602 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [en línea] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162 Finish_wait+0xc0/0x270 kernel/sched/wait.c:400 inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [en línea] inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497 mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865 inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739 e7/0x10e0 net/mptcp/protocol.c:3345 do_accept+0x382/0x510 net/socket.c:1773 __sys_accept4_file+0x7e/0xe0 net/socket.c:1816 __sys_accept4+0xb0/0x100 net/socket.c:1846 __do_sys_accept net/socket. c:1864 [en línea] __se_sys_accept net/socket.c:1861 [en línea] __x64_sys_accept+0x71/0xb0 net/socket.c:1861 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x35/0xb0 arch /x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f177cd8b8e9 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 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:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b RAX : ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f177 ce13400 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c R13: cde1004 R14: 6d705f706374706d R15: 0000000000022000 Arreglar el problema al omitir explícitamente el socket MPTCP en el estado TCP_LISTEN.