xamxte/cve-to-cwe huggingface dataset:
CVE-2025-2563: The User Registration & Membership  WordPress plugin before 4.1.2 does not prevent users to set their account role when the Membership Addon is enabled, leading to a privilege escalation issue and allowing unauthenticated users to gain admin privileges
CVE-2025-30720: Vulnerability in the Oracle Configurator product of Oracle E-Business Suite (component: Orders).  Supported versions that are affected are 12.2.3-12.2.14. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Configurator.  Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Configurator, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Configurator accessible data as well as  unauthorized read access to a subset of Oracle Configurator accessible data. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).
CVE-2025-31363: Mattermost versions 10.4.x <= 10.4.2, 10.5.x <= 10.5.0, 9.11.x <= 9.11.9 fail to restrict domains the LLM can request to contact upstream which allows an authenticated user to exfiltrate data from an arbitrary server accessible to the victim via performing a prompt injection in the AI plugin's Jira tool.
CVE-2024-58096: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode  ath11k_hal_srng_* should be used with srng->lock to protect srng data.  For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock.  So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace:  ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]  ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]  ? idr_alloc_u32+0x97/0xd0  ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]  ath11k_dp_service_srng+0x289/0x5a0 [ath11k]  ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]  __napi_poll+0x30/0x1f0  net_rx_action+0x198/0x320  __do_softirq+0xdd/0x319  So add srng->lock for them to avoid such warnings.  Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx().  Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
CVE-2025-22057: In the Linux kernel, the following vulnerability has been resolved:  net: decrease cached dst counters in dst_release  Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts:    Unable to handle kernel paging request at virtual address ffff5aabf6b5c000   Call trace:    percpu_counter_add_batch+0x3c/0x160 (P)    dst_release+0xec/0x108    dst_cache_destroy+0x68/0xd8    dst_destroy+0x13c/0x168    dst_destroy_rcu+0x1c/0xb0    rcu_do_batch+0x18c/0x7d0    rcu_core+0x174/0x378    rcu_core_si+0x18/0x30  Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.
CVE-2025-22078: In the Linux kernel, the following vulnerability has been resolved:  staging: vchiq_arm: Fix possible NPR of keep-alive thread  In case vchiq_platform_conn_state_changed() is never called or fails before driver removal, ka_thread won't be a valid pointer to a task_struct. So do the necessary checks before calling kthread_stop to avoid a crash.
CVE-2025-22116: In the Linux kernel, the following vulnerability has been resolved:  idpf: check error for register_netdev() on init  Current init logic ignores the error code from register_netdev(), which will cause WARN_ON() on attempt to unregister it, if there was one, and there is no info for the user that the creation of the netdev failed.  WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10 ... [ 3707.563641]  unregister_netdev+0x1c/0x30 [ 3707.563656]  idpf_vport_dealloc+0x5cf/0xce0 [idpf] [ 3707.563684]  idpf_deinit_task+0xef/0x160 [idpf] [ 3707.563712]  idpf_vc_core_deinit+0x84/0x320 [idpf] [ 3707.563739]  idpf_remove+0xbf/0x780 [idpf] [ 3707.563769]  pci_device_remove+0xab/0x1e0 [ 3707.563786]  device_release_driver_internal+0x371/0x530 [ 3707.563803]  driver_detach+0xbf/0x180 [ 3707.563816]  bus_remove_driver+0x11b/0x2a0 [ 3707.563829]  pci_unregister_driver+0x2a/0x250  Introduce an error check and log the vport number and error code. On removal make sure to check VPORT_REG_NETDEV flag prior to calling unregister and free on the netdev.  Add local variables for idx, vport_config and netdev for readability.
CVE-2025-22117: In the Linux kernel, the following vulnerability has been resolved:  ice: fix using untrusted value of pkt_len in ice_vc_fdir_parse_raw()  Fix using the untrusted value of proto->raw.pkt_len in function ice_vc_fdir_parse_raw() by verifying if it does not exceed the VIRTCHNL_MAX_SIZE_RAW_PACKET value.
CVE-2025-22120: In the Linux kernel, the following vulnerability has been resolved:  ext4: goto right label 'out_mmap_sem' in ext4_setattr()  Otherwise, if ext4_inode_attach_jinode() fails, a hung task will happen because filemap_invalidate_unlock() isn't called to unlock mapping->invalidate_lock. Like this:  EXT4-fs error (device sda) in ext4_setattr:5557: Out of memory INFO: task fsstress:374 blocked for more than 122 seconds.       Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:fsstress state:D stack:0     pid:374   tgid:374   ppid:373                                   task_flags:0x440140 flags:0x00000000 Call Trace:  <TASK>  __schedule+0x2c9/0x7f0  schedule+0x27/0xa0  schedule_preempt_disabled+0x15/0x30  rwsem_down_read_slowpath+0x278/0x4c0  down_read+0x59/0xb0  page_cache_ra_unbounded+0x65/0x1b0  filemap_get_pages+0x124/0x3e0  filemap_read+0x114/0x3d0  vfs_read+0x297/0x360  ksys_read+0x6c/0xe0  do_syscall_64+0x4b/0x110  entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVE-2025-22122: In the Linux kernel, the following vulnerability has been resolved:  block: fix adding folio to bio  >4GB folio is possible on some ARCHs, such as aarch64, 16GB hugepage is supported, then 'offset' of folio can't be held in 'unsigned int', cause warning in bio_add_folio_nofail() and IO failure.  Fix it by adjusting 'page' & trimming 'offset' so that `->bi_offset` won't be overflow, and folio can be added to bio successfully.
CVE-2024-13925: The Klarna Checkout for WooCommerce WordPress plugin before 2.13.5 exposes an unauthenticated WooCommerce Ajax endpoint that allows an attacker to flood the log files with data at the maximum size allowed for a POST parameter per request. This can result in rapid consumption of disk space, potentially filling the entire disk.
CVE-2025-39930: In the Linux kernel, the following vulnerability has been resolved:  ASoC: simple-card-utils: Don't use __free(device_node) at graph_util_parse_dai()  commit 419d1918105e ("ASoC: simple-card-utils: use __free(device_node) for device node") uses __free(device_node) for dlc->of_node, but we need to keep it while driver is in use.  Don't use __free(device_node) in graph_util_parse_dai().
CVE-2025-2594: The User Registration & Membership WordPress plugin before 4.1.3 does not properly validate data in an AJAX action when the Membership Addon is enabled, allowing attackers to authenticate as any user, including administrators, by simply using the target account's user ID.
CVE-2025-2558: The-wound WordPress theme through 0.0.1 does not validate some parameters before using them to generate paths passed to include function/s, allowing unauthenticated users to perform LFI attacks and download arbitrary file from the server
CVE-2025-3471: The SureForms  WordPress plugin before 1.4.4 does not have proper authorisation check when updating its settings via the REST API, which could allow Contributor and above roles to perform such action
CVE-2025-23144: In the Linux kernel, the following vulnerability has been resolved:  backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()  Lockdep detects the following issue on led-backlight removal:   [  142.315935] ------------[ cut here ]------------   [  142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80   ...   [  142.500725] Call trace:   [  142.503176]  led_sysfs_enable+0x54/0x80 (P)   [  142.507370]  led_bl_remove+0x80/0xa8 [led_bl]   [  142.511742]  platform_remove+0x30/0x58   [  142.515501]  device_remove+0x54/0x90   ...  Indeed, led_sysfs_enable() has to be called with the led_access lock held.  Hold the lock when calling led_sysfs_disable().
CVE-2025-23155: In the Linux kernel, the following vulnerability has been resolved:  net: stmmac: Fix accessing freed irq affinity_hint  In stmmac_request_irq_multi_msi(), a pointer to the stack variable cpu_mask is passed to irq_set_affinity_hint(). This value is stored in irq_desc->affinity_hint, but once stmmac_request_irq_multi_msi() returns, the pointer becomes dangling.  The affinity_hint is exposed via procfs with S_IRUGO permissions, allowing any unprivileged process to read it. Accessing this stale pointer can lead to:  - a kernel oops or panic if the referenced memory has been released and   unmapped, or - leakage of kernel data into userspace if the memory is re-used for   other purposes.  All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) are affected.
CVE-2025-37747: In the Linux kernel, the following vulnerability has been resolved:  perf: Fix hang while freeing sigtrap event  Perf can hang while freeing a sigtrap event if a related deferred signal hadn't managed to be sent before the file got closed:  perf_event_overflow()    task_work_add(perf_pending_task)  fput()    task_work_add(____fput())  task_work_run()     ____fput()         perf_release()             perf_event_release_kernel()                 _free_event()                     perf_pending_task_sync()                         task_work_cancel() -> FAILED                         rcuwait_wait_event()  Once task_work_run() is running, the list of pending callbacks is removed from the task_struct and from this point on task_work_cancel() can't remove any pending and not yet started work items, hence the task_work_cancel() failure and the hang on rcuwait_wait_event().  Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg:  T1                                                      T2  fd = perf_event_open(pid => T2->pid);                  fd = perf_event_open(pid => T1->pid); close(fd)                                              close(fd)     <IRQ>                                                  <IRQ>     perf_event_overflow()                                  perf_event_overflow()        task_work_add(perf_pending_task)                        task_work_add(perf_pending_task)     </IRQ>                                                 </IRQ>     fput()                                                 fput()         task_work_add(____fput())                              task_work_add(____fput())      task_work_run()                                        task_work_run()         ____fput()                                             ____fput()             perf_release()                                         perf_release()                 perf_event_release_kernel()                            perf_event_release_kernel()                     _free_event()                                          _free_event()                         perf_pending_task_sync()                               perf_pending_task_sync()                             rcuwait_wait_event()                                   rcuwait_wait_event()  Therefore the only option left is to acquire the event reference count upon queueing the perf task work and release it from the task work, just like it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release") but without the leaks it fixed.  Some adjustments are necessary to make it work:  * A child event might dereference its parent upon freeing. Care must be   taken to release the parent last.  * Some places assuming the event doesn't have any reference held and   therefore can be freed right away must instead put the reference and   let the reference counting to its job.
CVE-2025-37751: In the Linux kernel, the following vulnerability has been resolved:  x86/cpu: Avoid running off the end of an AMD erratum table  The NULL array terminator at the end of erratum_1386_microcode was removed during the switch from x86_cpu_desc to x86_cpu_id. This causes readers to run off the end of the array.  Replace the NULL.
CVE-2025-37762: In the Linux kernel, the following vulnerability has been resolved:  drm/virtio: Fix missed dmabuf unpinning in error path of prepare_fb()  Correct error handling in prepare_fb() to fix leaking resources when error happens.
CVE-2025-37773: In the Linux kernel, the following vulnerability has been resolved:  virtiofs: add filesystem context source name check  In certain scenarios, for example, during fuzz testing, the source name may be NULL, which could lead to a kernel panic. Therefore, an extra check for the source name should be added.
CVE-2025-37790: In the Linux kernel, the following vulnerability has been resolved:  net: mctp: Set SOCK_RCU_FREE  Bind lookup runs under RCU, so ensure that a socket doesn't go away in the middle of a lookup.
CVE-2025-37791: In the Linux kernel, the following vulnerability has been resolved:  ethtool: cmis_cdb: use correct rpl size in ethtool_cmis_module_poll()  rpl is passed as a pointer to ethtool_cmis_module_poll(), so the correct size of rpl is sizeof(*rpl) which should be just 1 byte.  Using the pointer size instead can cause stack corruption:  Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ethtool_cmis_wait_for_cond+0xf4/0x100 CPU: 72 UID: 0 PID: 4440 Comm: kworker/72:2 Kdump: loaded Tainted: G           OE      6.11.0 #24 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. PowerEdge R760/04GWWM, BIOS 1.6.6 09/20/2023 Workqueue: events module_flash_fw_work Call Trace:  <TASK>  panic+0x339/0x360  ? ethtool_cmis_wait_for_cond+0xf4/0x100  ? __pfx_status_success+0x10/0x10  ? __pfx_status_fail+0x10/0x10  __stack_chk_fail+0x10/0x10  ethtool_cmis_wait_for_cond+0xf4/0x100  ethtool_cmis_cdb_execute_cmd+0x1fc/0x330  ? __pfx_status_fail+0x10/0x10  cmis_cdb_module_features_get+0x6d/0xd0  ethtool_cmis_cdb_init+0x8a/0xd0  ethtool_cmis_fw_update+0x46/0x1d0  module_flash_fw_work+0x17/0xa0  process_one_work+0x179/0x390  worker_thread+0x239/0x340  ? __pfx_worker_thread+0x10/0x10  kthread+0xcc/0x100  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2d/0x50  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30  </TASK>
CVE-2022-49762: In the Linux kernel, the following vulnerability has been resolved:  ntfs: check overflow when iterating ATTR_RECORDs  Kernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find().  Because the ATTR_RECORDs are next to each other, kernel can get the next ATTR_RECORD from end address of current ATTR_RECORD, through current ATTR_RECORD length field.  The problem is that during iteration, when kernel calculates the end address of current ATTR_RECORD, kernel may trigger an integer overflow bug in executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`.  This may wrap, leading to a forever iteration on 32bit systems.  This patch solves it by adding some checks on calculating end address of current ATTR_RECORD during iteration.
CVE-2022-49764: In the Linux kernel, the following vulnerability has been resolved:  bpf: Prevent bpf program recursion for raw tracepoint probes  We got report from sysbot [1] about warnings that were caused by bpf program attached to contention_begin raw tracepoint triggering the same tracepoint by using bpf_trace_printk helper that takes trace_printk_lock lock.   Call Trace:   <TASK>   ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90   bpf_trace_printk+0x2b/0xe0   bpf_prog_a9aec6167c091eef_prog+0x1f/0x24   bpf_trace_run2+0x26/0x90   native_queued_spin_lock_slowpath+0x1c6/0x2b0   _raw_spin_lock_irqsave+0x44/0x50   bpf_trace_printk+0x3f/0xe0   bpf_prog_a9aec6167c091eef_prog+0x1f/0x24   bpf_trace_run2+0x26/0x90   native_queued_spin_lock_slowpath+0x1c6/0x2b0   _raw_spin_lock_irqsave+0x44/0x50   bpf_trace_printk+0x3f/0xe0   bpf_prog_a9aec6167c091eef_prog+0x1f/0x24   bpf_trace_run2+0x26/0x90   native_queued_spin_lock_slowpath+0x1c6/0x2b0   _raw_spin_lock_irqsave+0x44/0x50   bpf_trace_printk+0x3f/0xe0   bpf_prog_a9aec6167c091eef_prog+0x1f/0x24   bpf_trace_run2+0x26/0x90   native_queued_spin_lock_slowpath+0x1c6/0x2b0   _raw_spin_lock_irqsave+0x44/0x50   __unfreeze_partials+0x5b/0x160   ...  The can be reproduced by attaching bpf program as raw tracepoint on contention_begin tracepoint. The bpf prog calls bpf_trace_printk helper. Then by running perf bench the spin lock code is forced to take slow path and call contention_begin tracepoint.  Fixing this by skipping execution of the bpf program if it's already running, Using bpf prog 'active' field, which is being currently used by trampoline programs for the same reason.  Moving bpf_prog_inc_misses_counter to syscall.c because trampoline.c is compiled in just for CONFIG_BPF_JIT option.  [1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t
CVE-2022-49769: In the Linux kernel, the following vulnerability has been resolved:  gfs2: Check sb_bsize_shift after reading superblock  Fuzzers like to scribble over sb_bsize_shift but in reality it's very unlikely that this field would be corrupted on its own. Nevertheless it should be checked to avoid the possibility of messy mount errors due to bad calculations. It's always a fixed value based on the block size so we can just check that it's the expected value.  Tested with:      mkfs.gfs2 -O -p lock_nolock /dev/vdb     for i in 0 -1 64 65 32 33; do         gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb         mount /dev/vdb /mnt/test && umount /mnt/test     done  Before this patch we get a withdraw after  [   76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block [   76.413681]   bh = 19 (type: exp=5, found=4) [   76.413681]   function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492  and with UBSAN configured we also get complaints like  [   76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19 [   76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int'  After the patch, these complaints don't appear, mount fails immediately and we get an explanation in dmesg.
CVE-2022-49776: In the Linux kernel, the following vulnerability has been resolved:  macvlan: enforce a consistent minimal mtu  macvlan should enforce a minimal mtu of 68, even at link creation.  This patch avoids the current behavior (which could lead to crashes in ipv6 stack if the link is brought up)  $ ip link add macvlan1 link eno1 mtu 8 type macvlan  # This should fail ! $ ip link sh dev macvlan1 5: macvlan1@eno1: <BROADCAST,MULTICAST> mtu 8 qdisc noop     state DOWN mode DEFAULT group default qlen 1000     link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff $ ip link set macvlan1 mtu 67 Error: mtu less than device minimum. $ ip link set macvlan1 mtu 68 $ ip link set macvlan1 mtu 8 Error: mtu less than device minimum.
CVE-2022-49783: In the Linux kernel, the following vulnerability has been resolved:  x86/fpu: Drop fpregs lock before inheriting FPU permissions  Mike Galbraith reported the following against an old fork of preempt-rt but the same issue also applies to the current preempt-rt tree.     BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46    in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd    preempt_count: 1, expected: 0    RCU nest depth: 0, expected: 0    Preemption disabled at:    fpu_clone    CPU: 6 PID: 1 Comm: systemd Tainted: G            E       (unreleased)    Call Trace:     <TASK>     dump_stack_lvl     ? fpu_clone     __might_resched     rt_spin_lock     fpu_clone     ? copy_thread     ? copy_process     ? shmem_alloc_inode     ? kmem_cache_alloc     ? kernel_clone     ? __do_sys_clone     ? do_syscall_64     ? __x64_sys_rt_sigprocmask     ? syscall_exit_to_user_mode     ? do_syscall_64     ? syscall_exit_to_user_mode     ? do_syscall_64     ? syscall_exit_to_user_mode     ? do_syscall_64     ? exc_page_fault     ? entry_SYSCALL_64_after_hwframe     </TASK>  Mike says:    The splat comes from fpu_inherit_perms() being called under fpregs_lock(),   and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic()   returning true despite static key __fpu_state_size_dynamic having never   been enabled.  Mike's assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables preemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This problem exists since commit    9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features").  Even though the original bug report should not have enabled the paths at all, the bug still exists.  fpregs_lock is necessary when editing the FPU registers or a task's FP state but it is not necessary for fpu_inherit_perms(). The only write of any FP state in fpu_inherit_perms() is for the new child which is not running yet and cannot context switch or be borrowed by a kernel thread yet. Hence, fpregs_lock is not protecting anything in the new child until clone() completes and can be dropped earlier. The siglock still needs to be acquired by fpu_inherit_perms() as the read of the parent's permissions has to be serialised.    [ bp: Cleanup splat. ]
CVE-2022-49785: In the Linux kernel, the following vulnerability has been resolved:  x86/sgx: Add overflow check in sgx_validate_offset_length()  sgx_validate_offset_length() function verifies "offset" and "length" arguments provided by userspace, but was missing an overflow check on their addition. Add it.
CVE-2022-49808: In the Linux kernel, the following vulnerability has been resolved:  net: dsa: don't leak tagger-owned storage on switch driver unbind  In the initial commit dc452a471dba ("net: dsa: introduce tagger-owned storage for private and shared data"), we had a call to tag_ops->disconnect(dst) issued from dsa_tree_free(), which is called at tree teardown time.  There were problems with connecting to a switch tree as a whole, so this got reworked to connecting to individual switches within the tree. In this process, tag_ops->disconnect(ds) was made to be called only from switch.c (cross-chip notifiers emitted as a result of dynamic tag proto changes), but the normal driver teardown code path wasn't replaced with anything.  Solve this problem by adding a function that does the opposite of dsa_switch_setup_tag_protocol(), which is called from the equivalent spot in dsa_switch_teardown(). The positioning here also ensures that we won't have any use-after-free in tagging protocol (*rcv) ops, since the teardown sequence is as follows:  dsa_tree_teardown -> dsa_tree_teardown_master    -> dsa_master_teardown       -> unsets master->dsa_ptr, making no further packets match the          ETH_P_XDSA packet type handler -> dsa_tree_teardown_ports    -> dsa_port_teardown       -> dsa_slave_destroy          -> unregisters DSA net devices, there is even a synchronize_net()             in unregister_netdevice_many() -> dsa_tree_teardown_switches    -> dsa_switch_teardown       -> dsa_switch_teardown_tag_protocol          -> finally frees the tagger-owned storage