Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix UAF on sva unbind with pending IOPFs<br /> <br /> Commit 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach<br /> path") disables IOPF on device by removing the device from its IOMMU&amp;#39;s<br /> IOPF queue when the last IOPF-capable domain is detached from the device.<br /> Unfortunately, it did this in a wrong place where there are still pending<br /> IOPFs. As a result, a use-after-free error is potentially triggered and<br /> eventually a kernel panic with a kernel trace similar to the following:<br /> <br /> refcount_t: underflow; use-after-free.<br /> WARNING: CPU: 3 PID: 313 at lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0<br /> Workqueue: iopf_queue/dmar0-iopfq iommu_sva_handle_iopf<br /> Call Trace:<br /> <br /> iopf_free_group+0xe/0x20<br /> process_one_work+0x197/0x3d0<br /> worker_thread+0x23a/0x350<br /> ? rescuer_thread+0x4a0/0x4a0<br /> kthread+0xf8/0x230<br /> ? finish_task_switch.isra.0+0x81/0x260<br /> ? kthreads_online_cpu+0x110/0x110<br /> ? kthreads_online_cpu+0x110/0x110<br /> ret_from_fork+0x13b/0x170<br /> ? kthreads_online_cpu+0x110/0x110<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The intel_pasid_tear_down_entry() function is responsible for blocking<br /> hardware from generating new page faults and flushing all in-flight<br /> ones. Therefore, moving iopf_for_domain_remove() after this function<br /> should resolve this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen: fix UAF in dmabuf_exp_from_pages()<br /> <br /> [dma_buf_fd() fixes; no preferences regarding the tree it goes through -<br /> up to xen folks]<br /> <br /> As soon as we&amp;#39;d inserted a file reference into descriptor table, another<br /> thread could close it. That&amp;#39;s fine for the case when all we are doing is<br /> returning that descriptor to userland (it&amp;#39;s a race, but it&amp;#39;s a userland<br /> race and there&amp;#39;s nothing the kernel can do about it). However, if we<br /> follow fd_install() with any kind of access to objects that would be<br /> destroyed on close (be it the struct file itself or anything destroyed<br /> by its -&gt;release()), we have a UAF.<br /> <br /> dma_buf_fd() is a combination of reserving a descriptor and fd_install().<br /> gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the<br /> objects destroyed on close - starting with gntdev_dmabuf itself.<br /> <br /> Fix that by doing reserving descriptor before anything else and do<br /> fd_install() only when everything had been set up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Fix UAF in panthor_gem_create_with_handle() debugfs code<br /> <br /> The object is potentially already gone after the drm_gem_object_put().<br /> In general the object should be fully constructed before calling<br /> drm_gem_handle_create(), except the debugfs tracking uses a separate<br /> lock and list and separate flag to denotate whether the object is<br /> actually initialized.<br /> <br /> Since I&amp;#39;m touching this all anyway simplify this by only adding the<br /> object to the debugfs when it&amp;#39;s ready for that, which allows us to<br /> delete that separate flag. panthor_gem_debugfs_bo_rm() already checks<br /> whether we&amp;#39;ve actually been added to the list or this is some error<br /> path cleanup.<br /> <br /> v2: Fix build issues for !CONFIG_DEBUGFS (Adrián)<br /> <br /> v3: Add linebreak and remove outdated comment (Liviu)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port<br /> <br /> Each window of a vop2 is usable by a specific set of video ports, so while<br /> binding the vop2, we look through the list of available windows trying to<br /> find one designated as primary-plane and usable by that specific port.<br /> <br /> The code later wants to use drm_crtc_init_with_planes with that found<br /> primary plane, but nothing has checked so far if a primary plane was<br /> actually found.<br /> <br /> For whatever reason, the rk3576 vp2 does not have a usable primary window<br /> (if vp0 is also in use) which brought the issue to light and ended in a<br /> null-pointer dereference further down.<br /> <br /> As we expect a primary-plane to exist for a video-port, add a check at<br /> the end of the window-iteration and fail probing if none was found.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix use-after-free in amdgpu_userq_suspend+0x51a/0x5a0<br /> <br /> [ +0.000020] BUG: KASAN: slab-use-after-free in amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]<br /> [ +0.000817] Read of size 8 at addr ffff88812eec8c58 by task amd_pci_unplug/1733<br /> <br /> [ +0.000027] CPU: 10 UID: 0 PID: 1733 Comm: amd_pci_unplug Tainted: G W 6.14.0+ #2<br /> [ +0.000009] Tainted: [W]=WARN<br /> [ +0.000003] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020<br /> [ +0.000004] Call Trace:<br /> [ +0.000004] <br /> [ +0.000003] dump_stack_lvl+0x76/0xa0<br /> [ +0.000011] print_report+0xce/0x600<br /> [ +0.000009] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000006] ? kasan_complete_mode_report_info+0x76/0x200<br /> [ +0.000007] ? kasan_addr_to_slab+0xd/0xb0<br /> [ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]<br /> [ +0.000707] kasan_report+0xbe/0x110<br /> [ +0.000006] ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]<br /> [ +0.000541] __asan_report_load8_noabort+0x14/0x30<br /> [ +0.000005] amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]<br /> [ +0.000535] ? stop_cpsch+0x396/0x600 [amdgpu]<br /> [ +0.000556] ? stop_cpsch+0x429/0x600 [amdgpu]<br /> [ +0.000536] ? __pfx_amdgpu_userq_suspend+0x10/0x10 [amdgpu]<br /> [ +0.000536] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? kgd2kfd_suspend+0x132/0x1d0 [amdgpu]<br /> [ +0.000542] amdgpu_device_fini_hw+0x581/0xe90 [amdgpu]<br /> [ +0.000485] ? down_write+0xbb/0x140<br /> [ +0.000007] ? __mutex_unlock_slowpath.constprop.0+0x317/0x360<br /> [ +0.000005] ? __pfx_amdgpu_device_fini_hw+0x10/0x10 [amdgpu]<br /> [ +0.000482] ? __kasan_check_write+0x14/0x30<br /> [ +0.000004] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? up_write+0x55/0xb0<br /> [ +0.000007] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? blocking_notifier_chain_unregister+0x6c/0xc0<br /> [ +0.000008] amdgpu_driver_unload_kms+0x69/0x90 [amdgpu]<br /> [ +0.000484] amdgpu_pci_remove+0x93/0x130 [amdgpu]<br /> [ +0.000482] pci_device_remove+0xae/0x1e0<br /> [ +0.000008] device_remove+0xc7/0x180<br /> [ +0.000008] device_release_driver_internal+0x3d4/0x5a0<br /> [ +0.000007] device_release_driver+0x12/0x20<br /> [ +0.000004] pci_stop_bus_device+0x104/0x150<br /> [ +0.000006] pci_stop_and_remove_bus_device_locked+0x1b/0x40<br /> [ +0.000005] remove_store+0xd7/0xf0<br /> [ +0.000005] ? __pfx_remove_store+0x10/0x10<br /> [ +0.000006] ? __pfx__copy_from_iter+0x10/0x10<br /> [ +0.000006] ? __pfx_dev_attr_store+0x10/0x10<br /> [ +0.000006] dev_attr_store+0x3f/0x80<br /> [ +0.000006] sysfs_kf_write+0x125/0x1d0<br /> [ +0.000004] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? __kasan_check_write+0x14/0x30<br /> [ +0.000005] kernfs_fop_write_iter+0x2ea/0x490<br /> [ +0.000005] ? rw_verify_area+0x70/0x420<br /> [ +0.000005] ? __pfx_kernfs_fop_write_iter+0x10/0x10<br /> [ +0.000006] vfs_write+0x90d/0xe70<br /> [ +0.000005] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000005] ? __pfx_vfs_write+0x10/0x10<br /> [ +0.000004] ? local_clock+0x15/0x30<br /> [ +0.000008] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? __kasan_slab_free+0x5f/0x80<br /> [ +0.000005] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? __kasan_check_read+0x11/0x20<br /> [ +0.000004] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? fdget_pos+0x1d3/0x500<br /> [ +0.000007] ksys_write+0x119/0x220<br /> [ +0.000005] ? putname+0x1c/0x30<br /> [ +0.000006] ? __pfx_ksys_write+0x10/0x10<br /> [ +0.000007] __x64_sys_write+0x72/0xc0<br /> [ +0.000006] x64_sys_call+0x18ab/0x26f0<br /> [ +0.000006] do_syscall_64+0x7c/0x170<br /> [ +0.000004] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? __pfx___x64_sys_openat+0x10/0x10<br /> [ +0.000006] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? __kasan_check_read+0x11/0x20<br /> [ +0.000003] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? fpregs_assert_state_consistent+0x21/0xb0<br /> [ +0.000006] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? syscall_exit_to_user_mode+0x4e/0x240<br /> [ +0.000005] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? do_syscall_64+0x88/0x170<br /> [ +0.000003] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000004] ? irqentry_exit+0x43/0x50<br /> [ +0.000004] ? srso_return_thunk+0x5<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: Fix possible OOB access in mt7996_tx()<br /> <br /> Fis possible Out-Of-Boundary access in mt7996_tx routine if link_id is<br /> set to IEEE80211_LINK_UNSPECIFIED

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: fix double free in &amp;#39;hci_discovery_filter_clear()&amp;#39;<br /> <br /> Function &amp;#39;hci_discovery_filter_clear()&amp;#39; frees &amp;#39;uuids&amp;#39; array and then<br /> sets it to NULL. There is a tiny chance of the following race:<br /> <br /> &amp;#39;hci_cmd_sync_work()&amp;#39;<br /> <br /> &amp;#39;update_passive_scan_sync()&amp;#39;<br /> <br /> &amp;#39;hci_update_passive_scan_sync()&amp;#39;<br /> <br /> &amp;#39;hci_discovery_filter_clear()&amp;#39;<br /> kfree(uuids);<br /> <br /> <br /> &amp;#39;start_service_discovery()&amp;#39;<br /> <br /> &amp;#39;hci_discovery_filter_clear()&amp;#39;<br /> kfree(uuids); // DOUBLE FREE<br /> <br /> <br /> <br /> uuids = NULL;<br /> <br /> To fix it let&amp;#39;s add locking around &amp;#39;kfree()&amp;#39; call and NULL pointer<br /> assignment. Otherwise the following backtrace fires:<br /> <br /> [ ] ------------[ cut here ]------------<br /> [ ] kernel BUG at mm/slub.c:547!<br /> [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP<br /> [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1<br /> [ ] Tainted: [O]=OOT_MODULE<br /> [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ ] pc : __slab_free+0xf8/0x348<br /> [ ] lr : __slab_free+0x48/0x348<br /> ...<br /> [ ] Call trace:<br /> [ ] __slab_free+0xf8/0x348<br /> [ ] kfree+0x164/0x27c<br /> [ ] start_service_discovery+0x1d0/0x2c0<br /> [ ] hci_sock_sendmsg+0x518/0x924<br /> [ ] __sock_sendmsg+0x54/0x60<br /> [ ] sock_write_iter+0x98/0xf8<br /> [ ] do_iter_readv_writev+0xe4/0x1c8<br /> [ ] vfs_writev+0x128/0x2b0<br /> [ ] do_writev+0xfc/0x118<br /> [ ] __arm64_sys_writev+0x20/0x2c<br /> [ ] invoke_syscall+0x68/0xf0<br /> [ ] el0_svc_common.constprop.0+0x40/0xe0<br /> [ ] do_el0_svc+0x1c/0x28<br /> [ ] el0_svc+0x30/0xd0<br /> [ ] el0t_64_sync_handler+0x100/0x12c<br /> [ ] el0t_64_sync+0x194/0x198<br /> [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)<br /> [ ] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: prevent infinite loop in rt6_nlmsg_size()<br /> <br /> While testing prior patch, I was able to trigger<br /> an infinite loop in rt6_nlmsg_size() in the following place:<br /> <br /> list_for_each_entry_rcu(sibling, &amp;f6i-&gt;fib6_siblings,<br /> fib6_siblings) {<br /> rt6_nh_nlmsg_size(sibling-&gt;fib6_nh, &amp;nexthop_len);<br /> }<br /> <br /> This is because fib6_del_route() and fib6_add_rt2node()<br /> uses list_del_rcu(), which can confuse rcu readers,<br /> because they might no longer see the head of the list.<br /> <br /> Restart the loop if f6i-&gt;fib6_nsiblings is zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix possible infinite loop in fib6_info_uses_dev()<br /> <br /> fib6_info_uses_dev() seems to rely on RCU without an explicit<br /> protection.<br /> <br /> Like the prior fix in rt6_nlmsg_size(),<br /> we need to make sure fib6_del_route() or fib6_add_rt2node()<br /> have not removed the anchor from the list, or we risk an infinite loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Fix fp initialization for exception boundary<br /> <br /> In the ARM64 BPF JIT when prog-&gt;aux-&gt;exception_boundary is set for a BPF<br /> program, find_used_callee_regs() is not called because for a program<br /> acting as exception boundary, all callee saved registers are saved.<br /> find_used_callee_regs() sets `ctx-&gt;fp_used = true;` when it sees FP<br /> being used in any of the instructions.<br /> <br /> For programs acting as exception boundary, ctx-&gt;fp_used remains false<br /> even if frame pointer is used by the program and therefore, FP is not<br /> set-up for such programs in the prologue. This can cause the kernel to<br /> crash due to a pagefault.<br /> <br /> Fix it by setting ctx-&gt;fp_used = true for exception boundary programs as<br /> fp is always saved in such programs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> neighbour: Fix null-ptr-deref in neigh_flush_dev().<br /> <br /> kernel test robot reported null-ptr-deref in neigh_flush_dev(). [0]<br /> <br /> The cited commit introduced per-netdev neighbour list and converted<br /> neigh_flush_dev() to use it instead of the global hash table.<br /> <br /> One thing we missed is that neigh_table_clear() calls neigh_ifdown()<br /> with NULL dev.<br /> <br /> Let&amp;#39;s restore the hash table iteration.<br /> <br /> Note that IPv6 module is no longer unloadable, so neigh_table_clear()<br /> is called only when IPv6 fails to initialise, which is unlikely to<br /> happen.<br /> <br /> [0]:<br /> IPv6: Attempt to unregister permanent protocol 136<br /> IPv6: Attempt to unregister permanent protocol 17<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc00000001a0: 0000 [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000d00-0x0000000000000d07]<br /> CPU: 1 UID: 0 PID: 1 Comm: systemd Tainted: G T 6.12.0-rc6-01246-gf7f52738637f #1<br /> Tainted: [T]=RANDSTRUCT<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> RIP: 0010:neigh_flush_dev.llvm.6395807810224103582+0x52/0x570<br /> Code: c1 e8 03 42 8a 04 38 84 c0 0f 85 15 05 00 00 31 c0 41 83 3e 0a 0f 94 c0 48 8d 1c c3 48 81 c3 f8 0c 00 00 48 89 d8 48 c1 e8 03 80 3c 38 00 74 08 48 89 df e8 f7 49 93 fe 4c 8b 3b 4d 85 ff 0f<br /> RSP: 0000:ffff88810026f408 EFLAGS: 00010206<br /> RAX: 00000000000001a0 RBX: 0000000000000d00 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffc0631640<br /> RBP: ffff88810026f470 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffffffffc0625250 R14: ffffffffc0631640 R15: dffffc0000000000<br /> FS: 00007f575cb83940(0000) GS:ffff8883aee00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f575db40008 CR3: 00000002bf936000 CR4: 00000000000406f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __neigh_ifdown.llvm.6395807810224103582+0x44/0x390<br /> neigh_table_clear+0xb1/0x268<br /> ndisc_cleanup+0x21/0x38 [ipv6]<br /> init_module+0x2f5/0x468 [ipv6]<br /> do_one_initcall+0x1ba/0x628<br /> do_init_module+0x21a/0x530<br /> load_module+0x2550/0x2ea0<br /> __se_sys_finit_module+0x3d2/0x620<br /> __x64_sys_finit_module+0x76/0x88<br /> x64_sys_call+0x7ff/0xde8<br /> do_syscall_64+0xfb/0x1e8<br /> entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> RIP: 0033:0x7f575d6f2719<br /> Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 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 3d 01 f0 ff ff 73 01 c3 48 8b 0d b7 06 0d 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007fff82a2a268 EFLAGS: 00000246 ORIG_RAX: 0000000000000139<br /> RAX: ffffffffffffffda RBX: 0000557827b45310 RCX: 00007f575d6f2719<br /> RDX: 0000000000000000 RSI: 00007f575d584efd RDI: 0000000000000004<br /> RBP: 00007f575d584efd R08: 0000000000000000 R09: 0000557827b47b00<br /> R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000020000<br /> R13: 0000000000000000 R14: 0000557827b470e0 R15: 00007f575dbb4270<br /> <br /> Modules linked in: ipv6(+)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Remove skb secpath if xfrm state is not found<br /> <br /> Hardware returns a unique identifier for a decrypted packet&amp;#39;s xfrm<br /> state, this state is looked up in an xarray. However, the state might<br /> have been freed by the time of this lookup.<br /> <br /> Currently, if the state is not found, only a counter is incremented.<br /> The secpath (sp) extension on the skb is not removed, resulting in<br /> sp-&gt;len becoming 0.<br /> <br /> Subsequently, functions like __xfrm_policy_check() attempt to access<br /> fields such as xfrm_input_state(skb)-&gt;xso.type (which dereferences<br /> sp-&gt;xvec[sp-&gt;len - 1]) without first validating sp-&gt;len. This leads to<br /> a crash when dereferencing an invalid state pointer.<br /> <br /> This patch prevents the crash by explicitly removing the secpath<br /> extension from the skb if the xfrm state is not found after hardware<br /> decryption. This ensures downstream functions do not operate on a<br /> zero-length secpath.<br /> <br /> BUG: unable to handle page fault for address: ffffffff000002c8<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 282e067 P4D 282e067 PUD 0<br /> Oops: Oops: 0000 [#1] SMP<br /> CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__xfrm_policy_check+0x61a/0xa30<br /> Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa<br /> RSP: 0018:ffff88885fb04918 EFLAGS: 00010297<br /> RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000<br /> RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353<br /> R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8<br /> R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00<br /> FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? try_to_wake_up+0x108/0x4c0<br /> ? udp4_lib_lookup2+0xbe/0x150<br /> ? udp_lib_lport_inuse+0x100/0x100<br /> ? __udp4_lib_lookup+0x2b0/0x410<br /> __xfrm_policy_check2.constprop.0+0x11e/0x130<br /> udp_queue_rcv_one_skb+0x1d/0x530<br /> udp_unicast_rcv_skb+0x76/0x90<br /> __udp4_lib_rcv+0xa64/0xe90<br /> ip_protocol_deliver_rcu+0x20/0x130<br /> ip_local_deliver_finish+0x75/0xa0<br /> ip_local_deliver+0xc1/0xd0<br /> ? ip_protocol_deliver_rcu+0x130/0x130<br /> ip_sublist_rcv+0x1f9/0x240<br /> ? ip_rcv_finish_core+0x430/0x430<br /> ip_list_rcv+0xfc/0x130<br /> __netif_receive_skb_list_core+0x181/0x1e0<br /> netif_receive_skb_list_internal+0x200/0x360<br /> ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core]<br /> gro_receive_skb+0xfd/0x210<br /> mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core]<br /> mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core]<br /> ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core]<br /> mlx5e_napi_poll+0x114/0xab0 [mlx5_core]<br /> __napi_poll+0x25/0x170<br /> net_rx_action+0x32d/0x3a0<br /> ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core]<br /> ? notifier_call_chain+0x33/0xa0<br /> handle_softirqs+0xda/0x250<br /> irq_exit_rcu+0x6d/0xc0<br /> common_interrupt+0x81/0xa0<br />