Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> cifs: corrige un posible oops en cifs_oplock_break<br /> <br /> Con el cierre diferido podemos tener cierres que compiten con las interrupciones de arrendamiento, y así, con las comprobaciones actuales para determinar si enviar la respuesta de arrendamiento, oplock_response(), esto puede significar que un desmontaje (kill_sb) puede ocurrir justo antes de que estuviéramos comprobando si tcon-&amp;gt;ses es válido. Véase a continuación:<br /> <br /> [Fri Aug 4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs]<br /> [Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e &amp;lt;48&amp;gt; 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39<br /> [Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206<br /> [Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009<br /> [Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188<br /> [Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900<br /> [Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138<br /> [Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000<br /> [Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000<br /> [Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0<br /> [Fri Aug 4 04:12:50 2023] Call Trace:<br /> [Fri Aug 4 04:12:50 2023] <br /> [Fri Aug 4 04:12:50 2023] process_one_work+0x225/0x3d0<br /> [Fri Aug 4 04:12:50 2023] worker_thread+0x4d/0x3e0<br /> [Fri Aug 4 04:12:50 2023] ? process_one_work+0x3d0/0x3d0<br /> [Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150<br /> [Fri Aug 4 04:12:50 2023] ? set_kthread_struct+0x50/0x50<br /> [Fri Aug 4 04:12:50 2023] ret_from_fork+0x22/0x30<br /> [Fri Aug 4 04:12:50 2023] <br /> <br /> Para solucionar esto, cambie el orden de las comprobaciones antes de enviar la oplock_response para comprobar primero si la openFileList está vacía.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> soundwire: bus: Corrige pm_runtime_put() desequilibrado que causa un subdesbordamiento del contador de uso<br /> <br /> Esto revierte el commit<br /> 443a98e649b4 (&amp;#39;soundwire: bus: usa pm_runtime_resume_and_get()&amp;#39;)<br /> <br /> Cambia las llamadas a pm_runtime_resume_and_get() de vuelta a pm_runtime_get_sync(). Esto corrige un subdesbordamiento del contador de uso causado por realizar un pm_runtime_put() incluso si pm_runtime_resume_and_get() devolvió un error.<br /> <br /> Las tres funciones afectadas ignoran el error -EACCES al intentar obtener pm_runtime, y continúan, incluyendo un put al final de la función. Pero pm_runtime_resume_and_get() no incrementa el contador de uso si devuelve un error. Así que en el caso de -EACCES no se debe llamar a pm_runtime_put().<br /> <br /> La documentación de pm_runtime_get_sync() dice:<br /> &amp;#39;Considere usar pm_runtime_resume_and_get() ... ya que esto probablemente resultará en un código más limpio.&amp;#39;<br /> <br /> En este caso no creo que resulte en un código más limpio porque el pm_runtime_put() al final de la función tendría que ser condicional al valor de retorno de pm_runtime_resume_and_get() al principio de la función.<br /> <br /> pm_runtime_get_sync() no tiene este problema porque siempre incrementa el contador, por lo que siempre necesita un put. El código puede simplemente fluir y realizar el pm_runtime_put() incondicionalmente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> cifs: Corrección: pérdida de la destrucción de la conexión smbd cuando la asignación de MR falló<br /> <br /> Si la asignación de MR falló, la información de conexión directa smb es NULL,<br /> entonces smbd_destroy() regresará directamente, entonces la información de conexión<br /> se filtrará.<br /> <br /> Establezcamos la información de conexión directa smb al servidor antes de llamar a smbd_destroy().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drm/amdkfd: Añadir los callbacks faltantes del gestor MQD de gfx11<br /> <br /> La función mqd_stride fue introducida en el commit 2f77b9a242a2<br /> (&amp;#39;drm/amdkfd: Actualizar la gestión de MQD en una configuración multi-XCC&amp;#39;)<br /> pero no asignada para gfx11. Corrige una desreferencia NULL en debugfs.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/mlx5e: No clonar los atributos de acción posterior de flujo por segunda vez<br /> <br /> El código ya clona los atributos de acción posterior en mlx5e_clone_flow_attr_for_post_act(). Crear otra copia en mlx5e_tc_post_act_add() es un remanente erróneo de la implementación original. En su lugar, asignar handle-&amp;gt;attribute a post_attr proporcionado por el llamador. Tenga en cuenta que clonar el atributo por segunda vez no solo es un desperdicio, sino que también causa problemas como que la segunda copia no se actualice correctamente en el código de actualización de &amp;#39;neigh&amp;#39;, lo que lleva al siguiente uso después de liberación:<br /> <br /> Feb 21 09:02:00 c-237-177-40-045 kernel: BUG: KASAN: use-after-free in mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_report+0xbb/0x1a0<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_stack+0x1e/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_set_track+0x21/0x30<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: __kasan_kmalloc+0x7a/0x90<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_stack+0x1e/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_set_track+0x21/0x30<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_free_info+0x2a/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ____kasan_slab_free+0x11a/0x1b0<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: page dumped because: kasan: bad access detected<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_core 0000:08:00.0: mlx5_cmd_out_err:803:(pid 8833): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad resource state(0x9), syndrome (0xf2ff71), err(-22)<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_core 0000:08:00.0 enp8s0f0: Failed to add post action rule<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_core 0000:08:00.0: mlx5e_tc_encap_flows_add:190:(pid 8833): Failed to update flow post acts, -22<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: Traza de Llamada:<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: <br /> Feb 21 09:02:00 c-237-177-40-045 kernel: dump_stack_lvl+0x57/0x7d<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: print_report+0x170/0x471<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_report+0xbb/0x1a0<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_cmd_set_fte+0x200d/0x24c0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? __module_address.part.0+0x62/0x200<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? mlx5_cmd_stub_create_flow_table+0xd0/0xd0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: ? __raw_spin_lock_init+0x3b/0x110<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_cmd_create_fte+0x80/0xb0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: add_rule_fg+0xe80/0x19c0 [mlx5_core]<br /> --<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: Asignado por tarea 13476:<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_stack+0x1e/0x40<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_set_track+0x21/0x30<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: __kasan_kmalloc+0x7a/0x90<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5_packet_reformat_alloc+0x7b/0x230 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_tc_tun_create_header_ipv4+0x977/0xf10 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_attach_encap+0x15b4/0x1e10 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: post_process_attr+0x305/0xa30 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_tc_add_fdb_flow+0x4c0/0xcf0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_configure_flower+0xcaa/0x4b90 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_rep_setup_tc_cls_flower+0x99/0x1b0 [mlx5_core]<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: mlx5e_rep_setup_tc_cb+0x133/0x1e0 [mlx5_core]<br /> --<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: Liberado por tarea 8833:<br /> Feb 21 09:02:00 c-237-177-40-045 kernel: kasan_save_s<br /> ---truncado---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ASoC: códecs: tx-macro: Solución para KASAN: slab-out-of-bounds<br /> <br /> Cuando ejecutamos syzkaller obtenemos el siguiente Out of Bound.<br /> &amp;#39;KASAN: slab-out-of-bounds Read in regcache_flat_read&amp;#39;<br /> <br /> A continuación se muestra el rastreo de pila del problema:<br /> <br /> dump_backtrace+0x0/0x4c8<br /> show_stack+0x34/0x44<br /> dump_stack_lvl+0xd8/0x118<br /> print_address_description+0x30/0x2d8<br /> kasan_report+0x158/0x198<br /> __asan_report_load4_noabort+0x44/0x50<br /> regcache_flat_read+0x10c/0x110<br /> regcache_read+0xf4/0x180<br /> _regmap_read+0xc4/0x278<br /> _regmap_update_bits+0x130/0x290<br /> regmap_update_bits_base+0xc0/0x15c<br /> snd_soc_component_update_bits+0xa8/0x22c<br /> snd_soc_component_write_field+0x68/0xd4<br /> tx_macro_digital_mute+0xec/0x140<br /> <br /> En realidad, no hay necesidad de tener un decimador con 32 bits.<br /> Al limitar la variable con el tipo corto u8, el problema se resuelve.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> rcuscale: Mover rcu_scale_writer() schedule_timeout_uninterruptible() a _idle()<br /> <br /> El parámetro del módulo rcuscale.holdoff puede ser usado para retrasar el inicio del kthread rcu_scale_writer(). Sin embargo, el tiempo de espera de tarea colgada se activará cuando el tiempo de espera especificado por rcuscale.holdoff sea mayor que hung_task_timeout_secs:<br /> <br /> runqemu kvm nographic slirp qemuparams="-smp 4 -m 2048M"<br /> bootparams="rcuscale.shutdown=0 rcuscale.holdoff=300"<br /> <br /> [ 247.071753] INFO: tarea rcu_scale_write:59 bloqueada por más de 122 segundos.<br /> [ 247.072529] No contaminado 6.4.0-rc1-00134-gb9ed6de8d4ff #7<br /> [ 247.073400] &amp;#39;echo 0 &amp;gt; /proc/sys/kernel/hung_task_timeout_secs&amp;#39; deshabilita este mensaje.<br /> [ 247.074331] tarea:rcu_scale_write estado:D pila:30144 pid:59 ppid:2 flags:0x00004000<br /> [ 247.075346] Rastreo de Llamada:<br /> [ 247.075660] <br /> [ 247.075965] __schedule+0x635/0x1280<br /> [ 247.076448] ? __pfx___schedule+0x10/0x10<br /> [ 247.076967] ? schedule_timeout+0x2dc/0x4d0<br /> [ 247.077471] ? __pfx_lock_release+0x10/0x10<br /> [ 247.078018] ? enqueue_timer+0xe2/0x220<br /> [ 247.078522] schedule+0x84/0x120<br /> [ 247.078957] schedule_timeout+0x2e1/0x4d0<br /> [ 247.079447] ? __pfx_schedule_timeout+0x10/0x10<br /> [ 247.080032] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.080591] ? __pfx_process_timeout+0x10/0x10<br /> [ 247.081163] ? __pfx_sched_set_fifo_low+0x10/0x10<br /> [ 247.081760] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.082287] rcu_scale_writer+0x6b1/0x7f0<br /> [ 247.082773] ? mark_held_locks+0x29/0xa0<br /> [ 247.083252] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.083865] ? __pfx_rcu_scale_writer+0x10/0x10<br /> [ 247.084412] kthread+0x179/0x1c0<br /> [ 247.084759] ? __pfx_kthread+0x10/0x10<br /> [ 247.085098] ret_from_fork+0x2c/0x50<br /> [ 247.085433] <br /> <br /> Este commit por lo tanto reemplaza schedule_timeout_uninterruptible() con schedule_timeout_idle().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bpf: Silenciar una advertencia en btf_type_id_size()<br /> <br /> syzbot informó una advertencia en [1] con el siguiente stacktrace:<br /> WARNING: CPU: 0 PID: 5005 at kernel/bpf/btf.c:1988 btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988<br /> ...<br /> RIP: 0010:btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988<br /> ...<br /> Traza de Llamada:<br /> <br /> map_check_btf kernel/bpf/syscall.c:1024 [inline]<br /> map_create+0x1157/0x1860 kernel/bpf/syscall.c:1198<br /> __sys_bpf+0x127f/0x5420 kernel/bpf/syscall.c:5040<br /> __do_sys_bpf kernel/bpf/syscall.c:5162 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5160 [inline]<br /> __x64_sys_bpf+0x79/0xc0 kernel/bpf/syscall.c:5160<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Con el siguiente btf<br /> [1] DECL_TAG &amp;#39;a&amp;#39; type_id=4 component_idx=-1<br /> [2] PTR &amp;#39;(anon)&amp;#39; type_id=0<br /> [3] TYPE_TAG &amp;#39;a&amp;#39; type_id=2<br /> [4] VAR &amp;#39;a&amp;#39; type_id=3, linkage=static<br /> y cuando bpf_attr.btf_key_type_id = 1 (DECL_TAG),<br /> el siguiente WARN_ON_ONCE en btf_type_id_size() se activa:<br /> if (WARN_ON_ONCE(!btf_type_is_modifier(size_type) &amp;amp;&amp;amp;<br /> !btf_type_is_var(size_type)))<br /> return NULL;<br /> <br /> Tenga en cuenta que &amp;#39;return NULL&amp;#39; es el comportamiento correcto ya que no queremos<br /> que un tipo DECL_TAG sea usado como btf_{key,value}_type_id incluso<br /> para el caso como &amp;#39;DECL_TAG -&amp;gt; STRUCT&amp;#39;. Así que no hay<br /> ningún problema de corrección aquí, solo queremos silenciar la advertencia.<br /> <br /> Para silenciar la advertencia, agregué DECL_TAG como uno de los tipos en<br /> btf_type_nosize() lo que hará que btf_type_id_size() devuelva<br /> NULL antes sin la advertencia.<br /> <br /> [1] https://lore.kernel.org/bpf/000000000000e0df8d05fc75ba86@google.com/

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fs/ntfs3: Añadir comprobación para kmemdup<br /> <br /> Dado que kmemdup puede devolver un puntero NULL,<br /> sería mejor añadir una comprobación para el valor de retorno<br /> para evitar la desreferencia de puntero NULL.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bus: mhi: ep: Solo enviar estado -ENOTCONN si el controlador cliente está disponible<br /> <br /> Para los comandos STOP y RESET, solo enviar el estado de desconexión del canal -ENOTCONN si el controlador cliente está disponible. De lo contrario, resultará en desreferencia de puntero nulo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ksmbd: evitar el acceso fuera de límites en decode_preauth_ctxt()<br /> <br /> Confirmar que la dirección pneg_ctxt-&amp;gt;HashAlgorithms accedida se encuentra dentro del límite de la solicitud SMB; deassemble_neg_contexts() solo verifica que el encabezado smb2_neg_context de ocho bytes + (DataLength controlada por el cliente) estén dentro del límite del paquete, lo cual es insuficiente.<br /> <br /> Verificar sizeof(struct smb2_preauth_neg_context) es excesivo dado que el tipo actualmente asume SMB311_SALT_SIZE bytes de Salt final.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: taprio: Limitar TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME a INT_MAX.<br /> <br /> syzkaller encontró un error de división por cero [0] en div_s64_rem() llamada desde get_cycle_time_elapsed(), donde sched-&amp;gt;cycle_time es el divisor.<br /> <br /> Tenemos pruebas en parse_taprio_schedule() para que cycle_time nunca sea 0, y de hecho cycle_time no es 0 en get_cycle_time_elapsed().<br /> <br /> El problema es que los tipos de divisor son diferentes; cycle_time es s64, pero el argumento de div_s64_rem() es s32.<br /> <br /> syzkaller alimentó esta entrada y 0x100000000 se convierte a s32 para ser 0.<br /> <br /> @TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME={0xc, 0x8, 0x100000000}<br /> <br /> Usamos s64 para cycle_time para convertirlo a ktime_t, así que mantengámoslo y establezcamos el máximo para cycle_time.<br /> <br /> Ya que estamos, prevenimos el desbordamiento en setup_txtime() y añadimos otra prueba en parse_taprio_schedule() para verificar si cycle_time se desborda.<br /> <br /> Además, añadimos un nuevo caso de prueba tdc para este problema.<br /> <br /> [0]:<br /> divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 1 PID: 103 Comm: kworker/1:3 Not tainted 6.5.0-rc1-00330-g60cc1f7d0605 #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Workqueue: ipv6_addrconf addrconf_dad_work<br /> RIP: 0010:div_s64_rem include/linux/math64.h:42 [inline]<br /> RIP: 0010:get_cycle_time_elapsed net/sched/sch_taprio.c:223 [inline]<br /> RIP: 0010:find_entry_to_transmit+0x252/0x7e0 net/sched/sch_taprio.c:344<br /> Code: 3c 02 00 0f 85 5e 05 00 00 48 8b 4c 24 08 4d 8b bd 40 01 00 00 48 8b 7c 24 48 48 89 c8 4c 29 f8 48 63 f7 48 99 48 89 74 24 70 &amp;lt;48&amp;gt; f7 fe 48 29 d1 48 8d 04 0f 49 89 cc 48 89 44 24 20 49 8d 85 10<br /> RSP: 0018:ffffc90000acf260 EFLAGS: 00010206<br /> RAX: 177450e0347560cf RBX: 0000000000000000 RCX: 177450e0347560cf<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000100000000<br /> RBP: 0000000000000056 R08: 0000000000000000 R09: ffffed10020a0934<br /> R10: ffff8880105049a7 R11: ffff88806cf3a520 R12: ffff888010504800<br /> R13: ffff88800c00d800 R14: ffff8880105049a0 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff88806cf00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f0edf84f0e8 CR3: 000000000d73c002 CR4: 0000000000770ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> get_packet_txtime net/sched/sch_taprio.c:508 [inline]<br /> taprio_enqueue_one+0x900/0xff0 net/sched/sch_taprio.c:577<br /> taprio_enqueue+0x378/0xae0 net/sched/sch_taprio.c:658<br /> dev_qdisc_enqueue+0x46/0x170 net/core/dev.c:3732<br /> __dev_xmit_skb net/core/dev.c:3821 [inline]<br /> __dev_queue_xmit+0x1b2f/0x3000 net/core/dev.c:4169<br /> dev_queue_xmit include/linux/netdevice.h:3088 [inline]<br /> neigh_resolve_output net/core/neighbour.c:1552 [inline]<br /> neigh_resolve_output+0x4a7/0x780 net/core/neighbour.c:1532<br /> neigh_output include/net/neighbour.h:544 [inline]<br /> ip6_finish_output2+0x924/0x17d0 net/ipv6/ip6_output.c:135<br /> __ip6_finish_output+0x620/0xaa0 net/ipv6/ip6_output.c:196<br /> ip6_finish_output net/ipv6/ip6_output.c:207 [inline]<br /> NF_HOOK_COND include/linux/netfilter.h:292 [inline]<br /> ip6_output+0x206/0x410 net/ipv6/ip6_output.c:228<br /> dst_output include/net/dst.h:458 [inline]<br /> NF_HOOK.constprop.0+0xea/0x260 include/linux/netfilter.h:303<br /> ndisc_send_skb+0x872/0xe80 net/ipv6/ndisc.c:508<br /> ndisc_send_ns+0xb5/0x130 net/ipv6/ndisc.c:666<br /> addrconf_dad_work+0xc14/0x13f0 net/ipv6/addrconf.c:4175<br /> process_one_work+0x92c/0x13a0 kernel/workqueue.c:2597<br /> worker_thread+0x60f/0x1240 kernel/workqueue.c:2748<br /> kthread+0x2fe/0x3f0 kernel/kthread.c:389<br /> ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308<br /> <br /> Modules linked in: