Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/mm: no permitir la lectura de la página vsyscall para copy_from_kernel_nofault() Al intentar usar copy_from_kernel_nofault() para leer la página vsyscall a través de un programa bpf, se informó lo siguiente: ERROR: no se puede manejar el error de página para la dirección: ffffffffff600000 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0 Ups: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996) ...... RIP: 0010:copy_from_kernel_nofault+0x6f/0x110... ... Seguimiento de llamadas: ? copy_from_kernel_nofault+0x6f/0x110 bpf_probe_read_kernel+0x1d/0x50 bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d trace_call_bpf+0xc5/0x1c0 perf_call_bpf_enter.isra.0+0x69/0xb 0 perf_syscall_enter+0x13e/0x200 syscall_trace_enter+0x188/0x1c0 do_syscall_64+0xb5/0xe0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 < /TASK> ...... ---[ end trace 0000000000000000 ]--- Ups se activa cuando: 1) Un programa bpf usa bpf_probe_read_kernel() para leer desde la página vsyscall e invoca copy_from_kernel_nofault() que a su vez llama __get_user_asm(). 2) Debido a que la dirección de la página vsyscall no se puede leer desde el espacio del kernel, se activa una excepción de error de página en consecuencia. 3) handle_page_fault() considera la dirección de la página vsyscall como una dirección de espacio de usuario en lugar de una dirección de espacio de kernel. Esto da como resultado que no se aplique la configuración de reparación mediante bpf y se invoque page_fault_oops() debido a SMAP. Teniendo en cuenta que handle_page_fault() ya ha considerado la dirección de la página vsyscall como una dirección de espacio de usuario, solucione el problema no permitiendo la lectura de la página vsyscall para copy_from_kernel_nofault().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/mlx5: corrige la advertencia de fuente de fortify al acceder al segmento Eth ------------[ cortar aquí ]---------- -- memcpy: se detectó escritura que abarca todos los campos (tamaño 56) de un solo campo "eseg->inline_hdr.start" en /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/ wr.c:131 (tamaño 2) ADVERTENCIA: CPU: 0 PID: 293779 en /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+ 0x191b/0x1a60 [mlx5_ib] Módulos vinculados en: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) ) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd gracia sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover disquete de conmutación por error [última descarga : mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Contaminado: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Nombre de hardware: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Código: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 00000000000000000 R10: 0000000000000000 R11 : 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) 63a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 00000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? show_regs+0x72/0x90? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __advertir+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0? handle_bug+0x46/0x90? exc_invalid_op+0x19/0x80? asm_exc_invalid_op+0x1b/0x20? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] 8e/0x1e0 ? validar_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 _push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/xen: agregue alguna verificación de puntero nulo a smp.c kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free Una serie reciente de DRM que pretende simplificar el soporte para "puentes transparentes" y el manejo de aplazamientos de sonda expuso irónicamente un uso posterior -Problema gratuito en el aplazamiento de la sonda pmic_glink_altmode. Esto se ha manifestado como que el subsistema de visualización ocasionalmente falla al inicializarse y se eliminan las referencias del puntero NULL durante el arranque de máquinas como la Lenovo ThinkPad X13s. Específicamente, el puente dp-hpd actualmente está registrado antes de que se hayan adquirido todos los recursos, lo que significa que también se puede cancelar su registro en caso de aplazamientos de sonda. Mientras tanto, hay una ventana de carrera donde el nuevo controlador del puente auxiliar (o el controlador PHY anteriormente) puede haber buscado el puente dp-hpd y almacenado un puntero (sin recuento de referencias) al puente que está a punto de ser desasignado. Cuando el controlador de pantalla se inicializa posteriormente, esto activa un use-after-free al conectar los puentes: dp -> aux -> dp-hpd (liberado) que puede, por ejemplo, provocar que el puente liberado no se pueda conectar: [drm :drm_bridge_attach [drm]] *ERROR* no se pudo adjuntar el puente /soc@0/phy@88eb000 al codificador TMDS-31: -16 o una desreferencia de puntero NULL: no se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000000... Seguimiento de llamadas: drm_bridge_attach+0x70/0x1a8 [drm] drm_aux_bridge_attach+0x24/0x38 [aux_bridge] drm_bridge_attach+0x80/0x1a8 [drm] dp_bridge_init+0xa8/0x15c [msm] msm_dp_modeset_init+0x28/0xc4 [msm] El puente DRM la implementación es claramente frágil e implícitamente construido sobre el supuesto de que es posible que los puentes nunca desaparezcan. En este caso, la solución es mover el registro del puente en el controlador pmic_glink_altmode después de que se hayan buscado todos los recursos. Por cierto, con la nueva implementación del puente dp-hpd, que registra dispositivos secundarios, esto también es un requisito debido a un problema de larga data en el núcleo del controlador que, de lo contrario, puede provocar un bucle de aplazamiento de la sonda (consulte el compromiso fbc35b45f9f6 ("Agregar documentación sobre el significado de -EPROBE_DEFER")). [DB: mensaje de confirmación ligeramente corregido agregando la palabra 'compromiso']

Se encontró una vulnerabilidad en Tenda AC500 2.0.1.9(1307). Ha sido clasificada como crítica. Esto afecta a la función R7WebsSecurityHandler del archivo /goform/execCommand. La manipulación del argumento contraseña provoca un desbordamiento de búfer en la región stack de la memoria. Es posible iniciar el ataque de forma remota. El exploit ha sido divulgado al público y puede utilizarse. A esta vulnerabilidad se le asignó el identificador VDB-261141. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

Se encontró una vulnerabilidad en Tenda AC500 2.0.1.9(1307). Ha sido declarada crítica. Esta vulnerabilidad afecta a la función formQuickIndex del archivo /goform/QuickIndex. La manipulación del argumento PPPOEPassword provoca un desbordamiento de búfer en la región stack de la memoria. El ataque se puede iniciar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. VDB-261142 es el identificador asignado a esta vulnerabilidad. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: soluciona el fallo del kernel cuando se recibe 1588 en dispositivos HIP08 Los dispositivos HIP08 no registran los dispositivos ptp, por lo que hdev->ptp es NULL, pero el hardware puede recibir 1588 y configure el bit HNS3_RXD_TS_VLD_B, por lo que, si coincide con este caso, el acceso a hdev->ptp->flags provocará una falla del kernel: [5888.946472] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000018 [5888.946475] No se puede para manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000018 ... [ 5889.266118 ] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 ge] [5889.279101] sp: ffff800012c3bc50 [5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040 [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500 [ 5889.296333] x25: 0000000000000000 x24 : ffff204001c6f000 [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000 [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080 [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000 [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000 [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000 [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df [5889.340965] x11: bbfeff4d22000000 x10: 00000000000000000 [5889.347303] x9: ffff8000094021 24 x8: 0200f78811dfbb4d [5889.353637] x7: 2200000000191b01 x6: FFFF208002A7D480 [5889.359959] x5: 000000000000000000 X4: 0000000000000000 [5889.366271] x3: 0000000000000000 X2: 00000000000000000000000000000000000000000000000000 ABRIBA 80 [5889.378857] Lista de llamada: [5889.382285] HCLGE_PTP_GET_RX_HWTS+0x40/0x170 [HCLGE] [5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3] [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3] [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3] [ 0] hns3_nic_common_poll+0xa8/0x220 [hns3] [ 5889.411084] napi_poll+0xcc/0x264 [ 5889.415329] net_rx_action+0xd4/0x21c [ 5889.419911] __do_softirq+0x130/0x358 [ 5889.424484] irq_exit+0x134/0x154 [ 5889.428700] 0xf0 [ 5889.433684] gic_handle_irq+0x78/0x2c0 [ 5889.438319] el1_irq+0xb8/0x140 [ 5889.442354] arch_cpu_idle+0x18/0x40 [ 5889.446816] default_idle_call+0x5c/0x1c0 [ 5889.451714] cpuidle_idle_call+0x174/0x1b0 [ 5889.456692] do_idle+0xc8/0x160 [ 5889.46071 7] cpu_startup_entry+0x30/0xfc [ 5889.465523] second_start_kernel+0x158/0x1ec [ 5889.470936] Código: 97ffab78 f9411c14 91408294 f9457284 (f9400c80) [5889.477950] SMP: deteniendo las CPU secundarias [5890.514626] SMP: no se pudieron detener las CPU secundarias 0-69,71-95 [5890.522951] Iniciando el kernel de crashdump...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ip_tunnel: asegúrese de extraer el encabezado interno en ip_tunnel_rcv(). Aplique la misma solución que las encontradas en: 8d975c15c0cd ("ip6_tunnel: asegúrese de extraer el encabezado interno en __ip6_tnl_rcv() ") 1ca1ba465e55 ("geneve: asegúrese de extraer el encabezado interno en geneve_rx()") Tenemos que guardar skb->network_header en una variable temporal para poder volver a calcular el puntero network_header después de una llamada a pskb_inet_may_pull(). pskb_inet_may_pull() se asegura de que los encabezados necesarios estén en skb->head. syzbot informó: ERROR: KMSAN: valor uninit en __INET_ECN_decapsulate include/net/inet_ecn.h:253 [en línea] ERROR: KMSAN: valor uninit en INET_ECN_decapsulate include/net/inet_ecn.h:275 [en línea] ERROR: KMSAN: uninit -valor en IP_ECN_decapsulate include/net/inet_ecn.h:302 [en línea] ERROR: KMSAN: valor uninit en ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [en línea ] INET_ECN_decapsulate include/net/inet_ecn.h:275 [en línea] IP_ECN_decapsulate include/net/inet_ecn.h:302 [en línea] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [en línea] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/ 0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [en línea] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c: 254 dst_input include/net/dst.h:461 [en línea] ip_rcv_finish net/ipv4/ip_input.c:449 [en línea] NF_HOOK include/linux/netfilter.h:314 [en línea] ip_rcv+0x46f/0x760 net/ipv4/ip_input .c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [en línea] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [en línea] neto /core/dev.c:5793 tun_rx_batched+0x3ee/0x980 controladores/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 controladores/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 controladores/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs /read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf /0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit se creó en: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+ 0x1be /0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [en línea] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch /x86 /entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige la verificación de desbordamiento del mapa de pila en arcos de 32 bits. El código del mapa de pila se basa en roundup_pow_of_two() para calcular el número de depósitos de hash y contiene una verificación de desbordamiento verificando si el valor resultante es 0. Sin embargo, en arcos de 32 bits, el código de resumen en sí puede desbordarse al realizar un desplazamiento hacia la izquierda de 32 bits de un valor largo sin signo, lo cual es un comportamiento indefinido, por lo que no se garantiza que se trunque claramente. Esto fue activado por syzbot en el tipo DEVMAP_HASH, que contiene la misma verificación, copiada del código hashtab. La confirmación en la etiqueta de correcciones en realidad intentó solucionar este problema, pero la corrección no tuvo en cuenta la UB, por lo que la corrección solo funciona en CPU donde un desbordamiento resulta en un truncamiento claro a cero, lo cual no está garantizado. Verificar el valor antes de redondear no tiene este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige la comprobación de desbordamiento de hashtab en arcos de 32 bits. El código hashtab se basa en roundup_pow_of_two() para calcular el número de depósitos de hash y contiene una comprobación de desbordamiento comprobando si el valor resultante es 0. Sin embargo, en arcos de 32 bits, el código de resumen en sí puede desbordarse al realizar un desplazamiento hacia la izquierda de 32 bits de un valor largo sin signo, lo cual es un comportamiento indefinido, por lo que no se garantiza que se trunque claramente. Esto fue activado por syzbot en el tipo DEVMAP_HASH, que contiene la misma verificación, copiada del código hashtab. Así que aplique la misma solución a hashtab, moviendo la verificación de desbordamiento antes del resumen.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige la verificación de desbordamiento de DEVMAP_HASH en arcos de 32 bits. El código devmap asigna un número de depósitos de hash igual a la siguiente potencia de dos del valor max_entries proporcionado al crear el mapa. Al redondear a la siguiente potencia de dos, la variable de 32 bits que almacena el número de depósitos puede desbordarse, y el código verifica el desbordamiento comprobando si el valor truncado de 32 bits es igual a 0. Sin embargo, en arcos de 32 bits el redondeo hacia arriba puede desbordarse a mitad de camino, porque termina haciendo un desplazamiento hacia la izquierda de 32 bits en un valor largo sin signo. Si el tamaño de un largo sin firmar es de cuatro bytes, este es un comportamiento indefinido, por lo que no hay garantía de que terminemos con un valor 0 agradable y ordenado al final. Syzbot logró convertir esto en un bloqueo en arm32 creando un DEVMAP_HASH con max_entries > 0x80000000 y luego intentando actualizarlo. Solucione este problema moviendo la verificación de desbordamiento antes de la operación de redondeo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: af_bluetooth: Reparar interbloqueo Intentar ejecutar sock_lock en .recvmsg puede causar un interbloqueo como se muestra a continuación, por lo que en lugar de usar sock_sock, usa sk_receive_queue.lock en bt_sock_ioctl para evitar el UAF: INFORMACIÓN: tarea kworker/u9:1:121 bloqueada durante más de 30 segundos. No contaminado 6.7.6-lemon #183 Cola de trabajo: hci0 hci_rx_work Seguimiento de llamadas: __schedule+0x37d/0xa00 Schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270? terminar_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 proceso_one_work+0x13a/0x2f0 trabajador_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30