xamxte/cve-to-cwe huggingface dataset:
CVE-2025-39886: In the Linux kernel, the following vulnerability has been resolved:  bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()  Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example:  ...  [10.011566]  do_raw_spin_lock.cold  [10.011570]  try_to_wake_up             (5) double-acquiring the same  [10.011575]  kick_pool                      rq_lock, causing a hardlockup  [10.011579]  __queue_work  [10.011582]  queue_work_on  [10.011585]  kernfs_notify  [10.011589]  cgroup_file_notify  [10.011593]  try_charge_memcg           (4) memcg accounting raises an  [10.011597]  obj_cgroup_charge_pages        MEMCG_MAX event  [10.011599]  obj_cgroup_charge_account  [10.011600]  __memcg_slab_post_alloc_hook  [10.011603]  __kmalloc_node_noprof ...  [10.011611]  bpf_map_kmalloc_node  [10.011612]  __bpf_async_init  [10.011615]  bpf_timer_init             (3) BPF calls bpf_timer_init()  [10.011617]  bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable  [10.011619]  bpf__sched_ext_ops_runnable  [10.011620]  enqueue_task_scx           (2) BPF runs with rq_lock held  [10.011622]  enqueue_task  [10.011626]  ttwu_do_activate  [10.011629]  sched_ttwu_pending         (1) grabs rq_lock ...  The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event.  We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc.  As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there.  Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/  v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ v1 approach: https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/
CVE-2025-8282: The SureForms  WordPress plugin before 1.9.1 does not sanitise and escape some parameters when outputing them in the page, which could allow admin and above users to perform Cross-Site Scripting attacks.
CVE-2025-57319: fast-redact is a package that provides do very fast object redaction. A Prototype Pollution vulnerability in the nestedRestore function of fast-redact version 3.5.0 and before allows attackers to inject properties on Object.prototype via supplying a crafted payload, causing denial of service (DoS) as the minimum consequence. NOTE: the Supplier disputes this because the reporter only demonstrated access to properties by an internal utility function, and there is no means for achieving prototype pollution via the public API.
CVE-2025-21056: Improper input validation in Retail Mode prior to version 5.59.4 allows self attackers to execute privileged commands on their own devices.
CVE-2024-5200: The Postie WordPress plugin before 1.9.71 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup).
CVE-2025-9512: The Schema & Structured Data for WP & AMP WordPress plugin before 1.50 does not properly handles HTML tag attribute modifications, making it possible for unauthenticated attackers to conduct Stored XSS attacks via post comments.
CVE-2025-39891: In the Linux kernel, the following vulnerability has been resolved:  wifi: mwifiex: Initialize the chan_stats array to zero  The adapter->chan_stats[] array is initialized in mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out memory.  The array is filled in mwifiex_update_chan_statistics() and then the user can query the data in mwifiex_cfg80211_dump_survey().  There are two potential issues here.  What if the user calls mwifiex_cfg80211_dump_survey() before the data has been filled in. Also the mwifiex_update_chan_statistics() function doesn't necessarily initialize the whole array.  Since the array was not initialized at the start that could result in an information leak.  Also this array is pretty small.  It's a maximum of 900 bytes so it's more appropriate to use kcalloc() instead vmalloc().
CVE-2025-39913: In the Linux kernel, the following vulnerability has been resolved:  tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.  syzbot reported the splat below. [0]  The repro does the following:    1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)   2. Attach the prog to a SOCKMAP   3. Add a socket to the SOCKMAP   4. Activate fault injection   5. Send data less than cork_bytes  At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes().  Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN.  If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc().  Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork.  The "*copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "*copied" to 0.  [0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS:  00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace:  <IRQ>  __sk_destruct+0x86/0x660 net/core/sock.c:2339  rcu_do_batch kernel/rcu/tree.c:2605 [inline]  rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861  handle_softirqs+0x286/0x870 kernel/softirq.c:579  __do_softirq kernel/softirq.c:613 [inline]  invoke_softirq kernel/softirq.c:453 [inline]  __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680  irq_exit_rcu+0x9/0x30 kernel/softirq.c:696  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052  </IRQ>
CVE-2025-39921: In the Linux kernel, the following vulnerability has been resolved:  spi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op callback  In commit 13529647743d9 ("spi: microchip-core-qspi: Support per spi-mem operation frequency switches") the logic for checking the viability of op->max_freq in mchp_coreqspi_setup_clock() was copied into mchp_coreqspi_supports_op(). Unfortunately, op->max_freq is not valid when this function is called during probe but is instead zero. Accordingly, baud_rate_val is calculated to be INT_MAX due to division by zero, causing probe of the attached memory device to fail.  Seemingly spi-microchip-core-qspi was the only driver that had such a modification made to its supports_op callback when the per_op_freq capability was added, so just remove it to restore prior functionality.
CVE-2025-39926: In the Linux kernel, the following vulnerability has been resolved:  genetlink: fix genl_bind() invoking bind() after -EPERM  Per family bind/unbind callbacks were introduced to allow families to track multicast group consumer presence, e.g. to start or stop producing events depending on listeners.  However, in genl_bind() the bind() callback was invoked even if capability checks failed and ret was set to -EPERM. This means that callbacks could run on behalf of unauthorized callers while the syscall still returned failure to user space.  Fix this by only invoking bind() after "if (ret) break;" check i.e. after permission checks have succeeded.
CVE-2022-50426: In the Linux kernel, the following vulnerability has been resolved:  remoteproc: imx_dsp_rproc: Add mutex protection for workqueue  The workqueue may execute late even after remoteproc is stopped or stopping, some resources (rpmsg device and endpoint) have been released in rproc_stop_subdevices(), then rproc_vq_interrupt() accessing these resources will cause kennel dump.  Call trace:  virtqueue_add_split+0x1ac/0x560  virtqueue_add_inbuf+0x4c/0x60  rpmsg_recv_done+0x15c/0x294  vring_interrupt+0x6c/0xa4  rproc_vq_interrupt+0x30/0x50  imx_dsp_rproc_vq_work+0x24/0x40 [imx_dsp_rproc]  process_one_work+0x1d0/0x354  worker_thread+0x13c/0x470  kthread+0x154/0x160  ret_from_fork+0x10/0x20  Add mutex protection in imx_dsp_rproc_vq_work(), if the state is not running, then just skip calling rproc_vq_interrupt().  Also the flush workqueue operation can't be added in rproc stop for the same reason. The call sequence is  rproc_shutdown -> rproc_stop    ->rproc_stop_subdevices    ->rproc->ops->stop()      ->imx_dsp_rproc_stop        ->flush_work          -> rproc_vq_interrupt  The resource needed by rproc_vq_interrupt has been released in rproc_stop_subdevices, so flush_work is not safe to be called in imx_dsp_rproc_stop.
CVE-2022-50429: In the Linux kernel, the following vulnerability has been resolved:  memory: of: Fix refcount leak bug in of_lpddr3_get_ddr_timings()  We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount.
CVE-2022-50443: In the Linux kernel, the following vulnerability has been resolved:  drm/rockchip: lvds: fix PM usage counter unbalance in poweron  pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. We fix it by replacing it with the newest pm_runtime_resume_and_get to keep usage counter balanced.
CVE-2022-50444: In the Linux kernel, the following vulnerability has been resolved:  clk: tegra20: Fix refcount leak in tegra20_clock_init  of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2022-50457: In the Linux kernel, the following vulnerability has been resolved:  mtd: core: Fix refcount error in del_mtd_device()  del_mtd_device() will call of_node_put() to mtd_get_of_node(mtd), which is mtd->dev.of_node. However, memset(&mtd->dev, 0) is called before of_node_put(). As the result, of_node_put() won't do anything in del_mtd_device(), and causes the refcount leak.  del_mtd_device()     memset(&mtd->dev, 0, sizeof(mtd->dev) # clear mtd->dev     of_node_put()         mtd_get_of_node(mtd) # mtd->dev is cleared, can't locate of_node                              # of_node_put(NULL) won't do anything  Fix the error by caching the pointer of the device_node.  OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/spi-sram@0 CPU: 3 PID: 275 Comm: python3 Tainted: G N 6.1.0-rc3+ #54     0d8a1edddf51f172ff5226989a7565c6313b08e2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK>     dump_stack_lvl+0x67/0x83     kobject_get+0x155/0x160     of_node_get+0x1f/0x30     of_fwnode_get+0x43/0x70     fwnode_handle_get+0x54/0x80     fwnode_get_nth_parent+0xc9/0xe0     fwnode_full_name_string+0x3f/0xa0     device_node_string+0x30f/0x750     pointer+0x598/0x7a0     vsnprintf+0x62d/0x9b0     ...     cfs_overlay_release+0x30/0x90     config_item_release+0xbe/0x1a0     config_item_put+0x5e/0x80     configfs_rmdir+0x3bd/0x540     vfs_rmdir+0x18c/0x320     do_rmdir+0x198/0x330     __x64_sys_rmdir+0x2c/0x40     do_syscall_64+0x37/0x90     entry_SYSCALL_64_after_hwframe+0x63/0xcd  [<miquel.raynal@bootlin.com>: Light reword of the commit log]
CVE-2022-50458: In the Linux kernel, the following vulnerability has been resolved:  clk: tegra: Fix refcount leak in tegra210_clock_init  of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak.
CVE-2022-50461: In the Linux kernel, the following vulnerability has been resolved:  net: ethernet: ti: am65-cpsw: Fix PM runtime leakage in am65_cpsw_nuss_ndo_slave_open()  Ensure pm_runtime_put() is issued in error path.
CVE-2022-50464: In the Linux kernel, the following vulnerability has been resolved:  mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()  As comment of pci_get_device() says, it returns a pci_device with its refcount increased. We need to call pci_dev_put() to decrease the refcount. Save the return value of pci_get_device() and call pci_dev_put() to decrease the refcount.
CVE-2022-50468: In the Linux kernel, the following vulnerability has been resolved:  platform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init()  The following WARNING message was given when rmmod cros_usbpd_notify:   Unexpected driver unregister!  WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0  Modules linked in: cros_usbpd_notify(-)  CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24  ...  Call Trace:   <TASK>   cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify]   __x64_sys_delete_module+0x3c7/0x570   ? __ia32_sys_delete_module+0x570/0x570   ? lock_is_held_type+0xe3/0x140   ? syscall_enter_from_user_mode+0x17/0x50   ? rcu_read_lock_sched_held+0xa0/0xd0   ? syscall_enter_from_user_mode+0x1c/0x50   do_syscall_64+0x37/0x90   entry_SYSCALL_64_after_hwframe+0x63/0xcd  RIP: 0033:0x7f333fe9b1b7  The reason is that the cros_usbpd_notify_init() does not check the return value of platform_driver_register(), and the cros_usbpd_notify can install successfully even if platform_driver_register() failed.  Fix by checking the return value of platform_driver_register() and unregister cros_usbpd_notify_plat_driver when it failed.
CVE-2023-53456: In the Linux kernel, the following vulnerability has been resolved:  scsi: qla4xxx: Add length check when parsing nlattrs  There are three places that qla4xxx parses nlattrs:   - qla4xxx_set_chap_entry()   - qla4xxx_iface_set_param()   - qla4xxx_sysfs_ddb_set_param()  and each of them directly converts the nlattr to specific pointer of structure without length checking. This could be dangerous as those attributes are not validated and a malformed nlattr (e.g., length 0) could result in an OOB read that leaks heap dirty data.  Add the nla_len check before accessing the nlattr data and return EINVAL if the length check fails.
CVE-2023-53482: In the Linux kernel, the following vulnerability has been resolved:  iommu: Fix error unwind in iommu_group_alloc()  If either iommu_group_grate_file() fails then the iommu_group is leaked.  Destroy it on these error paths.  Found by kselftest/iommu/iommufd_fail_nth
CVE-2023-53488: In the Linux kernel, the following vulnerability has been resolved:  IB/hfi1: Fix possible panic during hotplug remove  During hotplug remove it is possible that the update counters work might be pending, and may run after memory has been freed. Cancel the update counters work before freeing memory.
CVE-2023-53493: In the Linux kernel, the following vulnerability has been resolved:  accel/qaic: tighten bounds checking in decode_message()  Copy the bounds checking from encode_message() to decode_message().  This patch addresses the following concerns.  Ensure that there is enough space for at least one header so that we don't have a negative size later.   if (msg_hdr_len < sizeof(*trans_hdr))  Ensure that we have enough space to read the next header from the msg->data.   if (msg_len > msg_hdr_len - sizeof(*trans_hdr))   return -EINVAL;  Check that the trans_hdr->len is not below the minimum size:   if (hdr_len < sizeof(*trans_hdr))  This minimum check ensures that we don't corrupt memory in decode_passthrough() when we do.   memcpy(out_trans->data, in_trans->data, len - sizeof(in_trans->hdr));  And finally, use size_add() to prevent an integer overflow:   if (size_add(msg_len, hdr_len) > msg_hdr_len)
CVE-2023-53501: In the Linux kernel, the following vulnerability has been resolved:  iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind  When unbinding pasid - a race condition exists vs outstanding page faults.  To prevent this, the pasid_state object contains a refcount.     * set to 1 on pasid bind     * incremented on each ppr notification start     * decremented on each ppr notification done     * decremented on pasid unbind  Since refcount_dec assumes that refcount will never reach 0:   the current implementation causes the following to be invoked on   pasid unbind:         REFCOUNT_WARN("decrement hit 0; leaking memory")  Fix this issue by changing refcount_dec to refcount_dec_and_test to explicitly handle refcount=1.
CVE-2023-53517: In the Linux kernel, the following vulnerability has been resolved:  tipc: do not update mtu if msg_max is too small in mtu negotiation  When doing link mtu negotiation, a malicious peer may send Activate msg with a very small mtu, e.g. 4 in Shuang's testing, without checking for the minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), then n->links[bearer_id].mtu is set to 4294967228, which is a overflow of '4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().  With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning:   tipc: Too large msg, purging xmit list 1 5 0 40 4!  tipc: Too large msg, purging xmit list 1 15 0 60 4!  And with tipc_link_entry.mtu 4294967228, a huge skb was allocated in named_distribute(), and when purging it in tipc_link_xmit(), a crash was even caused:    general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI   CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19   RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0   Call Trace:    <IRQ>    skb_release_data+0xf9/0x1d0    kfree_skb_reason+0x40/0x100    tipc_link_xmit+0x57a/0x740 [tipc]    tipc_node_xmit+0x16c/0x5c0 [tipc]    tipc_named_node_up+0x27f/0x2c0 [tipc]    tipc_node_write_unlock+0x149/0x170 [tipc]    tipc_rcv+0x608/0x740 [tipc]    tipc_udp_recv+0xdc/0x1f0 [tipc]    udp_queue_rcv_one_skb+0x33e/0x620    udp_unicast_rcv_skb.isra.72+0x75/0x90    __udp4_lib_rcv+0x56d/0xc20    ip_protocol_deliver_rcu+0x100/0x2d0  This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(), and not updating mtu if it is too small.
CVE-2023-53522: In the Linux kernel, the following vulnerability has been resolved:  cgroup,freezer: hold cpu_hotplug_lock before freezer_mutex  syzbot is reporting circular locking dependency between cpu_hotplug_lock and freezer_mutex, for commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic") replaced atomic_inc() in freezer_apply_state() with static_branch_inc() which holds cpu_hotplug_lock.  cpu_hotplug_lock => cgroup_threadgroup_rwsem => freezer_mutex    cgroup_file_write() {     cgroup_procs_write() {       __cgroup_procs_write() {         cgroup_procs_write_start() {           cgroup_attach_lock() {             cpus_read_lock() {               percpu_down_read(&cpu_hotplug_lock);             }             percpu_down_write(&cgroup_threadgroup_rwsem);           }         }         cgroup_attach_task() {           cgroup_migrate() {             cgroup_migrate_execute() {               freezer_attach() {                 mutex_lock(&freezer_mutex);                 (...snipped...)               }             }           }         }         (...snipped...)       }     }   }  freezer_mutex => cpu_hotplug_lock    cgroup_file_write() {     freezer_write() {       freezer_change_state() {         mutex_lock(&freezer_mutex);         freezer_apply_state() {           static_branch_inc(&freezer_active) {             static_key_slow_inc() {               cpus_read_lock();               static_key_slow_inc_cpuslocked();               cpus_read_unlock();             }           }         }         mutex_unlock(&freezer_mutex);       }     }   }  Swap locking order by moving cpus_read_lock() in freezer_apply_state() to before mutex_lock(&freezer_mutex) in freezer_change_state().
CVE-2023-53528: In the Linux kernel, the following vulnerability has been resolved:  RDMA/rxe: Fix unsafe drain work queue code  If create_qp does not fully succeed it is possible for qp cleanup code to attempt to drain the send or recv work queues before the queues have been created causing a seg fault. This patch checks to see if the queues exist before attempting to drain them.
CVE-2025-59685: Kazaar 1.25.12 allows a JWT with none in the alg field.
CVE-2025-9587: The CTL Behance Importer Lite WordPress plugin through 1.0 does not properly sanitise and escape a parameter before using it in a SQL statement via an AJAX action available to unauthenticated users, leading to a SQL injection.
CVE-2025-9697: The Ajax WooSearch WordPress plugin through 1.0.0 does not properly sanitise and escape a parameter before using it in a SQL statement via an AJAX action available to unauthenticated users, leading to a SQL injection
CVE-2025-10547: An uninitialized variable in the HTTP CGI request arguments processing component of Vigor Routers running DrayOS may allow an attacker the ability to perform RCE on the appliance through memory corruption.
CVE-2025-39932: In the Linux kernel, the following vulnerability has been resolved:  smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)  In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again.  I actually just hit the case using rxe:  WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [    T138]  smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687149] [    T138]  ? __kasan_check_write+0x14/0x30 [ 5305.687185] [    T138]  ? __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [    T138]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 5305.687356] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [    T138]  ? _raw_spin_unlock_irqrestore+0x11/0x60 [ 5305.687389] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [    T138]  ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [    T138]  smbd_post_send_credits+0x382/0x4b0 [cifs] [ 5305.687701] [    T138]  ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [    T138]  ? __pfx___schedule+0x10/0x10 [ 5305.687865] [    T138]  ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 5305.687875] [    T138]  ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [    T138]  process_one_work+0x629/0xf80 [ 5305.687908] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [    T138]  ? __kasan_check_write+0x14/0x30 [ 5305.687933] [    T138]  worker_thread+0x87f/0x1570 ...  It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggered by ib_drain_qp() and called: queue_work(info->workqueue, &info->post_send_credits_work);