xamxte/cve-to-cwe huggingface dataset:
CVE-2025-40213: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_complete  There is a BUG: KASAN: stack-out-of-bounds in set_mesh_sync due to memcpy from badly declared on-stack flexible array.  Another crash is in set_mesh_complete() due to double list_del via mgmt_pending_valid + mgmt_pending_remove.  Use DEFINE_FLEX to declare the flexible array right, and don't memcpy outside bounds.  As mgmt_pending_valid removes the cmd from list, use mgmt_pending_free, and also report status on error.
CVE-2025-11131: In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed
CVE-2025-11132: In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed
CVE-2025-11133: In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed
CVE-2025-3012: In dpc modem, there is a possible system crash due to null pointer dereference. This could lead to remote denial of service with no additional execution privileges needed
CVE-2025-61607: In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed
CVE-2025-61608: In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed
CVE-2025-61609: In modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed
CVE-2025-61610: In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed
CVE-2025-61617: In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed
CVE-2025-61618: In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed
CVE-2025-61619: In nr modem, there is a possible system crash due to improper input validation. This could lead to remote denial of service with no additional execution privileges needed
CVE-2025-21080: Improper export of android application components in Dynamic Lockscreen prior to SMR Dec-2025 Release 1 allows local attackers to access files with Dynamic Lockscreen's privilege.
CVE-2025-58475: Improper input validation in libsec-ril.so prior to SMR Dec-2025 Release 1 allows local privileged attackers to write out-of-bounds memory.
CVE-2025-58481: Improper access control in MPRemoteService of MotionPhoto prior to version 4.1.51 allows local attackers to start privileged service.
CVE-2025-58482: Improper access control in MPLocalService of MotionPhoto prior to version 4.1.51 allows local attackers to start privileged service.
CVE-2025-58483: Improper export of android application components in Galaxy Store for Galaxy Watch prior to version 1.0.06.29 allows local attacker to install arbitrary application on Galaxy Store.
CVE-2025-58484: Incorrect default permissions in Samsung Cloud Assistant prior to version 8.0.03.8 allows local attacker to access partial data in sandbox.
CVE-2025-58485: Improper input validation in Samsung Internet prior to version 29.0.0.48 allows local attackers to inject arbitrary script.
CVE-2025-58486: Improper input validation in Samsung Account prior to version 15.5.01.1 allows local attacker to execute arbitrary script.
CVE-2025-58487: Improper authorization in Samsung Account prior to version 15.5.01.1 allows local attacker to launch arbitrary activity with Samsung Account privilege.
CVE-2025-58488: Improper verification of source of a communication channel in SmartTouchCall prior to version 1.0.1.1 allows remote attackers to access sensitive information. User interaction is required for triggering this vulnerability.
CVE-2025-12630: The Upload.am  WordPress plugin before 1.0.1 is vulnerable to arbitrary option disclosure due to a missing capability check on its AJAX request handler, allowing users such as contributor to view site options.
CVE-2025-40214: In the Linux kernel, the following vulnerability has been resolved:  af_unix: Initialise scc_index in unix_add_edge().  Quang Le reported that the AF_UNIX GC could garbage-collect a receive queue of an alive in-flight socket, with a nice repro.  The repro consists of three stages.    1)     1-a. Create a single cyclic reference with many sockets     1-b. close() all sockets     1-c. Trigger GC    2)     2-a. Pass sk-A to an embryo sk-B     2-b. Pass sk-X to sk-X     2-c. Trigger GC    3)     3-a. accept() the embryo sk-B     3-b. Pass sk-B to sk-C     3-c. close() the in-flight sk-A     3-d. Trigger GC  As of 2-c, sk-A and sk-X are linked to unix_unvisited_vertices, and unix_walk_scc() groups them into two different SCCs:    unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START)   unix_sk(sk-X)->vertex->scc_index = 3  Once GC completes, unix_graph_grouped is set to true. Also, unix_graph_maybe_cyclic is set to true due to sk-X's cyclic self-reference, which makes close() trigger GC.  At 3-b, unix_add_edge() allocates unix_sk(sk-B)->vertex and links it to unix_unvisited_vertices.  unix_update_graph() is called at 3-a. and 3-b., but neither unix_graph_grouped nor unix_graph_maybe_cyclic is changed because both sk-B's listener and sk-C are not in-flight.  3-c decrements sk-A's file refcnt to 1.  Since unix_graph_grouped is true at 3-d, unix_walk_scc_fast() is finally called and iterates 3 sockets sk-A, sk-B, and sk-X:    sk-A -> sk-B (-> sk-C)   sk-X -> sk-X  This is totally fine.  All of them are not yet close()d and should be grouped into different SCCs.  However, unix_vertex_dead() misjudges that sk-A and sk-B are in the same SCC and sk-A is dead.    unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Wrong!   &&   sk-A's file refcnt == unix_sk(sk-A)->vertex->out_degree                                        ^-- 1 in-flight count for sk-B   -> sk-A is dead !?  The problem is that unix_add_edge() does not initialise scc_index.  Stage 1) is used for heap spraying, making a newly allocated vertex have vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START) set by unix_walk_scc() at 1-c.  Let's track the max SCC index from the previous unix_walk_scc() call and assign the max + 1 to a new vertex's scc_index.  This way, we can continue to avoid Tarjan's algorithm while preventing misjudgments.
CVE-2025-40215: In the Linux kernel, the following vulnerability has been resolved:  xfrm: delete x->tunnel as we delete x  The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete.  We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state.  Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped.  A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.
CVE-2025-40218: In the Linux kernel, the following vulnerability has been resolved:  mm/damon/vaddr: do not repeat pte_offset_map_lock() until success  DAMON's virtual address space operation set implementation (vaddr) calls pte_offset_map_lock() inside the page table walk callback function.  This is for reading and writing page table accessed bits.  If pte_offset_map_lock() fails, it retries by returning the page table walk callback function with ACTION_AGAIN.  pte_offset_map_lock() can continuously fail if the target is a pmd migration entry, though.  Hence it could cause an infinite page table walk if the migration cannot be done until the page table walk is finished.  This indeed caused a soft lockup when CPU hotplugging and DAMON were running in parallel.  Avoid the infinite loop by simply not retrying the page table walk.  DAMON is promising only a best-effort accuracy, so missing access to such pages is no problem.
CVE-2025-40219: In the Linux kernel, the following vulnerability has been resolved:  PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV  Before disabling SR-IOV via config space accesses to the parent PF, sriov_disable() first removes the PCI devices representing the VFs.  Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()") such removal operations are serialized against concurrent remove and rescan using the pci_rescan_remove_lock. No such locking was ever added in sriov_disable() however. In particular when commit 18f9e9d150fc ("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI device removal into sriov_del_vfs() there was still no locking around the pci_iov_remove_virtfn() calls.  On s390 the lack of serialization in sriov_disable() may cause double remove and list corruption with the below (amended) trace being observed:    PSW:  0704c00180000000 0000000c914e4b38 (klist_put+56)   GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001  00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480  0000000000000001 0000000000000000 0000000000000000 0000000180692828  00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8   #0 [3800313fb20] device_del at c9158ad5c   #1 [3800313fb88] pci_remove_bus_device at c915105ba   #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198   #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0   #4 [3800313fc60] zpci_bus_remove_device at c90fb6104   #5 [3800313fca0] __zpci_event_availability at c90fb3dca   #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2   #7 [3800313fd60] crw_collect_info at c91905822   #8 [3800313fe10] kthread at c90feb390   #9 [3800313fe68] __ret_from_fork at c90f6aa64   #10 [3800313fe98] ret_from_fork at c9194f3f2.  This is because in addition to sriov_disable() removing the VFs, the platform also generates hot-unplug events for the VFs. This being the reverse operation to the hotplug events generated by sriov_enable() and handled via pdev->no_vf_scan. And while the event processing takes pci_rescan_remove_lock and checks whether the struct pci_dev still exists, the lack of synchronization makes this checking racy.  Other races may also be possible of course though given that this lack of locking persisted so long observable races seem very rare. Even on s390 the list corruption was only observed with certain devices since the platform events are only triggered by config accesses after the removal, so as long as the removal finished synchronously they would not race. Either way the locking is missing so fix this by adding it to the sriov_del_vfs() helper.  Just like PCI rescan-remove, locking is also missing in sriov_add_vfs() including for the error case where pci_stop_and_remove_bus_device() is called without the PCI rescan-remove lock being held. Even in the non-error case, adding new PCI devices and buses should be serialized via the PCI rescan-remove lock. Add the necessary locking.
CVE-2025-40221: In the Linux kernel, the following vulnerability has been resolved:  media: pci: mg4b: fix uninitialized iio scan data  Fix potential leak of uninitialized stack data to userspace by ensuring that the `scan` structure is zeroed before use.
CVE-2025-40223: In the Linux kernel, the following vulnerability has been resolved:  most: usb: Fix use-after-free in hdm_disconnect  hdm_disconnect() calls most_deregister_interface(), which eventually unregisters the MOST interface device with device_unregister(iface->dev). If that drops the last reference, the device core may call release_mdev() immediately while hdm_disconnect() is still executing.  The old code also freed several mdev-owned allocations in hdm_disconnect() and then performed additional put_device() calls. Depending on refcount order, this could lead to use-after-free or double-free when release_mdev() ran (or when unregister paths also performed puts).  Fix by moving the frees of mdev-owned allocations into release_mdev(), so they happen exactly once when the device is truly released, and by dropping the extra put_device() calls in hdm_disconnect() that are redundant after device_unregister() and most_deregister_interface().  This addresses the KASAN slab-use-after-free reported by syzbot in hdm_disconnect(). See report and stack traces in the bug link below.
CVE-2025-40224: In the Linux kernel, the following vulnerability has been resolved:  hwmon: (cgbc-hwmon) Add missing NULL check after devm_kzalloc()  The driver allocates memory for sensor data using devm_kzalloc(), but did not check if the allocation succeeded. In case of memory allocation failure, dereferencing the NULL pointer would lead to a kernel crash.  Add a NULL pointer check and return -ENOMEM to handle allocation failure properly.
CVE-2025-40225: In the Linux kernel, the following vulnerability has been resolved:  drm/panthor: Fix kernel panic on partial unmap of a GPU VA region  This commit address a kernel panic issue that can happen if Userspace tries to partially unmap a GPU virtual region (aka drm_gpuva). The VM_BIND interface allows partial unmapping of a BO.  Panthor driver pre-allocates memory for the new drm_gpuva structures that would be needed for the map/unmap operation, done using drm_gpuvm layer. It expected that only one new drm_gpuva would be needed on umap but a partial unmap can require 2 new drm_gpuva and that's why it ended up doing a NULL pointer dereference causing a kernel panic.  Following dump was seen when partial unmap was exercised.  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000078  Mem abort info:    ESR = 0x0000000096000046    EC = 0x25: DABT (current EL), IL = 32 bits    SET = 0, FnV = 0    EA = 0, S1PTW = 0    FSC = 0x06: level 2 translation fault  Data abort info:    ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000    CM = 0, WnR = 1, TnD = 0, TagAccess = 0    GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0  user pgtable: 4k pages, 48-bit VAs, pgdp=000000088a863000  [000000000000078] pgd=080000088a842003, p4d=080000088a842003, pud=0800000884bf5003, pmd=0000000000000000  Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP  <snip>  pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)  pc : panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]  lr : panthor_gpuva_sm_step_remap+0x6c/0x330 [panthor]  sp : ffff800085d43970  x29: ffff800085d43970 x28: ffff00080363e440 x27: ffff0008090c6000  x26: 0000000000000030 x25: ffff800085d439f8 x24: ffff00080d402000  x23: ffff800085d43b60 x22: ffff800085d439e0 x21: ffff00080abdb180  x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000010  x17: 6e656c202c303030 x16: 3666666666646466 x15: 393d61766f69202c  x14: 312d3d7361203a70 x13: 303030323d6e656c x12: ffff80008324bf58  x11: 0000000000000003 x10: 0000000000000002 x9 : ffff8000801a6a9c  x8 : ffff00080360b300 x7 : 0000000000000000 x6 : 000000088aa35fc7  x5 : fff1000080000000 x4 : ffff8000842ddd30 x3 : 0000000000000001  x2 : 0000000100000000 x1 : 0000000000000001 x0 : 0000000000000078  Call trace:   panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor]   op_remap_cb.isra.22+0x50/0x80   __drm_gpuvm_sm_unmap+0x10c/0x1c8   drm_gpuvm_sm_unmap+0x40/0x60   panthor_vm_exec_op+0xb4/0x3d0 [panthor]   panthor_vm_bind_exec_sync_op+0x154/0x278 [panthor]   panthor_ioctl_vm_bind+0x160/0x4a0 [panthor]   drm_ioctl_kernel+0xbc/0x138   drm_ioctl+0x240/0x500   __arm64_sys_ioctl+0xb0/0xf8   invoke_syscall+0x4c/0x110   el0_svc_common.constprop.1+0x98/0xf8   do_el0_svc+0x24/0x38   el0_svc+0x40/0xf8   el0t_64_sync_handler+0xa0/0xc8   el0t_64_sync+0x174/0x178
CVE-2025-40226: In the Linux kernel, the following vulnerability has been resolved:  firmware: arm_scmi: Account for failed debug initialization  When the SCMI debug subsystem fails to initialize, the related debug root will be missing, and the underlying descriptor will be NULL.  Handle this fault condition in the SCMI debug helpers that maintain metrics counters.
CVE-2025-40227: In the Linux kernel, the following vulnerability has been resolved:  mm/damon/sysfs: dealloc commit test ctx always  The damon_ctx for testing online DAMON parameters commit inputs is deallocated only when the test fails.  This means memory is leaked for every successful online DAMON parameters commit.  Fix the leak by always deallocating it.
CVE-2025-40228: In the Linux kernel, the following vulnerability has been resolved:  mm/damon/sysfs: catch commit test ctx alloc failure  Patch series "mm/damon/sysfs: fix commit test damon_ctx [de]allocation".  DAMON sysfs interface dynamically allocates and uses a damon_ctx object for testing if given inputs for online DAMON parameters update is valid. The object is being used without an allocation failure check, and leaked when the test succeeds.  Fix the two bugs.   This patch (of 2):  The damon_ctx for testing online DAMON parameters commit inputs is used without its allocation failure check.  This could result in an invalid memory access.  Fix it by directly returning an error when the allocation failed.
CVE-2025-40229: In the Linux kernel, the following vulnerability has been resolved:  mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme  Currently, damon_destroy_scheme() only cleans up the filter list but leaves ops_filter untouched, which could lead to memory leaks when a scheme is destroyed.  This patch ensures both filter and ops_filter are properly freed in damon_destroy_scheme(), preventing potential memory leaks.
CVE-2025-40231: In the Linux kernel, the following vulnerability has been resolved:  vsock: fix lock inversion in vsock_assign_transport()  Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.  The issue was introduced by commit 687aa0c5581b ("vsock: Fix transport_* TOCTOU") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created.  Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get().
CVE-2025-40232: In the Linux kernel, the following vulnerability has been resolved:  rv: Fully convert enabled_monitors to use list_head as iterator  The callbacks in enabled_monitors_seq_ops are inconsistent. Some treat the iterator as struct rv_monitor *, while others treat the iterator as struct list_head *.  This causes a wrong type cast and crashes the system as reported by Nathan.  Convert everything to use struct list_head * as iterator. This also makes enabled_monitors consistent with available_monitors.
CVE-2025-40233: In the Linux kernel, the following vulnerability has been resolved:  ocfs2: clear extent cache after moving/defragmenting extents  The extent map cache can become stale when extents are moved or defragmented, causing subsequent operations to see outdated extent flags.  This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().  The problem occurs when: 1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED 2. ioctl(FITRIM) triggers ocfs2_move_extents() 3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2) 4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent()    which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0) 5. The extent map cache is not invalidated after the move 6. Later write() operations read stale cached flags (0x2) but disk has    updated flags (0x0), causing a mismatch 7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggers  Fix by clearing the extent map cache after each extent move/defrag operation in __ocfs2_move_extents_range().  This ensures subsequent operations read fresh extent data from disk.
CVE-2025-40234: In the Linux kernel, the following vulnerability has been resolved:  platform/x86: alienware-wmi-wmax: Fix NULL pointer dereference in sleep handlers  Devices without the AWCC interface don't initialize `awcc`. Add a check before dereferencing it in sleep handlers.
CVE-2025-40235: In the Linux kernel, the following vulnerability has been resolved:  btrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots()  If fs_info->super_copy or fs_info->super_for_commit allocated failed in btrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info(). Otherwise btrfs_check_leaked_roots() would access NULL pointer because fs_info->allocated_roots had not been initialised.  syzkaller reported the following information:   ------------[ cut here ]------------   BUG: unable to handle page fault for address: fffffffffffffbb0   #PF: supervisor read access in kernel mode   #PF: error_code(0x0000) - not-present page   PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0   Oops: Oops: 0000 [#1] SMP KASAN PTI   CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy)   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...)   RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline]   RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline]   RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline]   RIP: 0010:refcount_read include/linux/refcount.h:170 [inline]   RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230   [...]   Call Trace:    <TASK>    btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280    btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029    btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097    vfs_get_tree+0x98/0x320 fs/super.c:1759    do_new_mount+0x357/0x660 fs/namespace.c:3899    path_mount+0x716/0x19c0 fs/namespace.c:4226    do_mount fs/namespace.c:4239 [inline]    __do_sys_mount fs/namespace.c:4450 [inline]    __se_sys_mount fs/namespace.c:4427 [inline]    __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]    do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94    entry_SYSCALL_64_after_hwframe+0x76/0x7e   RIP: 0033:0x7f032eaffa8d   [...]
CVE-2025-40236: In the Linux kernel, the following vulnerability has been resolved:  virtio-net: zero unused hash fields  When GSO tunnel is negotiated virtio_net_hdr_tnl_from_skb() tries to initialize the tunnel metadata but forget to zero unused rxhash fields. This may leak information to another side. Fixing this by zeroing the unused hash fields.