Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: return fail if interface is down in bnxt_queue_mem_alloc(). Se llama a bnxt_queue_mem_alloc() para asignar nueva memoria de cola cuando esta se reinicia. Accede internamente al descriptor de búfer rx correspondiente al índice. El descriptor de búfer rx se asigna y se establece cuando la interfaz está activa y se libera cuando esta se cae. Por lo tanto, si la cola se reinicia mientras la interfaz está caída, se produce un pánico del kernel. El problema se ve así: ERROR: no se puede gestionar el error de página para la dirección: 000000000000b240 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 UID: 0 PID: 1563 Comm: ncdevmem2 No contaminado 6.14.0-rc2+ #9 844ddba6e7c459cafd0bf4db9a3198e Nombre del hardware: Nombre del producto del sistema ASUS/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP: 0010:bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en] Code: 41 54 4d 89 c4 4d 69 c0 c0 05 00 00 55 48 89 f5 53 48 89 fb 4c 8d b5 40 05 00 00 48 83 ec 15 RSP: 0018:ffff9dcc83fef9e8 EFLAGS: 00010202 RAX: ffffffffc0457720 RBX: ffff934ed8d40000 RCX: 0000000000000000 RDX: 000000000000001f RSI: ffff934ea508f800 RDI: ffff934ea508f808 RBP: ffff934ea508f800 R08: 000000000000b240 R09: ffff934e84f4b000 R10: ffff9dcc83fefa30 R11: ffff934e84f4b000 R12: 000000000000001f R13: ffff934ed8d40ac0 R14: ffff934ea508fd40 R15: ffff934e84f4b000 FS: 00007fa73888c740(0000) GS:ffff93559f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000b240 CR3: 0000000145a2e000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x15a/0x460 ? exc_page_fault+0x6e/0x180 ? asm_exc_page_fault+0x22/0x30 ? __pfx_bnxt_queue_mem_alloc+0x10/0x10 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7] ? bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7] netdev_rx_queue_restart+0xc5/0x240 net_devmem_bind_dmabuf_to_queue+0xf8/0x200 netdev_nl_bind_rx_doit+0x3a7/0x450 genl_family_rcv_msg_doit+0xd9/0x130 genl_rcv_msg+0x184/0x2b0 ? __pfx_netdev_nl_bind_rx_doit+0x10/0x10 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: hyperv_fb: Permite la eliminación ordenada del framebuffer. Cuando se desvincula un dispositivo framebuffer de Hyper-V, el controlador hyperv_fb intenta liberarlo forzosamente. Si este framebuffer está en uso, genera la siguiente advertencia y, por lo tanto, nunca se libera. [44.111220] ADVERTENCIA: CPU: 35 PID: 1882 en drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40 < snip > [44.111289] Rastreo de llamadas: [ 44.111290] [ 44.111291] ? show_regs+0x6c/0x80 [ 44.111295] ? __warn+0x8d/0x150 [ 44.111298] ? framebuffer_release+0x2c/0x40 [ 44.111300] ? report_bug+0x182/0x1b0 [ 44.111303] ? handle_bug+0x6e/0xb0 [ 44.111306] ? exc_invalid_op+0x18/0x80 [ 44.111308] ? asm_exc_invalid_op+0x1b/0x20 [ 44.111311] ? framebuffer_release+0x2c/0x40 [ 44.111313] ? hvfb_remove+0x86/0xa0 [hyperv_fb] [ 44.111315] vmbus_remove+0x24/0x40 [hv_vmbus] [ 44.111323] device_remove+0x40/0x80 [ 44.111325] device_release_driver_internal+0x20b/0x270 [ 44.111327] ? bus_find_device+0xb3/0xf0. Solucione esto trasladando la liberación del framebuffer y la memoria asociada a la función fb_ops.fb_destroy, para que el framework del framebuffer lo gestione correctamente. Mientras lo solucionamos, también reemplace el registro/desregistro manual del framebuffer con devm_register_framebuffer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrección de slab-use-after-free en hdcp_work [Por qué] Se reporta un slab-use-after-free cuando se destruye HDCP, pero la cola property_validate_dwork sigue en ejecución. [Cómo] Cancelar el trabajo retrasado al destruir la cola de trabajo. (Seleccionado de el commit 725a04ba5a95e89c89633d4322430cfbca7ce128)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Puente, corrige el fallo causado por la comprobación del estado de LAG Al retirar el dispositivo LAG del puente, se activa el evento NETDEV_CHANGEUPPER. El controlador encuentra los dispositivos inferiores (PF) para vaciar todas las entradas descargadas. Y mlx5_lag_is_shared_fdb está marcado, devuelve falso si uno de los PF está descargado. En tal caso, mlx5_esw_bridge_lag_rep_get() y su llamador devuelven NULL, en lugar del PF vivo, y se omite el vaciado. Además, el lastuse de la entrada fdb del puente se actualiza en el controlador de eventos del puente mlx5. Pero este evento SWITCHDEV_FDB_ADD_TO_BRIDGE se puede ignorar en este caso porque se elimina la interfaz superior para el enlace y la entrada nunca se envejecerá porque lastuse nunca se actualiza. Para empeorar las cosas, mientras la entrada esté activa, la cola de trabajo del puente mlx5 sigue enviando ese evento, que luego gestiona el notificador del puente del núcleo. Esto provoca el siguiente fallo al acceder al enlace transferido netdev, que ya está destruido. Para solucionar este problema, elimine estas comprobaciones. El estado de LAG ya se comprobó en el commit 15f8f168952f ("net/mlx5: Puente, verificar el estado de LAG al agregar el enlace al puente"). El controlador aún debe omitir la descarga si el estado de LAG se vuelve inválido después de la inicialización. Ups: segmento de pila: 0000 [#1] CPU SMP: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Contaminado: G OE 6.11.0_mlnx #1 Contaminado: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core] RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge] Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7 RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297 RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0 RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60 R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? die+0x38/0x60 ? do_trap+0x10b/0x120 ? do_error_trap+0x64/0xa0 ? exc_stack_segment+0x33/0x50 ? asm_exc_stack_segment+0x22/0x30 ? br_switchdev_event+0x2c/0x110 [bridge] ? sched_balance_newidle.isra.149+0x248/0x390 notifier_call_chain+0x4b/0xa0 atomic_notifier_call_chain+0x16/0x20 mlx5_esw_bridge_update+0xec/0x170 [mlx5_core] mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core] process_scheduled_works+0x81/0x390 worker_thread+0x106/0x250 ? bh_worker+0x110/0x110 kthread+0xb7/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: Impide la creación de clases con TC_H_ROOT La función qdisc_tree_reduce_backlog() usa TC_H_ROOT como condición de terminación al recorrer el árbol qdisc para actualizar los contadores de backlog primarios. Sin embargo, si se crea una clase con classid TC_H_ROOT, el recorrido termina prematuramente en esta clase en lugar de alcanzar la qdisc root real, lo que provoca que las estadísticas primarias se mantengan incorrectamente. En caso de DRR, esto podría provocar un fallo como lo informó Mingi Cho. Impide la creación de cualquier clase Qdisc con classid TC_H_ROOT (0xFFFFFFFF) en todos los tipos de qdisc, como sugirió Jamal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: gestión de errores en mlx5_chains_create_table(). En mlx5_chains_create_table(), se debe comprobar el valor de retorno de mlx5_get_fdb_sub_ns() y mlx5_get_flow_namespace() para evitar desreferencias de punteros nulos. Si alguna de las funciones falla, debe registrar un mensaje de error con mlx5_core_warn() y devolver un puntero de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "openvswitch: cambiar al conteo de etiquetas por acción en conntrack". Actualmente, ovs_ct_set_labels() solo se llama para entradas de conntrack confirmadas (ct) dentro de ovs_ct_commit(). Sin embargo, si la entrada de conntrack no tiene la extensión labels_ext, al intentar asignarla en ovs_ct_get_conn_labels() para una entrada confirmada, se genera una advertencia en nf_ct_ext_add(): WARN_ON(nf_ct_is_confirmed(ct)); Esto ocurre cuando la entrada de conntrack se crea externamente antes de que OVS incremente net->ct.labels_used. El problema se ha vuelto más frecuente desde el commit fcb1aa5163b1 ("openvswitch: cambio al conteo de etiquetas por acción en conntrack"), que cambió para usar el conteo de etiquetas por acción e incrementar net->ct.labels_used al agregar un flujo con la acción ct. Dado que actualmente no existe una solución directa para este problema, esta reversión de el commit evita la interrupción de los casos de uso existentes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: no actualice la suma de comprobación en bnxt_xdp_build_skb() El bnxt_rx_pkt() actualiza el valor de ip_summed al final si la descarga de suma de comprobación está habilitada. Cuando se adjunta el programa XDP-MB y devuelve XDP_PASS, se llama a bnxt_xdp_build_skb() para actualizar skb_shared_info. El propósito principal de bnxt_xdp_build_skb() es actualizar skb_shared_info, pero también actualiza el valor de ip_summed si la descarga de suma de comprobación está habilitada. En realidad, esto es trabajo duplicado. Cuando bnxt_rx_pkt() actualiza el valor de ip_summed, verifica si ip_summed es CHECKSUM_NONE o no. Significa que ip_summed debería ser CHECKSUM_NONE en este momento. Pero es posible que ip_summed ya esté actualizado a CHECKSUM_UNNECESSARY en la ruta XDP-MB-PASS. Por lo tanto, skb_checksum_none_assert() advierte al respecto. Esto implica trabajo duplicado y no es necesario actualizar ip_summed en bnxt_xdp_build_skb(). El mensaje aparece así: ADVERTENCIA: CPU: 3 PID: 5782 en ./include/linux/skbuff.h:5155 bnxt_rx_pkt+0x479b/0x7610 [bnxt_en] Módulos vinculados: bnxt_re bnxt_en rdma_ucm rdma_cm iw_cm ib_cm ib_uverbs veth xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_] CPU: 3 UID: 0 PID: 5782 Comm: socat Contaminado: GW 6.14.0-rc4+ #27 Contaminado: [W]=WARN Nombre del hardware: Nombre del producto del sistema ASUS/PRIME Z690-P D4, BIOS 0603 11/01/2021 RIP: 0010:bnxt_rx_pkt+0x479b/0x7610 [bnxt_es] Código: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff <0f> 0b f RSP: 0018:ffff88881ba09928 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000c7590303 RCX: 0000000000000000 RDX: 1ffff1104e7d1610 RSI: 0000000000000001 RDI: ffff8881c91300b8 RBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070 R10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080 R13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000 FS: 00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4: 00000000007506f0 PKRU: 55555554 Rastreo de llamadas: ? __warn+0xcd/0x2f0 ? bnxt_rx_pkt+0x479b/0x7610 ? report_bug+0x326/0x3c0 ? __pfx_bnxt_rx_pkt+0x10/0x10 ? __bnxt_poll_work+0x4e8/0x1220 ? __pfx___bnxt_poll_work+0x10/0x10 ? El siguiente parche de ping.py agrega el caso xdp-mb-pass, por lo que ping.py podrá reproducir este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: bnxt: corrección de truesize para el caso mb-xdp-pass. Cuando mb-xdp está configurado y el valor de retorno es XDP_PASS, el paquete se convierte de xdp_buff a sk_buff con xdp_update_skb_shared_info() en bnxt_xdp_build_skb(). bnxt_xdp_build_skb() pasa un argumento truesize incorrecto a xdp_update_skb_shared_info(). El truesize se calcula como BNXT_RX_PAGE_SIZE * sinfo->nr_frags, pero napi_build_skb() borró previamente skb_shared_info. De este modo, almacena sinfo->nr_frags antes de bnxt_xdp_build_skb() y lo utiliza en lugar de obtener skb_shared_info de xdp_get_shared_info_from_buff(). El splat se ve así: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 0 en net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590 Módulos enlazados en: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms CPU: 2 UID: 0 PID: 0 Comm: swapper/2 No contaminado 6.14.0-rc2+ #3 RIP: 0010:skb_try_coalesce+0x504/0x590 Código: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99 RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287 RAX: 000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0 RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 000000000000003 RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900 R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740 R13: ffffe43600000000 R14: 000000000000002 R15: 0000000000000002 FS: 000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0 PKRU: 55555554 Rastreo de llamadas: ? __warn+0x84/0x130 ? skb_try_coalesce+0x504/0x590 ? report_bug+0x18a/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? skb_try_coalesce+0x504/0x590 inet_frag_reasm_finish+0x11f/0x2e0 ip_defrag+0x37a/0x900 ip_local_deliver+0x51/0x120 ip_sublist_rcv_finish+0x64/0x70 ip_sublist_rcv+0x179/0x210 ip_list_rcv+0xf9/0x130 Cómo reproducir: enlace ip establecido $interfaz1 xdp obj xdp_pass.o enlace ip establecido $interfaz1 mtu 9000 activo ip aa 10.0.0.1/24 dev $interfaz1 enlace ip establecido $interfaz2 mtu 9000 activo ip aa 10.0.0.2/24 El siguiente parche de ping.py agrega el caso xdp-mb-pass, por lo que ping.py podrá reproducir este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched_ext: Validar prev_cpu en scx_bpf_select_cpu_dfl(). Si un programador BPF proporciona una CPU no válida (fuera del rango nr_cpu_ids) como prev_cpu a scx_bpf_select_cpu_dfl(), puede provocar un fallo del kernel. Para evitarlo, valide prev_cpu en scx_bpf_select_cpu_dfl() y genere un error scx si se especifica una CPU no válida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm-flakey: corrige la corrupción de memoria en la función opcional corrupt_bio_byte Corrige la corrupción de memoria debido al parámetro incorrecto que se pasa a bio_init

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_conncount: Inicializar completamente la estructura nf_conncount_tuple en insert_tree() Desde el commit b36e4523d4d5 ("netfilter: nf_conncount: corregir la carrera de confirmación de la recolección de basura"), se introdujeron `cpu` y `jiffies32` en la estructura nf_conncount_tuple. El commit hizo que nf_conncount_add() inicializara `conn->cpu` y `conn->jiffies32` al asignar la estructura. Por el contrario, count_tree() no se modificó para inicializarlas. Mediante el commit 34848d5c896e ("netfilter: nf_conncount: Dividir la inserción y el recorrido"), count_tree() se dividió y el código de asignación relevante ahora reside en insert_tree(). Inicialice `conn->cpu` y `conn->jiffies32` en insert_tree(). ERROR: KMSAN: valor no inicializado en find_or_evict net/netfilter/nf_conncount.c:117 [en línea] ERROR: KMSAN: valor no inicializado en __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 find_or_evict net/netfilter/nf_conncount.c:117 [en línea] __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 count_tree net/netfilter/nf_conncount.c:438 [en línea] nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [en línea] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [en línea] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn incluir/linux/netfilter.h:154 [en línea] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST incluir/linux/netfilter.h:350 [en línea] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669 __netif_receive_skb_list_ptype net/core/dev.c:5936 [en línea] __netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983 __netif_receive_skb_list net/core/dev.c:6035 [en línea] netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126 netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178 xdp_recv_frames net/bpf/test_run.c:280 [en línea] xdp_test_run_batch net/bpf/test_run.c:361 [en línea] bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390 bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316 bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 __do_sys_bpf kernel/bpf/syscall.c:5902 [en línea] __se_sys_bpf kernel/bpf/syscall.c:5900 [en línea] __ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [en línea] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387 do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Uninit se creó en: slab_post_alloc_hook mm/slub.c:4121 [en línea] slab_alloc_node mm/slub.c:4164 [en línea] kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171 árbol_de_inserción net/netfilter/nf_conncount.c:372 [en línea] árbol_de_conteo net/netfilter/nf_conncount.c:450 [en línea] nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [en línea] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [en línea] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [en línea] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [en línea] ip_sublist_rcv+0x17b7/0x17f0 ---truncado---