Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb3: missing lock when picking channel<br /> <br /> Coverity spotted a place where we should have been holding the<br /> channel lock when accessing the ses channel index.<br /> <br /> Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/hugetlb: fix missing hugetlb_lock for resv uncharge<br /> <br /> There is a recent report on UFFDIO_COPY over hugetlb:<br /> <br /> https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/<br /> <br /> 350: lockdep_assert_held(&amp;hugetlb_lock);<br /> <br /> Should be an issue in hugetlb but triggered in an userfault context, where<br /> it goes into the unlikely path where two threads modifying the resv map<br /> together. Mike has a fix in that path for resv uncharge but it looks like<br /> the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()<br /> will update the cgroup pointer, so it requires to be called with the lock<br /> held.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix the pre-flush when appending to a file in writethrough mode<br /> <br /> In netfs_perform_write(), when the file is marked NETFS_ICTX_WRITETHROUGH<br /> or O_*SYNC or RWF_*SYNC was specified, write-through caching is performed<br /> on a buffered file. When setting up for write-through, we flush any<br /> conflicting writes in the region and wait for the write to complete,<br /> failing if there&amp;#39;s a write error to return.<br /> <br /> The issue arises if we&amp;#39;re writing at or above the EOF position because we<br /> skip the flush and - more importantly - the wait. This becomes a problem<br /> if there&amp;#39;s a partial folio at the end of the file that is being written out<br /> and we want to make a write to it too. Both the already-running write and<br /> the write we start both want to clear the writeback mark, but whoever is<br /> second causes a warning looking something like:<br /> <br /> ------------[ cut here ]------------<br /> R=00000012: folio 11 is not under writeback<br /> WARNING: CPU: 34 PID: 654 at fs/netfs/write_collect.c:105<br /> ...<br /> CPU: 34 PID: 654 Comm: kworker/u386:27 Tainted: G S ...<br /> ...<br /> Workqueue: events_unbound netfs_write_collection_worker<br /> ...<br /> RIP: 0010:netfs_writeback_lookup_folio<br /> <br /> Fix this by making the flush-and-wait unconditional. It will do nothing if<br /> there are no folios in the pagecache and will return quickly if there are<br /> no folios in the region specified.<br /> <br /> Further, move the WBC attachment above the flush call as the flush is going<br /> to attach a WBC and detach it again if it is not present - and since we<br /> need one anyway we might as well share it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpll: fix dpll_pin_on_pin_register() for multiple parent pins<br /> <br /> In scenario where pin is registered with multiple parent pins via<br /> dpll_pin_on_pin_register(..), all belonging to the same dpll device.<br /> A second call to dpll_pin_on_pin_unregister(..) would cause a call trace,<br /> as it tries to use already released registration resources (due to fix<br /> introduced in b446631f355e). In this scenario pin was registered twice,<br /> so resources are not yet expected to be release until each registered<br /> pin/pin pair is unregistered.<br /> <br /> Currently, the following crash/call trace is produced when ice driver is<br /> removed on the system with installed E810T NIC which includes dpll device:<br /> <br /> WARNING: CPU: 51 PID: 9155 at drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30<br /> RIP: 0010:dpll_pin_ops+0x20/0x30<br /> Call Trace:<br /> ? __warn+0x7f/0x130<br /> ? dpll_pin_ops+0x20/0x30<br /> dpll_msg_add_pin_freq+0x37/0x1d0<br /> dpll_cmd_pin_get_one+0x1c0/0x400<br /> ? __nlmsg_put+0x63/0x80<br /> dpll_pin_event_send+0x93/0x140<br /> dpll_pin_on_pin_unregister+0x3f/0x100<br /> ice_dpll_deinit_pins+0xa1/0x230 [ice]<br /> ice_remove+0xf1/0x210 [ice]<br /> <br /> Fix by adding a parent pointer as a cookie when creating a registration,<br /> also when searching for it. For the regular pins pass NULL, this allows to<br /> create separated registration for each parent the pin is registered with.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix LAG and VF lock dependency in ice_reset_vf()<br /> <br /> 9f74a3dfcf83 ("ice: Fix VF Reset paths when interface in a failed over<br /> aggregate"), the ice driver has acquired the LAG mutex in ice_reset_vf().<br /> The commit placed this lock acquisition just prior to the acquisition of<br /> the VF configuration lock.<br /> <br /> If ice_reset_vf() acquires the configuration lock via the ICE_VF_RESET_LOCK<br /> flag, this could deadlock with ice_vc_cfg_qs_msg() because it always<br /> acquires the locks in the order of the VF configuration lock and then the<br /> LAG mutex.<br /> <br /> Lockdep reports this violation almost immediately on creating and then<br /> removing 2 VF:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.8.0-rc6 #54 Tainted: G W O<br /> ------------------------------------------------------<br /> kworker/60:3/6771 is trying to acquire lock:<br /> ff40d43e099380a0 (&amp;vf-&gt;cfg_lock){+.+.}-{3:3}, at: ice_reset_vf+0x22f/0x4d0 [ice]<br /> <br /> but task is already holding lock:<br /> ff40d43ea1961210 (&amp;pf-&gt;lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (&amp;pf-&gt;lag_mutex){+.+.}-{3:3}:<br /> __lock_acquire+0x4f8/0xb40<br /> lock_acquire+0xd4/0x2d0<br /> __mutex_lock+0x9b/0xbf0<br /> ice_vc_cfg_qs_msg+0x45/0x690 [ice]<br /> ice_vc_process_vf_msg+0x4f5/0x870 [ice]<br /> __ice_clean_ctrlq+0x2b5/0x600 [ice]<br /> ice_service_task+0x2c9/0x480 [ice]<br /> process_one_work+0x1e9/0x4d0<br /> worker_thread+0x1e1/0x3d0<br /> kthread+0x104/0x140<br /> ret_from_fork+0x31/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> -&gt; #0 (&amp;vf-&gt;cfg_lock){+.+.}-{3:3}:<br /> check_prev_add+0xe2/0xc50<br /> validate_chain+0x558/0x800<br /> __lock_acquire+0x4f8/0xb40<br /> lock_acquire+0xd4/0x2d0<br /> __mutex_lock+0x9b/0xbf0<br /> ice_reset_vf+0x22f/0x4d0 [ice]<br /> ice_process_vflr_event+0x98/0xd0 [ice]<br /> ice_service_task+0x1cc/0x480 [ice]<br /> process_one_work+0x1e9/0x4d0<br /> worker_thread+0x1e1/0x3d0<br /> kthread+0x104/0x140<br /> ret_from_fork+0x31/0x50<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;pf-&gt;lag_mutex);<br /> lock(&amp;vf-&gt;cfg_lock);<br /> lock(&amp;pf-&gt;lag_mutex);<br /> lock(&amp;vf-&gt;cfg_lock);<br /> <br /> *** DEADLOCK ***<br /> 4 locks held by kworker/60:3/6771:<br /> #0: ff40d43e05428b38 ((wq_completion)ice){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0<br /> #1: ff50d06e05197e58 ((work_completion)(&amp;pf-&gt;serv_task)){+.+.}-{0:0}, at: process_one_work+0x176/0x4d0<br /> #2: ff40d43ea1960e50 (&amp;pf-&gt;vfs.table_lock){+.+.}-{3:3}, at: ice_process_vflr_event+0x48/0xd0 [ice]<br /> #3: ff40d43ea1961210 (&amp;pf-&gt;lag_mutex){+.+.}-{3:3}, at: ice_reset_vf+0xb7/0x4d0 [ice]<br /> <br /> stack backtrace:<br /> CPU: 60 PID: 6771 Comm: kworker/60:3 Tainted: G W O 6.8.0-rc6 #54<br /> Hardware name:<br /> Workqueue: ice ice_service_task [ice]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x4a/0x80<br /> check_noncircular+0x12d/0x150<br /> check_prev_add+0xe2/0xc50<br /> ? save_trace+0x59/0x230<br /> ? add_chain_cache+0x109/0x450<br /> validate_chain+0x558/0x800<br /> __lock_acquire+0x4f8/0xb40<br /> ? lockdep_hardirqs_on+0x7d/0x100<br /> lock_acquire+0xd4/0x2d0<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? lock_is_held_type+0xc7/0x120<br /> __mutex_lock+0x9b/0xbf0<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? rcu_is_watching+0x11/0x50<br /> ? ice_reset_vf+0x22f/0x4d0 [ice]<br /> ice_reset_vf+0x22f/0x4d0 [ice]<br /> ? process_one_work+0x176/0x4d0<br /> ice_process_vflr_event+0x98/0xd0 [ice]<br /> ice_service_task+0x1cc/0x480 [ice]<br /> process_one_work+0x1e9/0x4d0<br /> worker_thread+0x1e1/0x3d0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x104/0x140<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x31/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> To avoid deadlock, we must acquire the LAG <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: check for NULL idev in ip_route_use_hint()<br /> <br /> syzbot was able to trigger a NULL deref in fib_validate_source()<br /> in an old tree [1].<br /> <br /> It appears the bug exists in latest trees.<br /> <br /> All calls to __in_dev_get_rcu() must be checked for a NULL result.<br /> <br /> [1]<br /> general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425<br /> Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf<br /> RSP: 0018:ffffc900015fee40 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0<br /> RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0<br /> RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000<br /> R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000<br /> R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000<br /> FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231<br /> ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327<br /> ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]<br /> ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638<br /> ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673<br /> __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]<br /> __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620<br /> __netif_receive_skb_list net/core/dev.c:5672 [inline]<br /> netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764<br /> netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816<br /> xdp_recv_frames net/bpf/test_run.c:257 [inline]<br /> xdp_test_run_batch net/bpf/test_run.c:335 [inline]<br /> bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363<br /> bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376<br /> bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736<br /> __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115<br /> __do_sys_bpf kernel/bpf/syscall.c:5201 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5199 [inline]<br /> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: Fix netdev refcount issue<br /> <br /> The dev_tracker is added to ax25_cb in ax25_bind(). When the<br /> ax25 device is detaching, the dev_tracker of ax25_cb should be<br /> deallocated in ax25_kill_by_device() instead of the dev_tracker<br /> of ax25_dev. The log reported by ref_tracker is shown below:<br /> <br /> [ 80.884935] ref_tracker: reference already released.<br /> [ 80.885150] ref_tracker: allocated in:<br /> [ 80.885349] ax25_dev_device_up+0x105/0x540<br /> [ 80.885730] ax25_device_event+0xa4/0x420<br /> [ 80.885730] notifier_call_chain+0xc9/0x1e0<br /> [ 80.885730] __dev_notify_flags+0x138/0x280<br /> [ 80.885730] dev_change_flags+0xd7/0x180<br /> [ 80.885730] dev_ifsioc+0x6a9/0xa30<br /> [ 80.885730] dev_ioctl+0x4d8/0xd90<br /> [ 80.885730] sock_do_ioctl+0x1c2/0x2d0<br /> [ 80.885730] sock_ioctl+0x38b/0x4f0<br /> [ 80.885730] __se_sys_ioctl+0xad/0xf0<br /> [ 80.885730] do_syscall_64+0xc4/0x1b0<br /> [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> [ 80.885730] ref_tracker: freed in:<br /> [ 80.885730] ax25_device_event+0x272/0x420<br /> [ 80.885730] notifier_call_chain+0xc9/0x1e0<br /> [ 80.885730] dev_close_many+0x272/0x370<br /> [ 80.885730] unregister_netdevice_many_notify+0x3b5/0x1180<br /> [ 80.885730] unregister_netdev+0xcf/0x120<br /> [ 80.885730] sixpack_close+0x11f/0x1b0<br /> [ 80.885730] tty_ldisc_kill+0xcb/0x190<br /> [ 80.885730] tty_ldisc_hangup+0x338/0x3d0<br /> [ 80.885730] __tty_hangup+0x504/0x740<br /> [ 80.885730] tty_release+0x46e/0xd80<br /> [ 80.885730] __fput+0x37f/0x770<br /> [ 80.885730] __x64_sys_close+0x7b/0xb0<br /> [ 80.885730] do_syscall_64+0xc4/0x1b0<br /> [ 80.885730] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> [ 80.893739] ------------[ cut here ]------------<br /> [ 80.894030] WARNING: CPU: 2 PID: 140 at lib/ref_tracker.c:255 ref_tracker_free+0x47b/0x6b0<br /> [ 80.894297] Modules linked in:<br /> [ 80.894929] CPU: 2 PID: 140 Comm: ax25_conn_rel_6 Not tainted 6.9.0-rc4-g8cd26fd90c1a #11<br /> [ 80.895190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qem4<br /> [ 80.895514] RIP: 0010:ref_tracker_free+0x47b/0x6b0<br /> [ 80.895808] Code: 83 c5 18 4c 89 eb 48 c1 eb 03 8a 04 13 84 c0 0f 85 df 01 00 00 41 83 7d 00 00 75 4b 4c 89 ff 9<br /> [ 80.896171] RSP: 0018:ffff888009edf8c0 EFLAGS: 00000286<br /> [ 80.896339] RAX: 1ffff1100141ac00 RBX: 1ffff1100149463b RCX: dffffc0000000000<br /> [ 80.896502] RDX: 0000000000000001 RSI: 0000000000000246 RDI: ffff88800a0d6518<br /> [ 80.896925] RBP: ffff888009edf9b0 R08: ffff88806d3288d3 R09: 1ffff1100da6511a<br /> [ 80.897212] R10: dffffc0000000000 R11: ffffed100da6511b R12: ffff88800a4a31d4<br /> [ 80.897859] R13: ffff88800a4a31d8 R14: dffffc0000000000 R15: ffff88800a0d6518<br /> [ 80.898279] FS: 00007fd88b7fe700(0000) GS:ffff88806d300000(0000) knlGS:0000000000000000<br /> [ 80.899436] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 80.900181] CR2: 00007fd88c001d48 CR3: 000000000993e000 CR4: 00000000000006f0<br /> ...<br /> [ 80.935774] ref_tracker: sp%d@000000000bb9df3d has 1/1 users at<br /> [ 80.935774] ax25_bind+0x424/0x4e0<br /> [ 80.935774] __sys_bind+0x1d9/0x270<br /> [ 80.935774] __x64_sys_bind+0x75/0x80<br /> [ 80.935774] do_syscall_64+0xc4/0x1b0<br /> [ 80.935774] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> <br /> Change ax25_dev-&gt;dev_tracker to the dev_tracker of ax25_cb<br /> in order to mitigate the bug.

A vulnerability classified as problematic was found in PHPGurukul Directory Management System 1.0. Affected by this vulnerability is an unknown functionality of the file /admin/admin-profile.php of the component Searchbar. The manipulation leads to cross site scripting. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-265213 was assigned to this vulnerability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix warning during rehash<br /> <br /> As previously explained, the rehash delayed work migrates filters from<br /> one region to another. This is done by iterating over all chunks (all<br /> the filters with the same priority) in the region and in each chunk<br /> iterating over all the filters.<br /> <br /> When the work runs out of credits it stores the current chunk and entry<br /> as markers in the per-work context so that it would know where to resume<br /> the migration from the next time the work is scheduled.<br /> <br /> Upon error, the chunk marker is reset to NULL, but without resetting the<br /> entry markers despite being relative to it. This can result in migration<br /> being resumed from an entry that does not belong to the chunk being<br /> migrated. In turn, this will eventually lead to a chunk being iterated<br /> over as if it is an entry. Because of how the two structures happen to<br /> be defined, this does not lead to KASAN splats, but to warnings such as<br /> [1].<br /> <br /> Fix by creating a helper that resets all the markers and call it from<br /> all the places the currently only reset the chunk marker. For good<br /> measures also call it when starting a completely new rehash. Add a<br /> warning to avoid future cases.<br /> <br /> [1]<br /> WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0<br /> Modules linked in:<br /> CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29<br /> Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019<br /> Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work<br /> RIP: 0010:mlxsw_afk_encode+0x242/0x2f0<br /> [...]<br /> Call Trace:<br /> <br /> mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0<br /> mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0<br /> mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290<br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470<br /> process_one_work+0x151/0x370<br /> worker_thread+0x2cb/0x3e0<br /> kthread+0xd0/0x100<br /> ret_from_fork+0x34/0x50<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix incorrect list API usage<br /> <br /> Both the function that migrates all the chunks within a region and the<br /> function that migrates all the entries within a chunk call<br /> list_first_entry() on the respective lists without checking that the<br /> lists are not empty. This is incorrect usage of the API, which leads to<br /> the following warning [1].<br /> <br /> Fix by returning if the lists are empty as there is nothing to migrate<br /> in this case.<br /> <br /> [1]<br /> WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c:1266 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0&gt;<br /> Modules linked in:<br /> CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39<br /> Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019<br /> Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work<br /> RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0<br /> [...]<br /> Call Trace:<br /> <br /> mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0<br /> process_one_work+0x151/0x370<br /> worker_thread+0x2cb/0x3e0<br /> kthread+0xd0/0x100<br /> ret_from_fork+0x34/0x50<br /> ret_from_fork_asm+0x1a/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: honor table dormant flag from netdev release event path<br /> <br /> Check for table dormant flag otherwise netdev release event path tries<br /> to unregister an already unregistered hook.<br /> <br /> [524854.857999] ------------[ cut here ]------------<br /> [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260<br /> [...]<br /> [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365<br /> [524854.858869] Workqueue: netns cleanup_net<br /> [524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260<br /> [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41<br /> [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246<br /> [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a<br /> [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438<br /> [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34<br /> [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005<br /> [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00<br /> [524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000<br /> [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0<br /> [524854.859000] Call Trace:<br /> [524854.859006] <br /> [524854.859013] ? __warn+0x9f/0x1a0<br /> [524854.859027] ? __nf_unregister_net_hook+0x21a/0x260<br /> [524854.859044] ? report_bug+0x1b1/0x1e0<br /> [524854.859060] ? handle_bug+0x3c/0x70<br /> [524854.859071] ? exc_invalid_op+0x17/0x40<br /> [524854.859083] ? asm_exc_invalid_op+0x1a/0x20<br /> [524854.859100] ? __nf_unregister_net_hook+0x6a/0x260<br /> [524854.859116] ? __nf_unregister_net_hook+0x21a/0x260<br /> [524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables]<br /> [524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]<br /> [524854.859461] ? packet_notifier+0xb3/0x360<br /> [524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40<br /> [524854.859489] ? dcbnl_netdevice_event+0x35/0x140<br /> [524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]<br /> [524854.859661] notifier_call_chain+0x7d/0x140<br /> [524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Do not use WQ_MEM_RECLAIM flag for workqueue<br /> <br /> Issue reported by customer during SRIOV testing, call trace:<br /> When both i40e and the i40iw driver are loaded, a warning<br /> in check_flush_dependency is being triggered. This seems<br /> to be because of the i40e driver workqueue is allocated with<br /> the WQ_MEM_RECLAIM flag, and the i40iw one is not.<br /> <br /> Similar error was encountered on ice too and it was fixed by<br /> removing the flag. Do the same for i40e too.<br /> <br /> [Feb 9 09:08] ------------[ cut here ]------------<br /> [ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is<br /> flushing !WQ_MEM_RECLAIM infiniband:0x0<br /> [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966<br /> check_flush_dependency+0x10b/0x120<br /> [ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq<br /> snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4<br /> nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr<br /> rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma<br /> intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif<br /> isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal<br /> intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core<br /> iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore<br /> ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich<br /> intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad<br /> xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe<br /> drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel<br /> libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror<br /> dm_region_hash dm_log dm_mod fuse<br /> [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not<br /> tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1<br /> [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS<br /> SE5C620.86B.02.01.0013.121520200651 12/15/2020<br /> [ +0.000001] Workqueue: i40e i40e_service_task [i40e]<br /> [ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120<br /> [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48<br /> 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd<br /> ff 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90<br /> [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282<br /> [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:<br /> 0000000000000027<br /> [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:<br /> ffff94d47f620bc0<br /> [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:<br /> 00000000ffff7fff<br /> [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:<br /> ffff94c5451ea180<br /> [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:<br /> ffff94c5f1330ab0<br /> [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)<br /> knlGS:0000000000000000<br /> [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:<br /> 00000000007706f0<br /> [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:<br /> 0000000000000000<br /> [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:<br /> 0000000000000400<br /> [ +0.000001] PKRU: 55555554<br /> [ +0.000001] Call Trace:<br /> [ +0.000001] <br /> [ +0.000002] ? __warn+0x80/0x130<br /> [ +0.000003] ? check_flush_dependency+0x10b/0x120<br /> [ +0.000002] ? report_bug+0x195/0x1a0<br /> [ +0.000005] ? handle_bug+0x3c/0x70<br /> [ +0.000003] ? exc_invalid_op+0x14/0x70<br /> [ +0.000002] ? asm_exc_invalid_op+0x16/0x20<br /> [ +0.000006] ? check_flush_dependency+0x10b/0x120<br /> [ +0.000002] ? check_flush_dependency+0x10b/0x120<br /> [ +0.000002] __flush_workqueue+0x126/0x3f0<br /> [ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core]<br /> [ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core]<br /> [ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core]<br /> [ +0.000020] i40iw_close+0x4b/0x90 [irdma]<br /> [ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]<br /> [ +0.000035] i40e_service_task+0x126/0x190 [i40e]<br /> [ +0.000024] process_one_work+0x174/0x340<br /> [ +0.000003] worker_th<br /> ---truncated---