xamxte/cve-to-cwe huggingface dataset:
CVE-2025-38168: In the Linux kernel, the following vulnerability has been resolved:  perf: arm-ni: Unregister PMUs on probe failure  When a resource allocation fails in one clock domain of an NI device, we need to properly roll back all previously registered perf PMUs in other clock domains of the same device.  Otherwise, it can lead to kernel panics.  Calling arm_ni_init+0x0/0xff8 [arm_ni] @ 2374 arm-ni ARMHCB70:00: Failed to request PMU region 0x1f3c13000 arm-ni ARMHCB70:00: probe with driver arm-ni failed with error -16 list_add corruption: next->prev should be prev (fffffd01e9698a18), but was 0000000000000000. (next=ffff10001a0decc8). pstate: 6340009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : list_add_valid_or_report+0x7c/0xb8 lr : list_add_valid_or_report+0x7c/0xb8 Call trace:  __list_add_valid_or_report+0x7c/0xb8  perf_pmu_register+0x22c/0x3a0  arm_ni_probe+0x554/0x70c [arm_ni]  platform_probe+0x70/0xe8  really_probe+0xc6/0x4d8  driver_probe_device+0x48/0x170  __driver_attach+0x8e/0x1c0  bus_for_each_dev+0x64/0xf0  driver_add+0x138/0x260  bus_add_driver+0x68/0x138  __platform_driver_register+0x2c/0x40  arm_ni_init+0x14/0x2a [arm_ni]  do_init_module+0x36/0x298 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops - BUG: Fatal exception SMP: stopping secondary CPUs
CVE-2025-38170: In the Linux kernel, the following vulnerability has been resolved:  arm64/fpsimd: Discard stale CPU state when handling SME traps  The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from do_sme_acc() where SME traps are not expected while TIF_SME is set:  |        /* With TIF_SME userspace shouldn't generate any traps */ |        if (test_and_set_thread_flag(TIF_SME)) |                WARN_ON(1);  This is very similar to the SVE issue we fixed in commit:    751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")  The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g.  | void do_sme_acc(unsigned long esr, struct pt_regs *regs) | { |         // Trap on CPU 0 with TIF_SME clear, SME traps enabled |         // task->fpsimd_cpu is 0. |         // per_cpu_ptr(&fpsimd_last_state, 0) is task. | |         ... | |         // Preempted; migrated from CPU 0 to CPU 1. |         // TIF_FOREIGN_FPSTATE is set. | |         get_cpu_fpsimd_context(); | |         /* With TIF_SME userspace shouldn't generate any traps */ |         if (test_and_set_thread_flag(TIF_SME)) |                 WARN_ON(1); | |         if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { |                 unsigned long vq_minus_one = |                         sve_vq_from_vl(task_get_sme_vl(current)) - 1; |                 sme_set_vq(vq_minus_one); | |                 fpsimd_bind_task_to_cpu(); |         } | |         put_cpu_fpsimd_context(); | |         // Preempted; migrated from CPU 1 to CPU 0. |         // task->fpsimd_cpu is still 0 |         // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: |         // - Stale HW state is reused (with SME traps enabled) |         // - TIF_FOREIGN_FPSTATE is cleared |         // - A return to userspace skips HW state restore | }  Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace.  Note: this was originallly posted as [1].  [ Rutland: rewrite commit message ]
CVE-2025-5920: The Sharable Password Protected Posts before version 1.1.1 allows access to password protected posts by providing a secret key in a GET parameter. However, the key is exposed by the REST API.
CVE-2025-38174: In the Linux kernel, the following vulnerability has been resolved:  thunderbolt: Do not double dequeue a configuration request  Some of our devices crash in tb_cfg_request_dequeue():   general protection fault, probably for non-canonical address 0xdead000000000122   CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65  RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0  Call Trace:  <TASK>  ? tb_cfg_request_dequeue+0x2d/0xa0  tb_cfg_request_work+0x33/0x80  worker_thread+0x386/0x8f0  kthread+0xed/0x110  ret_from_fork+0x38/0x50  ret_from_fork_asm+0x1b/0x30  The circumstances are unclear, however, the theory is that tb_cfg_request_work() can be scheduled twice for a request: first time via frame.callback from ring_work() and second time from tb_cfg_request().  Both times kworkers will execute tb_cfg_request_dequeue(), which results in double list_del() from the ctl->request_queue (the list poison deference hints at it: 0xdead000000000122).  Do not dequeue requests that don't have TB_CFG_REQUEST_ACTIVE bit set.
CVE-2025-38182: In the Linux kernel, the following vulnerability has been resolved:  ublk: santizize the arguments from userspace when adding a device  Sanity check the values for queue depth and number of queues we get from userspace when adding a device.
CVE-2025-38190: In the Linux kernel, the following vulnerability has been resolved:  atm: Revert atm_account_tx() if copy_from_iter_full() fails.  In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc by atm_account_tx().  It is expected to be reverted by atm_pop_raw() later called by vcc->dev->ops->send(vcc, skb).  However, vcc_sendmsg() misses the same revert when copy_from_iter_full() fails, and then we will leak a socket.  Let's factorise the revert part as atm_return_tx() and call it in the failure path.  Note that the corresponding sk_wmem_alloc operation can be found in alloc_tx() as of the blamed commit.    $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~
CVE-2025-38194: In the Linux kernel, the following vulnerability has been resolved:  jffs2: check that raw node were preallocated before writing summary  Syzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault injection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't check return value of jffs2_prealloc_raw_node_refs and simply lets any error propagate into jffs2_sum_write_data, which eventually calls jffs2_link_node_ref in order to link the summary to an expectedly allocated node.  kernel BUG at fs/jffs2/nodelist.c:592! invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592 Call Trace:  <TASK>  jffs2_sum_write_data fs/jffs2/summary.c:841 [inline]  jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874  jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388  jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197  jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362  jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301  generic_perform_write+0x314/0x5d0 mm/filemap.c:3856  __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973  generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005  call_write_iter include/linux/fs.h:2265 [inline]  do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735  do_iter_write+0x186/0x710 fs/read_write.c:861  vfs_iter_write+0x70/0xa0 fs/read_write.c:902  iter_file_splice_write+0x73b/0xc90 fs/splice.c:685  do_splice_from fs/splice.c:763 [inline]  direct_splice_actor+0x10c/0x170 fs/splice.c:950  splice_direct_to_actor+0x337/0xa10 fs/splice.c:896  do_splice_direct+0x1a9/0x280 fs/splice.c:1002  do_sendfile+0xb13/0x12c0 fs/read_write.c:1255  __do_sys_sendfile64 fs/read_write.c:1323 [inline]  __se_sys_sendfile64 fs/read_write.c:1309 [inline]  __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309  do_syscall_x64 arch/x86/entry/common.c:51 [inline]  do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81  entry_SYSCALL_64_after_hwframe+0x6e/0xd8  Fix this issue by checking return value of jffs2_prealloc_raw_node_refs before calling jffs2_sum_write_data.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2025-38195: In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()  ERROR INFO:  CPU 25 Unable to handle kernel paging request at virtual address 0x0          ...  Call Trace:  [<900000000023c30c>] huge_pte_offset+0x3c/0x58  [<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438  [<900000000051fee8>] __get_user_pages+0xe0/0x4c8  [<9000000000522414>] faultin_page_range+0x84/0x380  [<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48  [<900000000056689c>] do_madvise+0x1bc/0x3e8  [<9000000000566df4>] sys_madvise+0x24/0x38  [<90000000015b9e88>] do_syscall+0x78/0x98  [<9000000000221f18>] handle_syscall+0xb8/0x158  In some cases, pmd may be NULL and rely on NULL as the return value for processing, so it is necessary to determine this situation here.
CVE-2025-38218: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on sit_bitmap_size  w/ below testcase, resize will generate a corrupted image which contains inconsistent metadata, so when mounting such image, it will trigger kernel panic:  touch img truncate -s $((512*1024*1024*1024)) img mkfs.f2fs -f img $((256*1024*1024)) resize.f2fs -s -i img -t $((1024*1024*1024)) mount img /mnt/f2fs  ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.h:863! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fs_ra_meta_pages+0x47c/0x490  Call Trace:  f2fs_build_segment_manager+0x11c3/0x2600  f2fs_fill_super+0xe97/0x2840  mount_bdev+0xf4/0x140  legacy_get_tree+0x2b/0x50  vfs_get_tree+0x29/0xd0  path_mount+0x487/0xaf0  __x64_sys_mount+0x116/0x150  do_syscall_64+0x82/0x190  entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdbfde1bcfe  The reaseon is:  sit_i->bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum there are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt is 4762, build_sit_entries() -> current_sit_addr() tries to access out-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap and sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on().  Let's add sanity check in f2fs_sanity_check_ckpt() to avoid panic.
CVE-2025-38219: In the Linux kernel, the following vulnerability has been resolved:  f2fs: prevent kernel warning due to negative i_nlink from corrupted image  WARNING: CPU: 1 PID: 9426 at fs/inode.c:417 drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Modules linked in: CPU: 1 UID: 0 PID: 9426 Comm: syz-executor568 Not tainted 6.14.0-12627-g94d471a4f428 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:drop_nlink+0xac/0xd0 home/cc/linux/fs/inode.c:417 Code: 48 8b 5d 28 be 08 00 00 00 48 8d bb 70 07 00 00 e8 f9 67 e6 ff f0 48 ff 83 70 07 00 00 5b 5d e9 9a 12 82 ff e8 95 12 82 ff 90 &lt;0f&gt; 0b 90 c7 45 48 ff ff ff ff 5b 5d e9 83 12 82 ff e8 fe 5f e6 ff RSP: 0018:ffffc900026b7c28 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8239710f RDX: ffff888041345a00 RSI: ffffffff8239717b RDI: 0000000000000005 RBP: ffff888054509ad0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: ffffffff9ab36f08 R12: ffff88804bb40000 R13: ffff8880545091e0 R14: 0000000000008000 R15: ffff8880545091e0 FS:  000055555d0c5880(0000) GS:ffff8880eb3e3000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f915c55b178 CR3: 0000000050d20000 CR4: 0000000000352ef0 Call Trace:  <task>  f2fs_i_links_write home/cc/linux/fs/f2fs/f2fs.h:3194 [inline]  f2fs_drop_nlink+0xd1/0x3c0 home/cc/linux/fs/f2fs/dir.c:845  f2fs_delete_entry+0x542/0x1450 home/cc/linux/fs/f2fs/dir.c:909  f2fs_unlink+0x45c/0x890 home/cc/linux/fs/f2fs/namei.c:581  vfs_unlink+0x2fb/0x9b0 home/cc/linux/fs/namei.c:4544  do_unlinkat+0x4c5/0x6a0 home/cc/linux/fs/namei.c:4608  __do_sys_unlink home/cc/linux/fs/namei.c:4654 [inline]  __se_sys_unlink home/cc/linux/fs/namei.c:4652 [inline]  __x64_sys_unlink+0xc5/0x110 home/cc/linux/fs/namei.c:4652  do_syscall_x64 home/cc/linux/arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0xc7/0x250 home/cc/linux/arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb3d092324b Code: 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 57 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdc232d938 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb3d092324b RDX: 00007ffdc232d960 RSI: 00007ffdc232d960 RDI: 00007ffdc232d9f0 RBP: 00007ffdc232d9f0 R08: 0000000000000001 R09: 00007ffdc232d7c0 R10: 00000000fffffffd R11: 0000000000000206 R12: 00007ffdc232eaf0 R13: 000055555d0cebb0 R14: 00007ffdc232d958 R15: 0000000000000001  </task>
CVE-2025-38230: In the Linux kernel, the following vulnerability has been resolved:  jfs: validate AG parameters in dbMount() to prevent crashes  Validate db_agheight, db_agwidth, and db_agstart in dbMount to catch corrupted metadata early and avoid undefined behavior in dbAllocAG. Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE:  - agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift   (L2LPERCTL - 2*agheight) >= 0. - agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight))   ensures agperlev >= 1.   - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5).   - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG;     2^(10 - 2*agheight) prevents division to 0. - agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within   stree (size 1365).   - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8).  UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9 shift exponent -335544310 is negative CPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace:  <TASK>  __dump_stack lib/dump_stack.c:94 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120  ubsan_epilogue lib/ubsan.c:231 [inline]  __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468  dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400  dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613  jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105  jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:906 [inline]  __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2025-38235: In the Linux kernel, the following vulnerability has been resolved:  HID: appletb-kbd: fix "appletb_backlight" backlight device reference counting  During appletb_kbd_probe, probe attempts to get the backlight device by name. When this happens backlight_device_get_by_name looks for a device in the backlight class which has name "appletb_backlight" and upon finding a match it increments the reference count for the device and returns it to the caller. However this reference is never released leading to a reference leak.  Fix this by decrementing the backlight device reference count on removal via put_device and on probe failure.
CVE-2025-20997: Incorrect default permission in Framework for Galaxy Watch prior to SMR Jul-2025 Release 1 allows local attackers to reset some configuration of Galaxy Watch.
CVE-2025-20998: Improper access control in SamsungAccount for Galaxy Watch prior to SMR Jul-2025 Release 1 allows local attackers to access phone number.
CVE-2025-21000: Improper privilege management in Bluetooth prior to SMR Jul-2025 Release 1 allows local attackers to enable Bluetooth.
CVE-2025-21001: Improper access control in LeAudioService prior to SMR Jul-2025 Release 1 allows local attackers to stop broadcasting Auracast.
CVE-2025-21002: Improper access control in LeAudioService prior to SMR Jul-2025 Release 1 allows local attackers to manipulate broadcasting Auracast.
CVE-2025-21005: Improper access control in isemtelephony prior to Android 15 allows local attackers to access sensitive information.
CVE-2025-38238: In the Linux kernel, the following vulnerability has been resolved:  scsi: fnic: Fix crash in fnic_wq_cmpl_handler when FDMI times out  When both the RHBA and RPA FDMI requests time out, fnic reuses a frame to send ABTS for each of them. On send completion, this causes an attempt to free the same frame twice that leads to a crash.  Fix crash by allocating separate frames for RHBA and RPA, and modify ABTS logic accordingly.  Tested by checking MDS for FDMI information.  Tested by using instrumented driver to:   - Drop PLOGI response  - Drop RHBA response  - Drop RPA response  - Drop RHBA and RPA response  - Drop PLOGI response + ABTS response  - Drop RHBA response + ABTS response  - Drop RPA response + ABTS response  - Drop RHBA and RPA response + ABTS response for both of them
CVE-2025-38247: In the Linux kernel, the following vulnerability has been resolved:  userns and mnt_idmap leak in open_tree_attr(2)  Once want_mount_setattr() has returned a positive, it does require finish_mount_kattr() to release ->mnt_userns.  Failing do_mount_setattr() does not change that.  As the result, we can end up leaking userns and possibly mnt_idmap as well.
CVE-2025-38253: In the Linux kernel, the following vulnerability has been resolved:  HID: wacom: fix crash in wacom_aes_battery_handler()  Commit fd2a9b29dc9c ("HID: wacom: Remove AES power_supply after extended inactivity") introduced wacom_aes_battery_handler() which is scheduled as a delayed work (aes_battery_work).  In wacom_remove(), aes_battery_work is not canceled. Consequently, if the device is removed while aes_battery_work is still pending, then hard crashes or "Oops: general protection fault..." are experienced when wacom_aes_battery_handler() is finally called. E.g., this happens with built-in USB devices after resume from hibernate when aes_battery_work was still pending at the time of hibernation.  So, take care to cancel aes_battery_work in wacom_remove().
CVE-2025-38254: In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add sanity checks for drm_edid_raw()  When EDID is retrieved via drm_edid_raw(), it doesn't guarantee to return proper EDID bytes the caller wants: it may be either NULL (that leads to an Oops) or with too long bytes over the fixed size raw_edid array (that may lead to memory corruption).  The latter was reported actually when connected with a bad adapter.  Add sanity checks for drm_edid_raw() to address the above corner cases, and return EDID_BAD_INPUT accordingly.  (cherry picked from commit 648d3f4d209725d51900d6a3ed46b7b600140cdf)
CVE-2025-38257: In the Linux kernel, the following vulnerability has been resolved:  s390/pkey: Prevent overflow in size calculation for memdup_user()  Number of apqn target list entries contained in 'nr_apqns' variable is determined by userspace via an ioctl call so the result of the product in calculation of size passed to memdup_user() may overflow.  In this case the actual size of the allocated area and the value describing it won't be in sync leading to various types of unpredictable behaviour later.  Use a proper memdup_array_user() helper which returns an error if an overflow is detected. Note that it is different from when nr_apqns is initially zero - that case is considered valid and should be handled in subsequent pkey_handler implementations.  Found by Linux Verification Center (linuxtesting.org).
CVE-2025-38273: In the Linux kernel, the following vulnerability has been resolved:  net: tipc: fix refcount warning in tipc_aead_encrypt  syzbot reported a refcount warning [1] caused by calling get_net() on a network namespace that is being destroyed (refcount=0). This happens when a TIPC discovery timer fires during network namespace cleanup.  The recently added get_net() call in commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done") attempts to hold a reference to the network namespace. However, if the namespace is already being destroyed, its refcount might be zero, leading to the use-after-free warning.  Replace get_net() with maybe_get_net(), which safely checks if the refcount is non-zero before incrementing it. If the namespace is being destroyed, return -ENODEV early, after releasing the bearer reference.  [1]: https://lore.kernel.org/all/68342b55.a70a0220.253bc2.0091.GAE@google.com/T/#m12019cf9ae77e1954f666914640efa36d52704a2
CVE-2025-38283: In the Linux kernel, the following vulnerability has been resolved:  hisi_acc_vfio_pci: bugfix live migration function without VF device driver  If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors.  Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed.
CVE-2025-38293: In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: fix node corruption in ar->arvifs list  In current WLAN recovery code flow, ath11k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node.  When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath11k_mac_op_remove_interface(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic.  The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath11k_mac_op_remove_interface() can execute normally.  Call trace: __list_del_entry_valid_or_report+0xb8/0xd0 ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k] drv_remove_interface+0x48/0x194 [mac80211] ieee80211_do_stop+0x6e0/0x844 [mac80211] ieee80211_stop+0x44/0x17c [mac80211] __dev_close_many+0xac/0x150 __dev_change_flags+0x194/0x234 dev_change_flags+0x24/0x6c devinet_ioctl+0x3a0/0x670 inet_ioctl+0x200/0x248 sock_do_ioctl+0x60/0x118 sock_ioctl+0x274/0x35c __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x48/0x114 ...  Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
CVE-2025-38303: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: eir: Fix possible crashes on eir_create_adv_data  eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit.