xamxte/cve-to-cwe huggingface dataset:
CVE-2026-23033: In the Linux kernel, the following vulnerability has been resolved:  dmaengine: omap-dma: fix dma_pool resource leak in error paths  The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths.  Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource.
CVE-2026-23034: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/userq: Fix fence reference leak on queue teardown v2  The user mode queue keeps a pointer to the most recent fence in userq->last_fence. This pointer holds an extra dma_fence reference.  When the queue is destroyed, we free the fence driver and its xarray, but we forgot to drop the last_fence reference.  Because of the missing dma_fence_put(), the last fence object can stay alive when the driver unloads. This leaves an allocated object in the amdgpu_userq_fence slab cache and triggers  This is visible during driver unload as:    BUG amdgpu_userq_fence: Objects remaining on __kmem_cache_shutdown()   kmem_cache_destroy amdgpu_userq_fence: Slab cache still has objects   Call Trace:     kmem_cache_destroy     amdgpu_userq_fence_slab_fini     amdgpu_exit     __do_sys_delete_module  Fix this by putting userq->last_fence and clearing the pointer during amdgpu_userq_fence_driver_free().  This makes sure the fence reference is released and the slab cache is empty when the module exits.  v2: Update to only release userq->last_fence with dma_fence_put()     (Christian)  (cherry picked from commit 8e051e38a8d45caf6a866d4ff842105b577953bb)
CVE-2026-23035: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv  mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails.  Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on a valid netdev.  On mlx5e_remove: Check validity of priv->profile, before attempting to cleanup any resources that might be not there.  This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure.  $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12  $ devlink dev reload pci/0000:00:03.0 ==> oops  BUG: kernel NULL pointer dereference, address: 0000000000000370 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100 RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286 RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0 RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10 R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0 R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400 FS:  00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0 Call Trace:  <TASK>  mlx5e_remove+0x57/0x110  device_release_driver_internal+0x19c/0x200  bus_remove_device+0xc6/0x130  device_del+0x160/0x3d0  ? devl_param_driverinit_value_get+0x2d/0x90  mlx5_detach_device+0x89/0xe0  mlx5_unload_one_devl_locked+0x3a/0x70  mlx5_devlink_reload_down+0xc8/0x220  devlink_reload+0x7d/0x260  devlink_nl_reload_doit+0x45b/0x5a0  genl_family_rcv_msg_doit+0xe8/0x140
CVE-2026-23037: In the Linux kernel, the following vulnerability has been resolved:  can: etas_es58x: allow partial RX URB allocation to succeed  When es58x_alloc_rx_urbs() fails to allocate the requested number of URBs but succeeds in allocating some, it returns an error code. This causes es58x_open() to return early, skipping the cleanup label 'free_urbs', which leads to the anchored URBs being leaked.  As pointed out by maintainer Vincent Mailhol, the driver is designed to handle partial URB allocation gracefully. Therefore, partial allocation should not be treated as a fatal error.  Modify es58x_alloc_rx_urbs() to return 0 if at least one URB has been allocated, restoring the intended behavior and preventing the leak in es58x_open().
CVE-2026-23038: In the Linux kernel, the following vulnerability has been resolved:  pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()  In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak.  Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.
CVE-2026-23039: In the Linux kernel, the following vulnerability has been resolved:  drm/gud: fix NULL fb and crtc dereferences on USB disconnect  On disconnect drm_atomic_helper_disable_all() is called which sets both the fb and crtc for a plane to NULL before invoking a commit.  This causes a kernel oops on every display disconnect.  Add guards for those dereferences.
CVE-2026-20977: Improper access control in Emergency Sharing prior to SMR Feb-2026 Release 1 allows local attackers to interrupt its functioning.
CVE-2026-20978: Improper authorization in KnoxGuardManager prior to SMR Feb-2026 Release 1 allows local attackers to bypass the persistence configuration of the application.
CVE-2026-20979: Improper privilege management in Settings prior to SMR Feb-2026 Release 1 allows local attackers to launch arbitrary activity with Settings privilege.
CVE-2026-20980: Improper input validation in PACM prior to SMR Feb-2026 Release 1 allows physical attacker to execute arbitrary commands.
CVE-2026-20981: Improper input validation in FacAtFunction prior to SMR Feb-2026 Release 1 allows privileged physical attacker to execute arbitrary command with system privilege.
CVE-2026-20983: Improper export of android application components in Samsung Dialer prior to SMR Feb-2026 Release 1 allows local attackers to launch arbitrary activity with Samsung Dialer privilege.
CVE-2026-20984: Improper handling of insufficient permission in Galaxy Wearable installed on non-Samsung Device prior to version 2.2.68 allows local attackers to access sensitive information.
CVE-2026-20985: Improper input validation in Samsung Members prior to version 5.6.00.11 allows remote attackers to connect arbitrary URL and launch arbitrary activity with Samsung Members privilege. User interaction is required for triggering this vulnerability.
CVE-2026-20987: Improper input validation in GalaxyDiagnostics prior to version 3.5.050 allows local privileged attackers to execute privileged commands.
CVE-2025-71192: In the Linux kernel, the following vulnerability has been resolved:  ALSA: ac97: fix a double free in snd_ac97_controller_register()  If ac97_add_adapter() fails, put_device() is the correct way to drop the device reference. kfree() is not required. Add kfree() if idr_alloc() fails and in ac97_adapter_release() to do the cleanup.  Found by code review.
CVE-2026-23040: In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211_hwsim: fix typo in frequency notification  The NAN notification is for 5745 MHz which corresponds to channel 149 and not 5475 which is not actually a valid channel. This could result in a NULL pointer dereference in cfg80211_next_nan_dw_notif.
CVE-2026-23041: In the Linux kernel, the following vulnerability has been resolved:  bnxt_en: Fix NULL pointer crash in bnxt_ptp_enable during error cleanup  When bnxt_init_one() fails during initialization (e.g., bnxt_init_int_mode returns -ENODEV), the error path calls bnxt_free_hwrm_resources() which destroys the DMA pool and sets bp->hwrm_dma_pool to NULL. Subsequently, bnxt_ptp_clear() is called, which invokes ptp_clock_unregister().  Since commit a60fc3294a37 ("ptp: rework ptp_clock_unregister() to disable events"), ptp_clock_unregister() now calls ptp_disable_all_events(), which in turn invokes the driver's .enable() callback (bnxt_ptp_enable()) to disable PTP events before completing the unregistration.  bnxt_ptp_enable() attempts to send HWRM commands via bnxt_ptp_cfg_pin() and bnxt_ptp_cfg_event(), both of which call hwrm_req_init(). This function tries to allocate from bp->hwrm_dma_pool, causing a NULL pointer dereference:    bnxt_en 0000:01:00.0 (unnamed net_device) (uninitialized): bnxt_init_int_mode err: ffffffed   KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]   Call Trace:    __hwrm_req_init (drivers/net/ethernet/broadcom/bnxt/bnxt_hwrm.c:72)    bnxt_ptp_enable (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:323 drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:517)    ptp_disable_all_events (drivers/ptp/ptp_chardev.c:66)    ptp_clock_unregister (drivers/ptp/ptp_clock.c:518)    bnxt_ptp_clear (drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c:1134)    bnxt_init_one (drivers/net/ethernet/broadcom/bnxt/bnxt.c:16889)  Lines are against commit f8f9c1f4d0c7 ("Linux 6.19-rc3")  Fix this by clearing and unregistering ptp (bnxt_ptp_clear()) before freeing HWRM resources.
CVE-2026-23042: In the Linux kernel, the following vulnerability has been resolved:  idpf: fix aux device unplugging when rdma is not supported by vport  If vport flags do not contain VIRTCHNL2_VPORT_ENABLE_RDMA, driver does not allocate vdev_info for this vport. This leads to kernel NULL pointer dereference in idpf_idc_vport_dev_down(), which references vdev_info for every vport regardless.  Check, if vdev_info was ever allocated before unplugging aux device.
CVE-2026-23043: In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix NULL pointer dereference in do_abort_log_replay()  Coverity reported a NULL pointer dereference issue (CID 1666756) in do_abort_log_replay(). When btrfs_alloc_path() fails in replay_one_buffer(), wc->subvol_path is NULL, but btrfs_abort_log_replay() calls do_abort_log_replay() which unconditionally dereferences wc->subvol_path when attempting to print debug information. Fix this by adding a NULL check before dereferencing wc->subvol_path in do_abort_log_replay().
CVE-2026-23044: In the Linux kernel, the following vulnerability has been resolved:  PM: hibernate: Fix crash when freeing invalid crypto compressor  When crypto_alloc_acomp() fails, it returns an ERR_PTR value, not NULL.  The cleanup code in save_compressed_image() and load_compressed_image() unconditionally calls crypto_free_acomp() without checking for ERR_PTR, which causes crypto_acomp_tfm() to dereference an invalid pointer and crash the kernel.  This can be triggered when the compression algorithm is unavailable (e.g., CONFIG_CRYPTO_LZO not enabled).  Fix by adding IS_ERR_OR_NULL() checks before calling crypto_free_acomp() and acomp_request_free(), similar to the existing kthread_stop() check.  [ rjw: Added 2 empty code lines ]
CVE-2026-23045: In the Linux kernel, the following vulnerability has been resolved:  net/ena: fix missing lock when update devlink params  Fix assert lock warning while calling devl_param_driverinit_value_set() in ena.  WARNING: net/devlink/core.c:261 at devl_assert_locked+0x62/0x90, CPU#0: kworker/0:0/9 CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.19.0-rc2+ #1 PREEMPT(lazy) Hardware name: Amazon EC2 m8i-flex.4xlarge/, BIOS 1.0 10/16/2017 Workqueue: events work_for_cpu_fn RIP: 0010:devl_assert_locked+0x62/0x90  Call Trace:  <TASK>  devl_param_driverinit_value_set+0x15/0x1c0  ena_devlink_alloc+0x18c/0x220 [ena]  ? __pfx_ena_devlink_alloc+0x10/0x10 [ena]  ? trace_hardirqs_on+0x18/0x140  ? lockdep_hardirqs_on+0x8c/0x130  ? __raw_spin_unlock_irqrestore+0x5d/0x80  ? __raw_spin_unlock_irqrestore+0x46/0x80  ? devm_ioremap_wc+0x9a/0xd0  ena_probe+0x4d2/0x1b20 [ena]  ? __lock_acquire+0x56a/0xbd0  ? __pfx_ena_probe+0x10/0x10 [ena]  ? local_clock+0x15/0x30  ? __lock_release.isra.0+0x1c9/0x340  ? mark_held_locks+0x40/0x70  ? lockdep_hardirqs_on_prepare.part.0+0x92/0x170  ? trace_hardirqs_on+0x18/0x140  ? lockdep_hardirqs_on+0x8c/0x130  ? __raw_spin_unlock_irqrestore+0x5d/0x80  ? __raw_spin_unlock_irqrestore+0x46/0x80  ? __pfx_ena_probe+0x10/0x10 [ena]  ......  </TASK>
CVE-2025-71193: In the Linux kernel, the following vulnerability has been resolved:  phy: qcom-qusb2: Fix NULL pointer dereference on early suspend  Enabling runtime PM before attaching the QPHY instance as driver data can lead to a NULL pointer dereference in runtime PM callbacks that expect valid driver data. There is a small window where the suspend callback may run after PM runtime enabling and before runtime forbid. This causes a sporadic crash during boot:  ``` Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a1 [...] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.7+ #116 PREEMPT Workqueue: pm pm_runtime_work pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : qusb2_phy_runtime_suspend+0x14/0x1e0 [phy_qcom_qusb2] lr : pm_generic_runtime_suspend+0x2c/0x44 [...] ```  Attach the QPHY instance as driver data before enabling runtime PM to prevent NULL pointer dereference in runtime PM callbacks.  Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a short window where an unnecessary runtime suspend can occur.  Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.
CVE-2025-71196: In the Linux kernel, the following vulnerability has been resolved:  phy: stm32-usphyc: Fix off by one in probe()  The "index" variable is used as an index into the usbphyc->phys[] array which has usbphyc->nphys elements.  So if it is equal to usbphyc->nphys then it is one element out of bounds.  The "index" comes from the device tree so it's data that we trust and it's unlikely to be wrong, however it's obviously still worth fixing the bug.  Change the > to >=.
CVE-2025-71197: In the Linux kernel, the following vulnerability has been resolved:  w1: therm: Fix off-by-one buffer overflow in alarms_store  The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'.  Fix this by parsing the 'buf' parameter directly using simple_strtoll() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code.
CVE-2025-71198: In the Linux kernel, the following vulnerability has been resolved:  iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detection  The st_lsm6dsx_acc_channels array of struct iio_chan_spec has a non-NULL event_spec field, indicating support for IIO events. However, event detection is not supported for all sensors, and if userspace tries to configure accelerometer wakeup events on a sensor device that does not support them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences a NULL pointer when trying to write to the wakeup register. Define an additional struct iio_chan_spec array whose members have a NULL event_spec field, and use this array instead of st_lsm6dsx_acc_channels for sensors without event detection capability.
CVE-2025-71199: In the Linux kernel, the following vulnerability has been resolved:  iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver  at91_adc_interrupt can call at91_adc_touch_data_handler function to start the work by schedule_work(&st->touch_st.workq).  If we remove the module which will call at91_adc_remove to make cleanup, it will free indio_dev through iio_device_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                      CPU1                                       | at91_adc_workq_handler at91_adc_remove                      | iio_device_unregister(indio_dev)     | //free indio_dev a bit later         |                                      | iio_push_to_buffers(indio_dev)                                      | //use indio_dev  Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91_adc_remove.
CVE-2026-23051: In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix drm panic null pointer when driver not support atomic  When driver not support atomic, fb using plane->fb rather than plane->state->fb.  (cherry picked from commit 2f2a72de673513247cd6fae14e53f6c40c5841ef)
CVE-2026-23056: In the Linux kernel, the following vulnerability has been resolved:  uacce: implement mremap in uacce_vm_ops to return -EPERM  The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users.  The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario:  An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma's vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q->qfr to be freed twice(qfr will be set to null here, so repeated release is ok).
CVE-2026-23057: In the Linux kernel, the following vulnerability has been resolved:  vsock/virtio: Coalesce only linear skb  vsock/virtio common tries to coalesce buffers in rx queue: if a linear skb (with a spare tail room) is followed by a small skb (length limited by GOOD_COPY_LEN = 128), an attempt is made to join them.  Since the introduction of MSG_ZEROCOPY support, assumption that a small skb will always be linear is incorrect. In the zerocopy case, data is lost and the linear skb is appended with uninitialized kernel memory.  Of all 3 supported virtio-based transports, only loopback-transport is affected. G2H virtio-transport rx queue operates on explicitly linear skbs; see virtio_vsock_alloc_linear_skb() in virtio_vsock_rx_fill(). H2G vhost-transport may allocate non-linear skbs, but only for sizes that are not considered for coalescence; see PAGE_ALLOC_COSTLY_ORDER in virtio_vsock_alloc_skb().  Ensure only linear skbs are coalesced. Note that skb_tailroom(last_skb) > 0 guarantees last_skb is linear.
CVE-2026-23058: In the Linux kernel, the following vulnerability has been resolved:  can: ems_usb: ems_usb_read_bulk_callback(): fix URB memory leak  Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak").  In ems_usb_open(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback ems_usb_read_bulk_callback(), the URBs are processed and resubmitted. In ems_usb_close() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted).  However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in ems_usb_close().  Fix the memory leak by anchoring the URB in the ems_usb_read_bulk_callback() to the dev->rx_submitted anchor.
CVE-2026-23059: In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Sanitize payload size to prevent member overflow  In qla27xx_copy_fpin_pkt() and qla27xx_copy_multiple_pkt(), the frame_size reported by firmware is used to calculate the copy length into item->iocb. However, the iocb member is defined as a fixed-size 64-byte array within struct purex_item.  If the reported frame_size exceeds 64 bytes, subsequent memcpy calls will overflow the iocb member boundary. While extra memory might be allocated, this cross-member write is unsafe and triggers warnings under CONFIG_FORTIFY_SOURCE.  Fix this by capping total_bytes to the size of the iocb member (64 bytes) before allocation and copying. This ensures all copies remain within the bounds of the destination structure member.
CVE-2026-23060: In the Linux kernel, the following vulnerability has been resolved:  crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec  authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, crypto_authenc_esn_decrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalk_map_and_copy(), leading to a kernel panic (DoS).  Add a minimum AAD length check to fail fast on invalid inputs.
CVE-2026-23061: In the Linux kernel, the following vulnerability has been resolved:  can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak  Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak").  In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), the URBs for USB-in transfers are allocated, added to the dev->rx_submitted anchor and submitted. In the complete callback kvaser_usb_read_bulk_callback(), the URBs are processed and resubmitted. In kvaser_usb_remove_interfaces() the URBs are freed by calling usb_kill_anchored_urbs(&dev->rx_submitted).  However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs().  Fix the memory leak by anchoring the URB in the kvaser_usb_read_bulk_callback() to the dev->rx_submitted anchor.
CVE-2026-23062: In the Linux kernel, the following vulnerability has been resolved:  platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro  The GET_INSTANCE_ID macro that caused a kernel panic when accessing sysfs attributes:  1. Off-by-one error: The loop condition used '<=' instead of '<',    causing access beyond array bounds. Since array indices are 0-based    and go from 0 to instances_count-1, the loop should use '<'.  2. Missing NULL check: The code dereferenced attr_name_kobj->name    without checking if attr_name_kobj was NULL, causing a null pointer    dereference in min_length_show() and other attribute show functions.  The panic occurred when fwupd tried to read BIOS configuration attributes:    Oops: general protection fault [#1] SMP KASAN NOPTI   KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]   RIP: 0010:min_length_show+0xcf/0x1d0 [hp_bioscfg]  Add a NULL check for attr_name_kobj before dereferencing and corrects the loop boundary to match the pattern used elsewhere in the driver.
CVE-2026-23063: In the Linux kernel, the following vulnerability has been resolved:  uacce: ensure safe queue release with state management  Directly calling `put_queue` carries risks since it cannot guarantee that resources of `uacce_queue` have been fully released beforehand. So adding a `stop_queue` operation for the UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to the final resource release ensures safety.  Queue states are defined as follows: - UACCE_Q_ZOMBIE: Initial state - UACCE_Q_INIT: After opening `uacce` - UACCE_Q_STARTED: After `start` is issued via `ioctl`  When executing `poweroff -f` in virt while accelerator are still working, `uacce_fops_release` and `uacce_remove` may execute concurrently. This can cause `uacce_put_queue` within `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add state checks to prevent accessing freed pointers.