xamxte/cve-to-cwe huggingface dataset:
CVE-2025-68353: In the Linux kernel, the following vulnerability has been resolved:  net: vxlan: prevent NULL deref in vxlan_xmit_one  Neither sock4 nor sock6 pointers are guaranteed to be non-NULL in vxlan_xmit_one, e.g. if the iface is brought down. This can lead to the following NULL dereference:    BUG: kernel NULL pointer dereference, address: 0000000000000010   Oops: Oops: 0000 [#1] SMP NOPTI   RIP: 0010:vxlan_xmit_one+0xbb3/0x1580   Call Trace:    vxlan_xmit+0x429/0x610    dev_hard_start_xmit+0x55/0xa0    __dev_queue_xmit+0x6d0/0x7f0    ip_finish_output2+0x24b/0x590    ip_output+0x63/0x110  Mentioned commits changed the code path in vxlan_xmit_one and as a side effect the sock4/6 pointer validity checks in vxlan(6)_get_route were lost. Fix this by adding back checks.  Since both commits being fixed were released in the same version (v6.7) and are strongly related, bundle the fixes in a single commit.
CVE-2025-68354: In the Linux kernel, the following vulnerability has been resolved:  regulator: core: Protect regulator_supply_alias_list with regulator_list_mutex  regulator_supply_alias_list was accessed without any locking in regulator_supply_alias(), regulator_register_supply_alias(), and regulator_unregister_supply_alias(). Concurrent registration, unregistration and lookups can race, leading to:  1 use-after-free if an alias entry is removed while being read, 2 duplicate entries when two threads register the same alias, 3 inconsistent alias mappings observed by consumers.  Protect all traversals, insertions and deletions on regulator_supply_alias_list with the existing regulator_list_mutex.
CVE-2025-68355: In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix exclusive map memory leak  When excl_prog_hash is 0 and excl_prog_hash_size is non-zero, the map also needs to be freed. Otherwise, the map memory will not be reclaimed, just like the memory leak problem reported by syzbot [1].  syzbot reported: BUG: memory leak   backtrace (crc 7b9fb9b4):     map_create+0x322/0x11e0 kernel/bpf/syscall.c:1512     __sys_bpf+0x3556/0x3610 kernel/bpf/syscall.c:6131
CVE-2025-68359: In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix double free of qgroup record after failure to add delayed ref head  In the previous code it was possible to incur into a double kfree() scenario when calling add_delayed_ref_head(). This could happen if the record was reported to already exist in the btrfs_qgroup_trace_extent_nolock() call, but then there was an error later on add_delayed_ref_head(). In this case, since add_delayed_ref_head() returned an error, the caller went to free the record. Since add_delayed_ref_head() couldn't set this kfree'd pointer to NULL, then kfree() would have acted on a non-NULL 'record' object which was pointing to memory already freed by the callee.  The problem comes from the fact that the responsibility to kfree the object is on both the caller and the callee at the same time. Hence, the fix for this is to shift the ownership of the 'qrecord' object out of the add_delayed_ref_head(). That is, we will never attempt to kfree() the given object inside of this function, and will expect the caller to act on the 'qrecord' object on its own. The only exception where the 'qrecord' object cannot be kfree'd is if it was inserted into the tracing logic, for which we already have the 'qrecord_inserted_ret' boolean to account for this. Hence, the caller has to kfree the object only if add_delayed_ref_head() reports not to have inserted it on the tracing logic.  As a side-effect of the above, we must guarantee that 'qrecord_inserted_ret' is properly initialized at the start of the function, not at the end, and then set when an actual insert happens. This way we avoid 'qrecord_inserted_ret' having an invalid value on an early exit.  The documentation from the add_delayed_ref_head() has also been updated to reflect on the exact ownership of the 'qrecord' object.
CVE-2025-68361: In the Linux kernel, the following vulnerability has been resolved:  erofs: limit the level of fs stacking for file-backed mounts  Otherwise, it could cause potential kernel stack overflow (e.g., EROFS mounting itself).
CVE-2025-68362: In the Linux kernel, the following vulnerability has been resolved:  wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()  The rtl8187_rx_cb() calculates the rx descriptor header address by subtracting its size from the skb tail pointer. However, it does not validate if the received packet (skb->len from urb->actual_length) is large enough to contain this header.  If a truncated packet is received, this will lead to a buffer underflow, reading memory before the start of the skb data area, and causing a kernel panic.  Add length checks for both rtl8187 and rtl8187b descriptor headers before attempting to access them, dropping the packet cleanly if the check fails.
CVE-2025-68366: In the Linux kernel, the following vulnerability has been resolved:  nbd: defer config unlock in nbd_genl_connect  There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK:  nbd_genl_connect   nbd_alloc_and_init_config // config_refs=1   nbd_start_device // config_refs=2   set NBD_RT_HAS_CONFIG_REF   open nbd // config_refs=3   recv_work done // config_refs=2       NBD_CLEAR_SOCK // config_refs=1       close nbd // config_refs=0   refcount_inc -> uaf  ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290  nbd_genl_connect+0x16d0/0x1ab0  genl_family_rcv_msg_doit+0x1f3/0x310  genl_rcv_msg+0x44a/0x790  The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect():          mutex_unlock(&nbd->config_lock);         if (!ret) {                 set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags); +               printk("before sleep\n"); +               mdelay(5 * 1000); +               printk("after sleep\n");                 refcount_inc(&nbd->config_refs);                 nbd_connect_reply(info, nbd->index);         }
CVE-2025-68367: In the Linux kernel, the following vulnerability has been resolved:  macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse  The following warning appears when running syzkaller, and this issue also exists in the mainline code.   ------------[ cut here ]------------  list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100.  WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130  Modules linked in:  CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014  RIP: 0010:__list_add_valid_or_report+0xf7/0x130  RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282  RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817  RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001  RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c  R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100  R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48  FS:  00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  PKRU: 80000000  Call Trace:   <TASK>   input_register_handler+0xb3/0x210   mac_hid_start_emulation+0x1c5/0x290   mac_hid_toggle_emumouse+0x20a/0x240   proc_sys_call_handler+0x4c2/0x6e0   new_sync_write+0x1b1/0x2d0   vfs_write+0x709/0x950   ksys_write+0x12a/0x250   do_syscall_64+0x5a/0x110   entry_SYSCALL_64_after_hwframe+0x78/0xe2  The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler.    CPU0                             CPU1   -------------------------        -------------------------   vfs_write() //write 1            vfs_write()  //write 1     proc_sys_write()                 proc_sys_write()       mac_hid_toggle_emumouse()          mac_hid_toggle_emumouse()         old_val = *valp // old_val=0                                            old_val = *valp // old_val=0                                            mutex_lock_killable()                                            proc_dointvec() // *valp=1                                            mac_hid_start_emulation()                                              input_register_handler()                                            mutex_unlock()         mutex_lock_killable()         proc_dointvec()         mac_hid_start_emulation()           input_register_handler() //Trigger Warning         mutex_unlock()  Fix this by moving the old_val read inside the mutex lock region.
CVE-2025-68368: In the Linux kernel, the following vulnerability has been resolved:  md: init bioset in mddev_init  IO operations may be needed before md_run(), such as updating metadata after writing sysfs. Without bioset, this triggers a NULL pointer dereference as below:   BUG: kernel NULL pointer dereference, address: 0000000000000020  Call Trace:   md_update_sb+0x658/0xe00   new_level_store+0xc5/0x120   md_attr_store+0xc9/0x1e0   sysfs_kf_write+0x6f/0xa0   kernfs_fop_write_iter+0x141/0x2a0   vfs_write+0x1fc/0x5a0   ksys_write+0x79/0x180   __x64_sys_write+0x1d/0x30   x64_sys_call+0x2818/0x2880   do_syscall_64+0xa9/0x580   entry_SYSCALL_64_after_hwframe+0x4b/0x53  Reproducer ```   mdadm -CR /dev/md0 -l1 -n2 /dev/sd[cd]   echo inactive > /sys/block/md0/md/array_state   echo 10 > /sys/block/md0/md/new_level ```  mddev_init() can only be called once per mddev, no need to test if bioset has been initialized anymore.
CVE-2025-68369: In the Linux kernel, the following vulnerability has been resolved:  ntfs3: init run lock for extend inode  After setting the inode mode of $Extend to a regular file, executing the truncate system call will enter the do_truncate() routine, causing the run_lock uninitialized error reported by syzbot.  Prior to patch 4e8011ffec79, if the inode mode of $Extend was not set to a regular file, the do_truncate() routine would not be entered.  Add the run_lock initialization when loading $Extend.  syzbot reported: INFO: trying to register non-static key. Call Trace:  dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120  assign_lock_key+0x133/0x150 kernel/locking/lockdep.c:984  register_lock_class+0x105/0x320 kernel/locking/lockdep.c:1299  __lock_acquire+0x99/0xd20 kernel/locking/lockdep.c:5112  lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868  down_write+0x96/0x1f0 kernel/locking/rwsem.c:1590  ntfs_set_size+0x140/0x200 fs/ntfs3/inode.c:860  ntfs_extend+0x1d9/0x970 fs/ntfs3/file.c:387  ntfs_setattr+0x2e8/0xbe0 fs/ntfs3/file.c:808
CVE-2025-68371: In the Linux kernel, the following vulnerability has been resolved:  scsi: smartpqi: Fix device resources accessed after device removal  Correct possible race conditions during device removal.  Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.  This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources.    - Check in the device reset handler if the device is still present in     the controller's SCSI device list before running; if not, the reset     is skipped.    - Cancel any pending TMF work that has not started in sdev_destroy().    - Ensure device freeing in sdev_destroy() is done while holding the     LUN reset mutex to avoid races with ongoing resets.
CVE-2025-68372: In the Linux kernel, the following vulnerability has been resolved:  nbd: defer config put in recv_work  There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE:   nbd_genl_connect     // conf_ref=2 (connect and recv_work A)   nbd_open        // conf_ref=3   recv_work A done     // conf_ref=2   NBD_CLEAR_SOCK       // conf_ref=1   nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B)   close nbd        // conf_ref=1   recv_work B     config_put         // conf_ref=0     atomic_dec(&config->recv_threads); -> UAF  Or only running NBD_CLEAR_SOCK:   nbd_genl_connect   // conf_ref=2   nbd_open       // conf_ref=3   NBD_CLEAR_SOCK     // conf_ref=2   close nbd     nbd_release       config_put     // conf_ref=1   recv_work     config_put       // conf_ref=0     atomic_dec(&config->recv_threads); -> UAF  Commit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying the waiter") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared.  However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup.  Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave.  In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock):  path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT):   connect  // nbd_refs=1 (trigger recv_work)   open nbd // nbd_refs=2   NBD_CLEAR_SOCK   close nbd     nbd_release       nbd_disconnect_and_put         flush_workqueue // recv_work done       nbd_config_put         nbd_put // nbd_refs=1       nbd_put // nbd_refs=0         queue_work  path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT):   connect  // nbd_refs=2 (trigger recv_work)   open nbd // nbd_refs=3   NBD_CLEAR_SOCK // conf_refs=2   close nbd     nbd_release       nbd_config_put // conf_refs=1       nbd_put // nbd_refs=2   recv_work done // conf_refs=0, nbd_refs=1   rmmod // nbd_refs=0  Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")
CVE-2025-68373: In the Linux kernel, the following vulnerability has been resolved:  md: avoid repeated calls to del_gendisk  There is a uaf problem which is found by case 23rdev-lifetime:  Oops: general protection fault, probably for non-canonical address 0xdead000000000122 RIP: 0010:bdi_unregister+0x4b/0x170 Call Trace:  <TASK>  __del_gendisk+0x356/0x3e0  mddev_unlock+0x351/0x360  rdev_attr_store+0x217/0x280  kernfs_fop_write_iter+0x14a/0x210  vfs_write+0x29e/0x550  ksys_write+0x74/0xf0  do_syscall_64+0xbb/0x380  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff5250a177e  The sequence is: 1. rdev remove path gets reconfig_mutex 2. rdev remove path release reconfig_mutex in mddev_unlock 3. md stop calls do_md_stop and sets MD_DELETED 4. rdev remove path calls del_gendisk because MD_DELETED is set 5. md stop path release reconfig_mutex and calls del_gendisk again  So there is a race condition we should resolve. This patch adds a flag MD_DO_DELETE to avoid the race condition.
CVE-2025-68374: In the Linux kernel, the following vulnerability has been resolved:  md: fix rcu protection in md_wakeup_thread  We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.
CVE-2025-68375: In the Linux kernel, the following vulnerability has been resolved:  perf/x86: Fix NULL event access and potential PEBS record loss  When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record.  While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows.  perf_event_overflow()   -> __perf_event_overflow()     ->__perf_event_account_interrupt()       -> perf_event_throttle_group()         -> perf_event_throttle()           -> event->pmu->stop()             -> x86_pmu_stop()  The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL.  Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access.  To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[].
CVE-2025-68376: In the Linux kernel, the following vulnerability has been resolved:  coresight: ETR: Fix ETR buffer use-after-free issue  When ETR is enabled as CS_MODE_SYSFS, if the buffer size is changed and enabled again, currently sysfs_buf will point to the newly allocated memory(buf_new) and free the old memory(buf_old). But the etr_buf that is being used by the ETR remains pointed to buf_old, not updated to buf_new. In this case, it will result in a memory use-after-free issue.  Fix this by checking ETR's mode before updating and releasing buf_old, if the mode is CS_MODE_SYSFS, then skip updating and releasing it.
CVE-2025-68378: In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix stackmap overflow check in __bpf_get_stackid()  Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace  contains more stack entries than the stack map bucket can hold,  leading to an out-of-bounds write in the bucket's data array.
CVE-2025-68379: In the Linux kernel, the following vulnerability has been resolved:  RDMA/rxe: Fix null deref on srq->rq.queue after resize failure  A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask.  Call Trace: <TASK> rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e
CVE-2025-68724: In the Linux kernel, the following vulnerability has been resolved:  crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_id  Use check_add_overflow() to guard against potential integer overflows when adding the binary blob lengths and the size of an asymmetric_key_id structure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents a possible buffer overflow when copying data from potentially malicious X.509 certificate fields that can be arbitrarily large, such as ASN.1 INTEGER serial numbers, issuer names, etc.
CVE-2025-68726: In the Linux kernel, the following vulnerability has been resolved:  crypto: aead - Fix reqsize handling  Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg") introduced cra_reqsize field in crypto_alg struct to replace type specific reqsize fields. It looks like this was introduced specifically for ahash and acomp from the commit description as subsequent commits add necessary changes in these alg frameworks.  However, this is being recommended for use in all crypto algs instead of setting reqsize using crypto_*_set_reqsize(). Using cra_reqsize in aead algorithms, hence, causes memory corruptions and crashes as the underlying functions in the algorithm framework have not been updated to set the reqsize properly from cra_reqsize. [1]  Add proper set_reqsize calls in the aead init function to properly initialize reqsize for these algorithms in the framework.  [1]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b
CVE-2025-68727: In the Linux kernel, the following vulnerability has been resolved:  ntfs3: Fix uninit buffer allocated by __getname()  Fix uninit errors caused after buffer allocation given to 'de'; by initializing the buffer with zeroes. The fix was found by using KMSAN.
CVE-2025-68728: In the Linux kernel, the following vulnerability has been resolved:  ntfs3: fix uninit memory after failed mi_read in mi_format_new  Fix a KMSAN un-init bug found by syzkaller.  ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be uptodate. We do not bring the buffer uptodate before setting it as uptodate. If the buffer were to not be uptodate, it could mean adding a buffer with un-init data to the mi record. Attempting to load that record will trigger KMSAN.  Avoid this by setting the buffer as uptodate, if it’s not already, by overwriting it.
CVE-2025-68729: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath12k: Fix MSDU buffer types handling in RX error path  Currently, packets received on the REO exception ring from unassociated peers are of MSDU buffer type, while the driver expects link descriptor type packets. These packets are not parsed further due to a return check on packet type in ath12k_hal_desc_reo_parse_err(), but the associated skb is not freed. This may lead to kernel crashes and buffer leaks.  Hence to fix, update the RX error handler to explicitly drop MSDU buffer type packets received on the REO exception ring. This prevents further processing of invalid packets and ensures stability in the RX error handling path.  Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
CVE-2025-68731: In the Linux kernel, the following vulnerability has been resolved:  accel/amdxdna: Fix an integer overflow in aie2_query_ctx_status_array()  The unpublished smatch static checker reported a warning.  drivers/accel/amdxdna/aie2_pci.c:904 aie2_query_ctx_status_array() warn: potential user controlled sizeof overflow 'args->num_element * args->element_size' '1-u32max(user) * 1-u32max(user)'  Even this will not cause a real issue, it is better to put a reasonable limitation for element_size and num_element. Add condition to make sure the input element_size <= 4K and num_element <= 1K.