xamxte/cve-to-cwe huggingface dataset:
CVE-2024-35880: In the Linux kernel, the following vulnerability has been resolved:  io_uring/kbuf: hold io_buffer_list reference over mmap  If we look up the kbuf, ensure that it doesn't get unregistered until after we're done with it. Since we're inside mmap, we cannot safely use the io_uring lock. Rely on the fact that we can lookup the buffer list under RCU now and grab a reference to it, preventing it from being unregistered until we're done with it. The lookup returns the io_buffer_list directly with it referenced.
CVE-2024-35910: In the Linux kernel, the following vulnerability has been resolved:  tcp: properly terminate timers for kernel sockets  We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled.  Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago.  When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers.  inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later.  For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns.  For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns.  This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler.  Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held.  It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)  We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future.
CVE-2024-35924: In the Linux kernel, the following vulnerability has been resolved:  usb: typec: ucsi: Limit read size on v1.2  Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was increased from 16 to 256. In order to avoid overflowing reads for older systems, add a mechanism to use the read UCSI version to truncate read sizes on UCSI v1.2.
CVE-2024-35938: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: decrease MHI channel buffer length to 8KB  Currently buf_len field of ath11k_mhi_config_qca6390 is assigned with 0, making MHI use a default size, 64KB, to allocate channel buffers. This is likely to fail in some scenarios where system memory is highly fragmented and memory compaction or reclaim is not allowed.  There is a fail report which is caused by it: kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0 CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb Workqueue: events_unbound async_run_entry_fn Call Trace:  <TASK>  dump_stack_lvl+0x47/0x60  warn_alloc+0x13a/0x1b0  ? srso_alias_return_thunk+0x5/0xfbef5  ? __alloc_pages_direct_compact+0xab/0x210  __alloc_pages_slowpath.constprop.0+0xd3e/0xda0  __alloc_pages+0x32d/0x350  ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]  __kmalloc_large_node+0x72/0x110  __kmalloc+0x37c/0x480  ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]  ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]  mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]  __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]  ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]  device_for_each_child+0x5c/0xa0  ? __pfx_pci_pm_resume+0x10/0x10  ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e]  ? srso_alias_return_thunk+0x5/0xfbef5  ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec]  ? srso_alias_return_thunk+0x5/0xfbef5  dpm_run_callback+0x8c/0x1e0  device_resume+0x104/0x340  ? __pfx_dpm_watchdog_handler+0x10/0x10  async_resume+0x1d/0x30  async_run_entry_fn+0x32/0x120  process_one_work+0x168/0x330  worker_thread+0x2f5/0x410  ? __pfx_worker_thread+0x10/0x10  kthread+0xe8/0x120  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x34/0x50  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1b/0x30  </TASK>  Actually those buffers are used only by QMI target -> host communication. And for WCN6855 and QCA6390, the largest packet size for that is less than 6KB. So change buf_len field to 8KB, which results in order 1 allocation if page size is 4KB. In this way, we can at least save some memory, and as well as decrease the possibility of allocation failure in those scenarios.  Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
CVE-2024-35950: In the Linux kernel, the following vulnerability has been resolved:  drm/client: Fully protect modes[] with dev->mode_config.mutex  The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory.
CVE-2024-35962: In the Linux kernel, the following vulnerability has been resolved:  netfilter: complete validation of user input  In my recent commit, I missed that do_replace() handlers use copy_from_sockptr() (which I fixed), followed by unsafe copy_from_sockptr_offset() calls.  In all functions, we can perform the @optlen validation before even calling xt_alloc_table_info() with the following check:  if ((u64)optlen < (u64)tmp.size + sizeof(tmp))         return -EINVAL;
CVE-2024-35975: In the Linux kernel, the following vulnerability has been resolved:  octeontx2-pf: Fix transmit scheduler resource leak  Inorder to support shaping and scheduling, Upon class creation Netdev driver allocates trasmit schedulers.  The previous patch which added support for Round robin scheduling has a bug due to which driver is not freeing transmit schedulers post class deletion.  This patch fixes the same.
CVE-2024-36002: In the Linux kernel, the following vulnerability has been resolved:  dpll: fix dpll_pin_on_pin_register() for multiple parent pins  In scenario where pin is registered with multiple parent pins via dpll_pin_on_pin_register(..), all belonging to the same dpll device. A second call to dpll_pin_on_pin_unregister(..) would cause a call trace, as it tries to use already released registration resources (due to fix introduced in b446631f355e). In this scenario pin was registered twice, so resources are not yet expected to be release until each registered pin/pin pair is unregistered.  Currently, the following crash/call trace is produced when ice driver is removed on the system with installed E810T NIC which includes dpll device:  WARNING: CPU: 51 PID: 9155 at drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30 RIP: 0010:dpll_pin_ops+0x20/0x30 Call Trace:  ? __warn+0x7f/0x130  ? dpll_pin_ops+0x20/0x30  dpll_msg_add_pin_freq+0x37/0x1d0  dpll_cmd_pin_get_one+0x1c0/0x400  ? __nlmsg_put+0x63/0x80  dpll_pin_event_send+0x93/0x140  dpll_pin_on_pin_unregister+0x3f/0x100  ice_dpll_deinit_pins+0xa1/0x230 [ice]  ice_remove+0xf1/0x210 [ice]  Fix by adding a parent pointer as a cookie when creating a registration, also when searching for it. For the regular pins pass NULL, this allows to create separated registration for each parent the pin is registered with.
CVE-2024-3155: The Post Grid, Form Maker, Popup Maker, WooCommerce Blocks, Post Blocks, Post Carousel – Combo Blocks plugin for WordPress is vulnerable to Stored Cross-Site Scripting via several parameters in all versions up to, and including, 2.2.80 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
CVE-2024-4710: The UberMenu plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's ubermenu-col, ubermenu_mobile_close_button, ubermenu_toggle, ubermenu-search shortcodes in all versions up to, and including, 3.8.2 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
CVE-2021-47255: In the Linux kernel, the following vulnerability has been resolved:  kvm: LAPIC: Restore guard to prevent illegal APIC register access  Per the SDM, "any access that touches bytes 4 through 15 of an APIC register may cause undefined behavior and must not be executed." Worse, such an access in kvm_lapic_reg_read can result in a leak of kernel stack contents. Prior to commit 01402cf81051 ("kvm: LAPIC: write down valid APIC registers"), such an access was explicitly disallowed. Restore the guard that was removed in that commit.
CVE-2021-47262: In the Linux kernel, the following vulnerability has been resolved:  KVM: x86: Ensure liveliness of nested VM-Enter fail tracepoint message  Use the __string() machinery provided by the tracing subystem to make a copy of the string literals consumed by the "nested VM-Enter failed" tracepoint.  A complete copy is necessary to ensure that the tracepoint can't outlive the data/memory it consumes and deference stale memory.  Because the tracepoint itself is defined by kvm, if kvm-intel and/or kvm-amd are built as modules, the memory holding the string literals defined by the vendor modules will be freed when the module is unloaded, whereas the tracepoint and its data in the ring buffer will live until kvm is unloaded (or "indefinitely" if kvm is built-in).  This bug has existed since the tracepoint was added, but was recently exposed by a new check in tracing to detect exactly this type of bug.    fmt: '%s%s   ' current_buffer: ' vmx_dirty_log_t-140127  [003] ....  kvm_nested_vmenter_failed: '   WARNING: CPU: 3 PID: 140134 at kernel/trace/trace.c:3759 trace_check_vprintf+0x3be/0x3e0   CPU: 3 PID: 140134 Comm: less Not tainted 5.13.0-rc1-ce2e73ce600a-req #184   Hardware name: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014   RIP: 0010:trace_check_vprintf+0x3be/0x3e0   Code: <0f> 0b 44 8b 4c 24 1c e9 a9 fe ff ff c6 44 02 ff 00 49 8b 97 b0 20   RSP: 0018:ffffa895cc37bcb0 EFLAGS: 00010282   RAX: 0000000000000000 RBX: ffffa895cc37bd08 RCX: 0000000000000027   RDX: 0000000000000027 RSI: 00000000ffffdfff RDI: ffff9766cfad74f8   RBP: ffffffffc0a041d4 R08: ffff9766cfad74f0 R09: ffffa895cc37bad8   R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffc0a041d4   R13: ffffffffc0f4dba8 R14: 0000000000000000 R15: ffff976409f2c000   FS:  00007f92fa200740(0000) GS:ffff9766cfac0000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 0000559bd11b0000 CR3: 000000019fbaa002 CR4: 00000000001726e0   Call Trace:    trace_event_printf+0x5e/0x80    trace_raw_output_kvm_nested_vmenter_failed+0x3a/0x60 [kvm]    print_trace_line+0x1dd/0x4e0    s_show+0x45/0x150    seq_read_iter+0x2d5/0x4c0    seq_read+0x106/0x150    vfs_read+0x98/0x180    ksys_read+0x5f/0xe0    do_syscall_64+0x40/0xb0    entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2021-47265: In the Linux kernel, the following vulnerability has been resolved:  RDMA: Verify port when creating flow rule  Validate port value provided by the user and with that remove no longer needed validation by the driver.  The missing check in the mlx5_ib driver could cause to the below oops.  Call trace:   _create_flow_rule+0x2d4/0xf28 [mlx5_ib]   mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]   ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]   ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]   ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]   ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]   do_vfs_ioctl+0xd0/0xaf0   ksys_ioctl+0x84/0xb4   __arm64_sys_ioctl+0x28/0xc4   el0_svc_common.constprop.3+0xa4/0x254   el0_svc_handler+0x84/0xa0   el0_svc+0x10/0x26c  Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)
CVE-2021-47272: In the Linux kernel, the following vulnerability has been resolved:  usb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL  There exists a possible scenario in which dwc3_gadget_init() can fail: during during host -> peripheral mode switch in dwc3_set_mode(), and a pending gadget driver fails to bind.  Then, if the DRD undergoes another mode switch from peripheral->host the resulting dwc3_gadget_exit() will attempt to reference an invalid and dangling dwc->gadget pointer as well as call dma_free_coherent() on unmapped DMA pointers.  The exact scenario can be reproduced as follows:  - Start DWC3 in peripheral mode  - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs)  - Run FunctionFS userspace application (open EPs, write descriptors, etc)  - Bind gadget driver to DWC3's UDC  - Switch DWC3 to host mode    => dwc3_gadget_exit() is called. usb_del_gadget() will put the  ConfigFS driver instance on the gadget_driver_pending_list  - Stop FunctionFS application (closes the ep files)  - Switch DWC3 to peripheral mode    => dwc3_gadget_init() fails as usb_add_gadget() calls  check_pending_gadget_drivers() and attempts to rebind the UDC  to the ConfigFS gadget but fails with -19 (-ENODEV) because the  FFS instance is not in FFS_ACTIVE state (userspace has not  re-opened and written the descriptors yet, i.e. desc_ready!=0).  - Switch DWC3 back to host mode    => dwc3_gadget_exit() is called again, but this time dwc->gadget  is invalid.  Although it can be argued that userspace should take responsibility for ensuring that the FunctionFS application be ready prior to allowing the composite driver bind to the UDC, failure to do so should not result in a panic from the kernel driver.  Fix this by setting dwc->gadget to NULL in the failure path of dwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out unless the gadget pointer is valid.
CVE-2021-47325: In the Linux kernel, the following vulnerability has been resolved:  iommu/arm-smmu: Fix arm_smmu_device refcount leak in address translation  The reference counting issue happens in several exception handling paths of arm_smmu_iova_to_phys_hard(). When those error scenarios occur, the function forgets to decrease the refcount of "smmu" increased by arm_smmu_rpm_get(), causing a refcount leak.  Fix this issue by jumping to "out" label when those error scenarios occur.
CVE-2021-47376: In the Linux kernel, the following vulnerability has been resolved:  bpf: Add oversize check before call kvcalloc()  Commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls") add the oversize check. When the allocation is larger than what kmalloc() supports, the following warning triggered:  WARNING: CPU: 0 PID: 8408 at mm/util.c:597 kvmalloc_node+0x108/0x110 mm/util.c:597 Modules linked in: CPU: 0 PID: 8408 Comm: syz-executor221 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:kvmalloc_node+0x108/0x110 mm/util.c:597 Call Trace:  kvmalloc include/linux/mm.h:806 [inline]  kvmalloc_array include/linux/mm.h:824 [inline]  kvcalloc include/linux/mm.h:829 [inline]  check_btf_line kernel/bpf/verifier.c:9925 [inline]  check_btf_info kernel/bpf/verifier.c:10049 [inline]  bpf_check+0xd634/0x150d0 kernel/bpf/verifier.c:13759  bpf_prog_load kernel/bpf/syscall.c:2301 [inline]  __sys_bpf+0x11181/0x126e0 kernel/bpf/syscall.c:4587  __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]  __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]  __x64_sys_bpf+0x78/0x90 kernel/bpf/syscall.c:4689  do_syscall_x64 arch/x86/entry/common.c:50 [inline]  do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80  entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2021-47395: In the Linux kernel, the following vulnerability has been resolved:  mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap  Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap routine in order to fix the following warning reported by syzbot:  WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline] WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 Modules linked in: CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline] RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244 RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216 RAX: 0000000000000618 RBX: ffff88804ef76500 RCX: ffffc900143a5000 RDX: 0000000000040000 RSI: ffffffff888f478e RDI: 0000000000000003 RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000100 R10: ffffffff888f46f9 R11: 0000000000000000 R12: 00000000fffffff8 R13: ffff88804ef7653c R14: 0000000000000001 R15: 0000000000000004 FS:  00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2de23000 CR3: 000000006a671000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace:  ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740  netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089  __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165  __bpf_tx_skb net/core/filter.c:2114 [inline]  __bpf_redirect_no_mac net/core/filter.c:2139 [inline]  __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162  ____bpf_clone_redirect net/core/filter.c:2429 [inline]  bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401  bpf_prog_eeb6f53a69e5c6a2+0x59/0x234  bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline]  __bpf_prog_run include/linux/filter.h:624 [inline]  bpf_prog_run include/linux/filter.h:631 [inline]  bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119  bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663  bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline]  __sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605  __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]  __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]  __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689  do_syscall_x64 arch/x86/entry/common.c:50 [inline]  do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80  entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9
CVE-2021-47400: In the Linux kernel, the following vulnerability has been resolved:  net: hns3: do not allow call hns3_nic_net_open repeatedly  hns3_nic_net_open() is not allowed to called repeatly, but there is no checking for this. When doing device reset and setup tc concurrently, there is a small oppotunity to call hns3_nic_net_open repeatedly, and cause kernel bug by calling napi_enable twice.  The calltrace information is like below: [ 3078.222780] ------------[ cut here ]------------ [ 3078.230255] kernel BUG at net/core/dev.c:6991! [ 3078.236224] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 3078.243431] Modules linked in: hns3 hclgevf hclge hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [ 3078.258880] CPU: 0 PID: 295 Comm: kworker/u8:5 Tainted: G           O      5.14.0-rc4+ #1 [ 3078.269102] Hardware name:  , BIOS KpxxxFPGA 1P B600 V181 08/12/2021 [ 3078.276801] Workqueue: hclge hclge_service_task [hclge] [ 3078.288774] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 3078.296168] pc : napi_enable+0x80/0x84 tc qdisc sho[w  3d0e7v8 .e3t0h218 79] lr : hns3_nic_net_open+0x138/0x510 [hns3]  [ 3078.314771] sp : ffff8000108abb20 [ 3078.319099] x29: ffff8000108abb20 x28: 0000000000000000 x27: ffff0820a8490300 [ 3078.329121] x26: 0000000000000001 x25: ffff08209cfc6200 x24: 0000000000000000 [ 3078.339044] x23: ffff0820a8490300 x22: ffff08209cd76000 x21: ffff0820abfe3880 [ 3078.349018] x20: 0000000000000000 x19: ffff08209cd76900 x18: 0000000000000000 [ 3078.358620] x17: 0000000000000000 x16: ffffc816e1727a50 x15: 0000ffff8f4ff930 [ 3078.368895] x14: 0000000000000000 x13: 0000000000000000 x12: 0000259e9dbeb6b4 [ 3078.377987] x11: 0096a8f7e764eb40 x10: 634615ad28d3eab5 x9 : ffffc816ad8885b8 [ 3078.387091] x8 : ffff08209cfc6fb8 x7 : ffff0820ac0da058 x6 : ffff0820a8490344 [ 3078.396356] x5 : 0000000000000140 x4 : 0000000000000003 x3 : ffff08209cd76938 [ 3078.405365] x2 : 0000000000000000 x1 : 0000000000000010 x0 : ffff0820abfe38a0 [ 3078.414657] Call trace: [ 3078.418517]  napi_enable+0x80/0x84 [ 3078.424626]  hns3_reset_notify_up_enet+0x78/0xd0 [hns3] [ 3078.433469]  hns3_reset_notify+0x64/0x80 [hns3] [ 3078.441430]  hclge_notify_client+0x68/0xb0 [hclge] [ 3078.450511]  hclge_reset_rebuild+0x524/0x884 [hclge] [ 3078.458879]  hclge_reset_service_task+0x3c4/0x680 [hclge] [ 3078.467470]  hclge_service_task+0xb0/0xb54 [hclge] [ 3078.475675]  process_one_work+0x1dc/0x48c [ 3078.481888]  worker_thread+0x15c/0x464 [ 3078.487104]  kthread+0x160/0x170 [ 3078.492479]  ret_from_fork+0x10/0x18 [ 3078.498785] Code: c8027c81 35ffffa2 d50323bf d65f03c0 (d4210000) [ 3078.506889] ---[ end trace 8ebe0340a1b0fb44 ]---  Once hns3_nic_net_open() is excute success, the flag HNS3_NIC_STATE_DOWN will be cleared. So add checking for this flag, directly return when HNS3_NIC_STATE_DOWN is no set.
CVE-2021-47412: In the Linux kernel, the following vulnerability has been resolved:  block: don't call rq_qos_ops->done_bio if the bio isn't tracked  rq_qos framework is only applied on request based driver, so:  1) rq_qos_done_bio() needn't to be called for bio based driver  2) rq_qos_done_bio() needn't to be called for bio which isn't tracked, such as bios ended from error handling code.  Especially in bio_endio():  1) request queue is referred via bio->bi_bdev->bd_disk->queue, which may be gone since request queue refcount may not be held in above two cases  2) q->rq_qos may be freed in blk_cleanup_queue() when calling into __rq_qos_done_bio()  Fix the potential kernel panic by not calling rq_qos_ops->done_bio if the bio isn't tracked. This way is safe because both ioc_rqos_done_bio() and blkcg_iolatency_done_bio() are nop if the bio isn't tracked.