{"schema_version":"1.7.2","id":"OESA-2025-1446","modified":"2025-04-25T14:04:59Z","published":"2025-04-25T14:04:59Z","upstream":["CVE-2023-53034","CVE-2024-52559","CVE-2024-52560","CVE-2024-53162","CVE-2024-53179","CVE-2024-54458","CVE-2024-55881","CVE-2024-56616","CVE-2024-56664","CVE-2024-56710","CVE-2024-57795","CVE-2024-57857","CVE-2024-57908","CVE-2024-57911","CVE-2024-57912","CVE-2024-57929","CVE-2024-57952","CVE-2024-57996","CVE-2024-57999","CVE-2024-58002","CVE-2024-58003","CVE-2024-58007","CVE-2024-58009","CVE-2024-58011","CVE-2024-58013","CVE-2024-58014","CVE-2024-58016","CVE-2024-58017","CVE-2024-58076","CVE-2024-58079","CVE-2024-58083","CVE-2024-58086","CVE-2024-58088","CVE-2024-58090","CVE-2025-21636","CVE-2025-21637","CVE-2025-21638","CVE-2025-21640","CVE-2025-21665","CVE-2025-21666","CVE-2025-21669","CVE-2025-21675","CVE-2025-21690","CVE-2025-21692","CVE-2025-21697","CVE-2025-21700","CVE-2025-21701","CVE-2025-21709","CVE-2025-21712","CVE-2025-21721","CVE-2025-21735","CVE-2025-21739","CVE-2025-21741","CVE-2025-21742","CVE-2025-21744","CVE-2025-21746","CVE-2025-21748","CVE-2025-21749","CVE-2025-21753","CVE-2025-21758","CVE-2025-21759","CVE-2025-21760","CVE-2025-21761","CVE-2025-21762","CVE-2025-21763","CVE-2025-21764","CVE-2025-21765","CVE-2025-21766","CVE-2025-21772","CVE-2025-21773","CVE-2025-21775","CVE-2025-21779","CVE-2025-21780","CVE-2025-21781","CVE-2025-21784","CVE-2025-21790","CVE-2025-21792","CVE-2025-21793","CVE-2025-21821","CVE-2025-21826","CVE-2025-21830","CVE-2025-21831","CVE-2025-21835","CVE-2025-21836","CVE-2025-21838","CVE-2025-21847","CVE-2025-21848","CVE-2025-21855","CVE-2025-21857","CVE-2025-21858","CVE-2025-21859","CVE-2025-21862","CVE-2025-21866","CVE-2025-21867","CVE-2025-21870","CVE-2025-21871","CVE-2025-21873","CVE-2025-21877","CVE-2025-21878","CVE-2025-21881","CVE-2025-21883","CVE-2025-21885","CVE-2025-21888","CVE-2025-21892","CVE-2025-21895","CVE-2025-21898","CVE-2025-21899","CVE-2025-21910","CVE-2025-21914","CVE-2025-21923","CVE-2025-21927","CVE-2025-21928","CVE-2025-21935","CVE-2025-21941","CVE-2025-21943","CVE-2025-21946","CVE-2025-21949","CVE-2025-21963","CVE-2025-21964","CVE-2025-21976","CVE-2025-21978","CVE-2025-21993","CVE-2025-21994","CVE-2025-21999","CVE-2025-22008","CVE-2025-22013","CVE-2025-22035","CVE-2025-22038","CVE-2025-22049","CVE-2025-22066","CVE-2025-22120","CVE-2025-23136","CVE-2025-38240"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans\n\nThere is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and\nsize. This would make xlate_pos negative.\n\n[   23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000\n[   23.734158] ================================================================================\n[   23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7\n[   23.734418] shift exponent -1 is negative\n\nEnsuring xlate_pos is a positive or zero before BIT.(CVE-2023-53034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()\n\nThe \u0026quot;submit-\u0026gt;cmd[i].size\u0026quot; and \u0026quot;submit-\u0026gt;cmd[i].offset\u0026quot; variables are u32\nvalues that come from the user via the submit_lookup_cmds() function.\nThis addition could lead to an integer wrapping bug so use size_add()\nto prevent that.\n\nPatchwork: https://patchwork.freedesktop.org/patch/624696/(CVE-2024-52559)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr()\n\nExtended the `mi_enum_attr()` function interface with an additional\nparameter, `struct ntfs_inode *ni`, to allow marking the inode\nas bad as soon as an error is detected.(CVE-2024-52560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat/qat_4xxx - fix off by one in uof_get_name()\n\nThe fw_objs[] array has \u0026quot;num_objs\u0026quot; elements so the \u0026gt; needs to be \u0026gt;= to\nprevent an out of bounds read.(CVE-2024-53162)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free of signing key\n\nCustomers have reported use-after-free in @ses-\u0026gt;auth_key.response with\nSMB2.1 + sign mounts which occurs due to following race:\n\ntask A                         task B\ncifs_mount()\n dfs_mount_share()\n  get_session()\n   cifs_mount_get_session()    cifs_send_recv()\n    cifs_get_smb_ses()          compound_send_recv()\n     cifs_setup_session()        smb2_setup_request()\n      kfree_sensitive()           smb2_calc_signature()\n                                   crypto_shash_setkey() *UAF*\n\nFix this by ensuring that we have a valid @ses-\u0026gt;auth_key.response by\nchecking whether @ses-\u0026gt;ses_status is SES_GOOD or SES_EXITING with\n@ses-\u0026gt;ses_lock held.  After commit 24a9799aa8ef (\u0026quot;smb: client: fix UAF\nin smb2_reconnect_server()\u0026quot;), we made sure to call -\u0026gt;logoff() only\nwhen @ses was known to be good (e.g. valid -\u0026gt;auth_key.response), so\nit\u0026apos;s safe to access signing key when @ses-\u0026gt;ses_status == SES_EXITING.(CVE-2024-53179)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: bsg: Set bsg_queue to NULL after removal\n\nCurrently, this does not cause any issues, but I believe it is necessary to\nset bsg_queue to NULL after removing it to prevent potential use-after-free\n(UAF) access.(CVE-2024-54458)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Play nice with protected guests in complete_hypercall_exit()\n\nUse is_64_bit_hypercall() instead of is_64_bit_mode() to detect a 64-bit\nhypercall when completing said hypercall.  For guests with protected state,\ne.g. SEV-ES and SEV-SNP, KVM must assume the hypercall was made in 64-bit\nmode as the vCPU state needed to detect 64-bit mode is unavailable.\n\nHacking the sev_smoke_test selftest to generate a KVM_HC_MAP_GPA_RANGE\nhypercall via VMGEXIT trips the WARN:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 273 PID: 326626 at arch/x86/kvm/x86.h:180 complete_hypercall_exit+0x44/0xe0 [kvm]\n  Modules linked in: kvm_amd kvm ... [last unloaded: kvm]\n  CPU: 273 UID: 0 PID: 326626 Comm: sev_smoke_test Not tainted 6.12.0-smp--392e932fa0f3-feat #470\n  Hardware name: Google Astoria/astoria, BIOS 0.20240617.0-0 06/17/2024\n  RIP: 0010:complete_hypercall_exit+0x44/0xe0 [kvm]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   kvm_arch_vcpu_ioctl_run+0x2400/0x2720 [kvm]\n   kvm_vcpu_ioctl+0x54f/0x630 [kvm]\n   __se_sys_ioctl+0x6b/0xc0\n   do_syscall_64+0x83/0x160\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   \u0026lt;/TASK\u0026gt;\n  ---[ end trace 0000000000000000 ]---(CVE-2024-55881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp_mst: Fix MST sideband message body length check\n\nFix the MST sideband message body length check, which must be at least 1\nbyte accounting for the message body CRC (aka message data CRC) at the\nend of the message.\n\nThis fixes a case where an MST branch device returns a header with a\ncorrect header CRC (indicating a correctly received body length), with\nthe body length being incorrectly set to 0. This will later lead to a\nmemory corruption in drm_dp_sideband_append_payload() and the following\nerrors in dmesg:\n\n   UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25\n   index -1 is out of range for type \u0026apos;u8 [48]\u0026apos;\n   Call Trace:\n    drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper]\n    drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]\n    drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]\n\n   memcpy: detected field-spanning write (size 18446744073709551615) of single field \u0026quot;\u0026amp;msg-\u0026gt;msg[msg-\u0026gt;curlen]\u0026quot; at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256)\n   Call Trace:\n    drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper]\n    drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]\n    drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper](CVE-2024-56616)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix race between element replace and close()\n\nElement replace (with a socket different from the one stored) may race\nwith socket\u0026apos;s close() link popping \u0026amp; unlinking. __sock_map_delete()\nunconditionally unrefs the (wrong) element:\n\n// set map[0] = s0\nmap_update_elem(map, 0, s0)\n\n// drop fd of s0\nclose(s0)\n  sock_map_close()\n    lock_sock(sk)               (s0!)\n    sock_map_remove_links(sk)\n      link = sk_psock_link_pop()\n      sock_map_unlink(sk, link)\n        sock_map_delete_from_link\n                                        // replace map[0] with s1\n                                        map_update_elem(map, 0, s1)\n                                          sock_map_update_elem\n                                (s1!)       lock_sock(sk)\n                                            sock_map_update_common\n                                              psock = sk_psock(sk)\n                                              spin_lock(\u0026amp;stab-\u0026gt;lock)\n                                              osk = stab-\u0026gt;sks[idx]\n                                              sock_map_add_link(..., \u0026amp;stab-\u0026gt;sks[idx])\n                                              sock_map_unref(osk, \u0026amp;stab-\u0026gt;sks[idx])\n                                                psock = sk_psock(osk)\n                                                sk_psock_put(sk, psock)\n                                                  if (refcount_dec_and_test(\u0026amp;psock))\n                                                    sk_psock_drop(sk, psock)\n                                              spin_unlock(\u0026amp;stab-\u0026gt;lock)\n                                            unlock_sock(sk)\n          __sock_map_delete\n            spin_lock(\u0026amp;stab-\u0026gt;lock)\n            sk = *psk                        // s1 replaced s0; sk == s1\n            if (!sk_test || sk_test == sk)   // sk_test (s0) != sk (s1); no branch\n              sk = xchg(psk, NULL)\n            if (sk)\n              sock_map_unref(sk, psk)        // unref s1; sks[idx] will dangle\n                psock = sk_psock(sk)\n                sk_psock_put(sk, psock)\n                  if (refcount_dec_and_test())\n                    sk_psock_drop(sk, psock)\n            spin_unlock(\u0026amp;stab-\u0026gt;lock)\n    release_sock(sk)\n\nThen close(map) enqueues bpf_map_free_deferred, which finally calls\nsock_map_free(). This results in some refcount_t warnings along with\na KASAN splat [1].\n\nFix __sock_map_delete(), do not allow sock_map_unref() on elements that\nmay have been replaced.\n\n[1]:\nBUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330\nWrite of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063\n\nCPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\nWorkqueue: events_unbound bpf_map_free_deferred\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x68/0x90\n print_report+0x174/0x4f6\n kasan_report+0xb9/0x190\n kasan_check_range+0x10f/0x1e0\n sock_map_free+0x10e/0x330\n bpf_map_free_deferred+0x173/0x320\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 1202:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n __kasan_slab_alloc+0x85/0x90\n kmem_cache_alloc_noprof+0x131/0x450\n sk_prot_alloc+0x5b/0x220\n sk_alloc+0x2c/0x870\n unix_create1+0x88/0x8a0\n unix_create+0xc5/0x180\n __sock_create+0x241/0x650\n __sys_socketpair+0x1ce/0x420\n __x64_sys_socketpair+0x92/0x100\n do_syscall_64+0x93/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 46:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x37/0x60\n __kasan_slab_free+0x4b/0x70\n kmem_cache_free+0x1a1/0x590\n __sk_destruct+0x388/0x5a0\n sk_psock_destroy+0x73e/0xa50\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n\nThe bu\n---truncated---(CVE-2024-56664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix memory leak in ceph_direct_read_write()\n\nThe bvecs array which is allocated in iter_get_bvecs_alloc() is leaked\nand pages remain pinned if ceph_alloc_sparse_ext_map() fails.\n\nThere is no need to delay the allocation of sparse_ext map until after\nthe bvecs array is set up, so fix this by moving sparse_ext allocation\na bit earlier.  Also, make a similar adjustment in __ceph_sync_read()\nfor consistency (a leak of the same kind in __ceph_sync_read() has been\naddressed differently).(CVE-2024-56710)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Remove the direct link to net_device\n\nThe similar patch in siw is in the link:\nhttps://git.kernel.org/rdma/rdma/c/16b87037b48889\n\nThis problem also occurred in RXE. The following analyze this problem.\nIn the following Call Traces:\n\u0026quot;\nBUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782\nRead of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295\n\nCPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted\n6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0\nHardware name: Google Compute Engine/Google Compute Engine,\nBIOS Google 09/13/2024\nWorkqueue: infiniband ib_cache_event_task\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n dev_get_flags+0x188/0x1d0 net/core/dev.c:8782\n rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60\n __ib_query_port drivers/infiniband/core/device.c:2111 [inline]\n ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143\n ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494\n ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310\n worker_thread+0x870/0xd30 kernel/workqueue.c:3391\n kthread+0x2f2/0x390 kernel/kthread.c:389\n ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\n\u0026quot;\n\n1). In the link [1],\n\n\u0026quot;\n infiniband syz2: set down\n\u0026quot;\n\nThis means that on 839.350575, the event ib_cache_event_task was sent andi\nqueued in ib_wq.\n\n2). In the link [1],\n\n\u0026quot;\n team0 (unregistering): Port device team_slave_0 removed\n\u0026quot;\n\nIt indicates that before 843.251853, the net device should be freed.\n\n3). In the link [1],\n\n\u0026quot;\n BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0\n\u0026quot;\n\nThis means that on 850.559070, this slab-use-after-free problem occurred.\n\nIn all, on 839.350575, the event ib_cache_event_task was sent and queued\nin ib_wq,\n\nbefore 843.251853, the net device veth was freed.\n\non 850.559070, this event was executed, and the mentioned freed net device\nwas called. Thus, the above call trace occurred.\n\n[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000(CVE-2024-57795)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: Remove direct link to net_device\n\nDo not manage a per device direct link to net_device. Rely\non associated ib_devices net_device management, not doubling\nthe effort locally. A badly managed local link to net_device\nwas causing a \u0026apos;KASAN: slab-use-after-free\u0026apos; exception during\nsiw_query_port() call.(CVE-2024-57857)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: kmx61: fix information leak in triggered buffer\n\nThe \u0026apos;buffer\u0026apos; local array is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the array to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57908)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; array is allocated via kmalloc() and it is used to push data\nto user space from a triggered buffer, but it does not set values for\ninactive channels, as it only uses iio_for_each_active_channel()\nto assign new values.\n\nUse kzalloc for the memory allocation to avoid pushing uninitialized\ninformation to userspace.(CVE-2024-57911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: pressure: zpa2326: fix information leak in triggered buffer\n\nThe \u0026apos;sample\u0026apos; local struct is used to push data to user space from a\ntriggered buffer, but it has a hole between the temperature and the\ntimestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).\nThis hole is never initialized.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm array: fix releasing a faulty array block twice in dm_array_cursor_end\n\nWhen dm_bm_read_lock() fails due to locking or checksum errors, it\nreleases the faulty block implicitly while leaving an invalid output\npointer behind. The caller of dm_bm_read_lock() should not operate on\nthis invalid dm_block pointer, or it will lead to undefined result.\nFor example, the dm_array_cursor incorrectly caches the invalid pointer\non reading a faulty array block, causing a double release in\ndm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().\n\nReproduce steps:\n\n1. initialize a cache device\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc $262144\u0026quot;\ndd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\n2. wipe the second array block offline\n\ndmsteup remove cache cmeta cdata corig\nmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \\\n2\u0026gt;/dev/null | hexdump -e \u0026apos;1/8 \u0026quot;%u\\n\u0026quot;\u0026apos;)\nablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \\\n2\u0026gt;/dev/null | hexdump -e \u0026apos;1/8 \u0026quot;%u\\n\u0026quot;\u0026apos;)\ndd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock\n\n3. try reopen the cache device\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc $262144\u0026quot;\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\nKernel logs:\n\n(snip)\ndevice-mapper: array: array_block_check failed: blocknr 0 != wanted 10\ndevice-mapper: block manager: array validator check failed for block 10\ndevice-mapper: array: get_ablock failed\ndevice-mapper: cache metadata: dm_array_cursor_next for mapping failed\n------------[ cut here ]------------\nkernel BUG at drivers/md/dm-bufio.c:638!\n\nFix by setting the cached block pointer to NULL on errors.\n\nIn addition to the reproducer described above, this fix can be\nverified using the \u0026quot;array_cursor/damaged\u0026quot; test in dm-unit:\n  dm-unit run /pdata/array_cursor/damaged --kernel-dir \u0026lt;KERNEL_DIR\u0026gt;(CVE-2024-57929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert \u0026quot;libfs: fix infinite directory reads for offset dir\u0026quot;\n\nThe current directory offset allocator (based on mtree_alloc_cyclic)\nstores the next offset value to return in octx-\u0026gt;next_offset. This\nmechanism typically returns values that increase monotonically over\ntime. Eventually, though, the newly allocated offset value wraps\nback to a low number (say, 2) which is smaller than other already-\nallocated offset values.\n\nYu Kuai \u0026lt;yukuai3@huawei.com\u0026gt; reports that, after commit 64a7ce76fb90\n(\u0026quot;libfs: fix infinite directory reads for offset dir\u0026quot;), if a\ndirectory\u0026apos;s offset allocator wraps, existing entries are no longer\nvisible via readdir/getdents because offset_readdir() stops listing\nentries once an entry\u0026apos;s offset is larger than octx-\u0026gt;next_offset.\nThese entries vanish persistently -- they can be looked up, but will\nnever again appear in readdir(3) output.\n\nThe reason for this is that the commit treats directory offsets as\nmonotonically increasing integer values rather than opaque cookies,\nand introduces this comparison:\n\n\tif (dentry2offset(dentry) \u0026gt;= last_index) {\n\nOn 64-bit platforms, the directory offset value upper bound is\n2^63 - 1. Directory offsets will monotonically increase for millions\nof years without wrapping.\n\nOn 32-bit platforms, however, LONG_MAX is 2^31 - 1. The allocator\ncan wrap after only a few weeks (at worst).\n\nRevert commit 64a7ce76fb90 (\u0026quot;libfs: fix infinite directory reads for\noffset dir\u0026quot;) to prepare for a fix that can work properly on 32-bit\nsystems and might apply to recent LTS kernels where shmem employs\nthe simple_offset mechanism.(CVE-2024-57952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: don\u0026apos;t allow 1 packet limit\n\nThe current implementation does not work correctly with a limit of\n1. iproute2 actually checks for this and this patch adds the check in\nkernel as well.\n\nThis fixes the following syzkaller reported crash:\n\nUBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6\nindex 65535 is out of range for type \u0026apos;struct sfq_head[128]\u0026apos;\nCPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n  __dump_stack lib/dump_stack.c:79 [inline]\n  dump_stack+0x125/0x19f lib/dump_stack.c:120\n  ubsan_epilogue lib/ubsan.c:148 [inline]\n  __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347\n  sfq_link net/sched/sch_sfq.c:210 [inline]\n  sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238\n  sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500\n  sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525\n  qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026\n  tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319\n  qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026\n  dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296\n  netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline]\n  dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362\n  __dev_close_many+0x214/0x350 net/core/dev.c:1468\n  dev_close_many+0x207/0x510 net/core/dev.c:1506\n  unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738\n  unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695\n  unregister_netdevice include/linux/netdevice.h:2893 [inline]\n  __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689\n  tun_detach drivers/net/tun.c:705 [inline]\n  tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640\n  __fput+0x203/0x840 fs/file_table.c:280\n  task_work_run+0x129/0x1b0 kernel/task_work.c:185\n  exit_task_work include/linux/task_work.h:33 [inline]\n  do_exit+0x5ce/0x2200 kernel/exit.c:931\n  do_group_exit+0x144/0x310 kernel/exit.c:1046\n  __do_sys_exit_group kernel/exit.c:1057 [inline]\n  __se_sys_exit_group kernel/exit.c:1055 [inline]\n  __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055\n do_syscall_64+0x6c/0xd0\n entry_SYSCALL_64_after_hwframe+0x61/0xcb\nRIP: 0033:0x7fe5e7b52479\nCode: Unable to access opcode bytes at RIP 0x7fe5e7b5244f.\nRSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479\nRDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000\nRBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0\nR13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270\n\nThe crash can be also be reproduced with the following (with a tc\nrecompiled to allow for sfq limits of 1):\n\ntc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s\n../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1\nifconfig dummy0 up\nping -I dummy0 -f -c2 -W0.1 8.8.8.8\nsleep 1\n\nScenario that triggers the crash:\n\n* the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1\n\n* TBF dequeues: it peeks from SFQ which moves the packet to the\n  gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so\n  it schedules itself for later.\n\n* the second packet is sent and TBF tries to queues it to SFQ. qdisc\n  qlen is now 2 and because the SFQ limit is 1 the packet is dropped\n  by SFQ. At this point qlen is 1, and all of the SFQ slots are empty,\n  however q-\u0026gt;tail is not NULL.\n\nAt this point, assuming no more packets are queued, when sch_dequeue\nruns again it will decrement the qlen for the current empty slot\ncausing an underflow and the subsequent out of bounds access.(CVE-2024-57996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW\n\nPower Hypervisor can possibily allocate MMIO window intersecting with\nDynamic DMA Window (DDW) range, which is over 32-bit addressing.\n\nThese MMIO pages needs to be marked as reserved so that IOMMU doesn\u0026apos;t map\nDMA buffers in this range.\n\nThe current code is not marking these pages correctly which is resulting\nin LPAR to OOPS while booting. The stack is at below\n\nBUG: Unable to handle kernel data access on read at 0xc00800005cd40000\nFaulting instruction address: 0xc00000000005cdac\nOops: Kernel access of bad area, sig: 11 [#1]\nLE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries\nModules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod\nSupported: Yes, External\nCPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b\nHardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries\nWorkqueue: events work_for_cpu_fn\nNIP:  c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000\nREGS: c00001400c9ff770 TRAP: 0300   Not tainted  (6.4.0-150600.23.14-default)\nMSR:  800000000280b033 \u0026lt;SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE\u0026gt;  CR: 24228448  XER: 00000001\nCFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0\nGPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800\nGPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000\nGPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff\nGPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000\nGPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800\nGPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b\nGPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8\nGPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800\nNIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100\nLR [c00000000005e830] iommu_init_table+0x80/0x1e0\nCall Trace:\n[c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable)\n[c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40\n[c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230\n[c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90\n[c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80\n[c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net]\n[c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110\n[c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60\n[c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620\n[c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620\n[c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150\n[c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18\n\nThere are 2 issues in the code\n\n1. The index is \u0026quot;int\u0026quot; while the address is \u0026quot;unsigned long\u0026quot;. This results in\n   negative value when setting the bitmap.\n\n2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit\n   address). MMIO address needs to be page shifted as well.(CVE-2024-57999)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Remove dangling pointers\n\nWhen an async control is written, we copy a pointer to the file handle\nthat started the operation. That pointer will be used when the device is\ndone. Which could be anytime in the future.\n\nIf the user closes that file descriptor, its structure will be freed,\nand there will be one dangling pointer per pending async control, that\nthe driver will try to use.\n\nClean all the dangling pointers during release().\n\nTo avoid adding a performance penalty in the most common case (no async\noperation), a counter has been introduced with some logic to make sure\nthat it is properly handled.(CVE-2024-58002)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: i2c: ds90ub9x3: Fix extra fwnode_handle_put()\n\nThe ub913 and ub953 drivers call fwnode_handle_put(priv-\u0026gt;sd.fwnode) as\npart of their remove process, and if the driver is removed multiple\ntimes, eventually leads to put \u0026quot;overflow\u0026quot;, possibly causing memory\ncorruption or crash.\n\nThe fwnode_handle_put() is a leftover from commit 905f88ccebb1 (\u0026quot;media:\ni2c: ds90ub9x3: Fix sub-device matching\u0026quot;), which changed the code\nrelated to the sd.fwnode, but missed removing these fwnode_handle_put()\ncalls.(CVE-2024-58003)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: socinfo: Avoid out of bounds read of serial number\n\nOn MSM8916 devices, the serial number exposed in sysfs is constant and does\nnot change across individual devices. It\u0026apos;s always:\n\n  db410c:/sys/devices/soc0$ cat serial_number\n  2644893864\n\nThe firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not\nhave support for the serial_num field in the socinfo struct. There is an\nexisting check to avoid exposing the serial number in that case, but it\u0026apos;s\nnot correct: When checking the item_size returned by SMEM, we need to make\nsure the *end* of the serial_num is within bounds, instead of comparing\nwith the *start* offset. The serial_number currently exposed on MSM8916\ndevices is just an out of bounds read of whatever comes after the socinfo\nstruct in SMEM.\n\nFix this by changing offsetof() to offsetofend(), so that the size of the\nfield is also taken into account.(CVE-2024-58007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc\n\nA NULL sock pointer is passed into l2cap_sock_alloc() when it is called\nfrom l2cap_sock_new_connection_cb() and the error handling paths should\nalso be aware of it.\n\nSeemingly a more elegant solution would be to swap bt_sock_alloc() and\nl2cap_chan_create() calls since they are not interdependent to that moment\nbut then l2cap_chan_create() adds the soon to be deallocated and still\ndummy-initialized channel to the global list accessible by many L2CAP\npaths. The channel would be removed from the list in short period of time\nbut be a bit more straight-forward here and just check for NULL instead of\nchanging the order of function calls.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE static\nanalysis tool.(CVE-2024-58009)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: int3472: Check for adev == NULL\n\nNot all devices have an ACPI companion fwnode, so adev might be NULL. This\ncan e.g. (theoretically) happen when a user manually binds one of\nthe int3472 drivers to another i2c/platform device through sysfs.\n\nAdd a check for adev not being set and return -ENODEV in that case to\navoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer().(CVE-2024-58011)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix slab-use-after-free Read in mgmt_remove_adv_monitor_sync\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543\nRead of size 8 at addr ffff88814128f898 by task kworker/u9:4/5961\n\nCPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted 6.12.0-syzkaller-10684-gf1cd565ce577 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nWorkqueue: hci0 hci_cmd_sync_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543\n hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310\n worker_thread+0x870/0xd30 kernel/workqueue.c:3391\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 16026:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4314\n kmalloc_noprof include/linux/slab.h:901 [inline]\n kzalloc_noprof include/linux/slab.h:1037 [inline]\n mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269\n mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296\n remove_adv_monitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568\n hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712\n hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832\n sock_sendmsg_nosec net/socket.c:711 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:726\n sock_write_iter+0x2d7/0x3f0 net/socket.c:1147\n new_sync_write fs/read_write.c:586 [inline]\n vfs_write+0xaeb/0xd30 fs/read_write.c:679\n ksys_write+0x18f/0x2b0 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 16022:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582\n poison_slab_object mm/kasan/common.c:247 [inline]\n __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2338 [inline]\n slab_free mm/slub.c:4598 [inline]\n kfree+0x196/0x420 mm/slub.c:4746\n mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259\n __mgmt_power_off+0x183/0x430 net/bluetooth/mgmt.c:9550\n hci_dev_close_sync+0x6c4/0x11c0 net/bluetooth/hci_sync.c:5208\n hci_dev_do_close net/bluetooth/hci_core.c:483 [inline]\n hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508\n sock_do_ioctl+0x158/0x460 net/socket.c:1209\n sock_ioctl+0x626/0x8e0 net/socket.c:1328\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:906 [inline]\n __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-58013)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()\n\nIn \u0026apos;wlc_phy_iqcal_gainparams_nphy()\u0026apos;, add gain range check to WARN()\ninstead of possible out-of-bounds \u0026apos;tbl_iqcal_gainparams_nphy\u0026apos; access.\nCompile tested only.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-58014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsafesetid: check size of policy writes\n\nsyzbot attempts to write a buffer with a large size to a sysfs entry\nwith writes handled by handle_policy_update(), triggering a warning\nin kmalloc.\n\nCheck the size specified for write buffers before allocating.\n\n[PM: subject tweak](CVE-2024-58016)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nprintk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX\n\nShifting 1 \u0026lt;\u0026lt; 31 on a 32-bit int causes signed integer overflow, which\nleads to undefined behavior. To prevent this, cast 1 to u32 before\nperforming the shift, ensuring well-defined behavior.\n\nThis change explicitly avoids any potential overflow by ensuring that\nthe shift occurs on an unsigned 32-bit integer.(CVE-2024-58017)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: gcc-sm6350: Add missing parent_map for two clocks\n\nIf a clk_rcg2 has a parent, it should also have parent_map defined,\notherwise we\u0026apos;ll get a NULL pointer dereference when calling clk_set_rate\nlike the following:\n\n  [    3.388105] Call trace:\n  [    3.390664]  qcom_find_src_index+0x3c/0x70 (P)\n  [    3.395301]  qcom_find_src_index+0x1c/0x70 (L)\n  [    3.399934]  _freq_tbl_determine_rate+0x48/0x100\n  [    3.404753]  clk_rcg2_determine_rate+0x1c/0x28\n  [    3.409387]  clk_core_determine_round_nolock+0x58/0xe4\n  [    3.421414]  clk_core_round_rate_nolock+0x48/0xfc\n  [    3.432974]  clk_core_round_rate_nolock+0xd0/0xfc\n  [    3.444483]  clk_core_set_rate_nolock+0x8c/0x300\n  [    3.455886]  clk_set_rate+0x38/0x14c\n\nAdd the parent_map property for two clocks where it\u0026apos;s missing and also\nun-inline the parent_data as well to keep the matching parent_map and\nparent_data together.(CVE-2024-58076)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Fix crash during unbind if gpio unit is in use\n\nWe used the wrong device for the device managed functions. We used the\nusb device, when we should be using the interface device.\n\nIf we unbind the driver from the usb interface, the cleanup functions\nare never called. In our case, the IRQ is never disabled.\n\nIf an IRQ is triggered, it will try to access memory sections that are\nalready free, causing an OOPS.\n\nWe cannot use the function devm_request_threaded_irq here. The devm_*\nclean functions may be called after the main structure is released by\nuvc_delete.\n\nLuckily this bug has small impact, as it is only affected by devices\nwith gpio units and the user has to unbind the device, a disconnect will\nnot trigger this error.(CVE-2024-58079)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Explicitly verify target vCPU is online in kvm_get_vcpu()\n\nExplicitly verify the target vCPU is fully online _prior_ to clamping the\nindex in kvm_get_vcpu().  If the index is \u0026quot;bad\u0026quot;, the nospec clamping will\ngenerate \u0026apos;0\u0026apos;, i.e. KVM will return vCPU0 instead of NULL.\n\nIn practice, the bug is unlikely to cause problems, as it will only come\ninto play if userspace or the guest is buggy or misbehaving, e.g. KVM may\nsend interrupts to vCPU0 instead of dropping them on the floor.\n\nHowever, returning vCPU0 when it shouldn\u0026apos;t exist per online_vcpus is\nproblematic now that KVM uses an xarray for the vCPUs array, as KVM needs\nto insert into the xarray before publishing the vCPU to userspace (see\ncommit c5b077549136 (\u0026quot;KVM: Convert the kvm-\u0026gt;vcpus array to a xarray\u0026quot;)),\ni.e. before vCPU creation is guaranteed to succeed.\n\nAs a result, incorrectly providing access to vCPU0 will trigger a\nuse-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()\nbails out of vCPU creation due to an error and frees vCPU0.  Commit\nafb2acb2e3a3 (\u0026quot;KVM: Fix vcpu_array[0] races\u0026quot;) papered over that issue, but\nin doing so introduced an unsolvable teardown conundrum.  Preventing\naccesses to vCPU0 before it\u0026apos;s fully online will allow reverting commit\nafb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.(CVE-2024-58083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Stop active perfmon if it is being destroyed\n\nIf the active performance monitor (`v3d-\u0026gt;active_perfmon`) is being\ndestroyed, stop it first. Currently, the active perfmon is not\nstopped during destruction, leaving the `v3d-\u0026gt;active_perfmon` pointer\nstale. This can lead to undefined behavior and instability.\n\nThis patch ensures that the active perfmon is stopped before being\ndestroyed, aligning with the behavior introduced in commit\n7d1fd3638ee3 (\u0026quot;drm/v3d: Stop the active perfmon before being destroyed\u0026quot;).(CVE-2024-58086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix deadlock when freeing cgroup storage\n\nThe following commit\nbc235cdb423a (\u0026quot;bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]\u0026quot;)\nfirst introduced deadlock prevention for fentry/fexit programs attaching\non bpf_task_storage helpers. That commit also employed the logic in map\nfree path in its v6 version.\n\nLater bpf_cgrp_storage was first introduced in\nc4bcfb38a95e (\u0026quot;bpf: Implement cgroup storage available to non-cgroup-attached bpf progs\u0026quot;)\nwhich faces the same issue as bpf_task_storage, instead of its busy\ncounter, NULL was passed to bpf_local_storage_map_free() which opened\na window to cause deadlock:\n\n\t\u0026lt;TASK\u0026gt;\n\t\t(acquiring local_storage-\u0026gt;lock)\n\t_raw_spin_lock_irqsave+0x3d/0x50\n\tbpf_local_storage_update+0xd1/0x460\n\tbpf_cgrp_storage_get+0x109/0x130\n\tbpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170\n\t? __bpf_prog_enter_recur+0x16/0x80\n\tbpf_trampoline_6442485186+0x43/0xa4\n\tcgroup_storage_ptr+0x9/0x20\n\t\t(holding local_storage-\u0026gt;lock)\n\tbpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160\n\tbpf_selem_unlink_storage+0x6f/0x110\n\tbpf_local_storage_map_free+0xa2/0x110\n\tbpf_map_free_deferred+0x5b/0x90\n\tprocess_one_work+0x17c/0x390\n\tworker_thread+0x251/0x360\n\tkthread+0xd2/0x100\n\tret_from_fork+0x34/0x50\n\tret_from_fork_asm+0x1a/0x30\n\t\u0026lt;/TASK\u0026gt;\n\nProgs:\n - A: SEC(\u0026quot;fentry/cgroup_storage_ptr\u0026quot;)\n   - cgid (BPF_MAP_TYPE_HASH)\n\tRecord the id of the cgroup the current task belonging\n\tto in this hash map, using the address of the cgroup\n\tas the map key.\n   - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE)\n\tIf current task is a kworker, lookup the above hash\n\tmap using function parameter @owner as the key to get\n\tits corresponding cgroup id which is then used to get\n\ta trusted pointer to the cgroup through\n\tbpf_cgroup_from_id(). This trusted pointer can then\n\tbe passed to bpf_cgrp_storage_get() to finally trigger\n\tthe deadlock issue.\n - B: SEC(\u0026quot;tp_btf/sys_enter\u0026quot;)\n   - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE)\n\tThe only purpose of this prog is to fill Prog A\u0026apos;s\n\thash map by calling bpf_cgrp_storage_get() for as\n\tmany userspace tasks as possible.\n\nSteps to reproduce:\n - Run A;\n - while (true) { Run B; Destroy B; }\n\nFix this issue by passing its busy counter to the free procedure so\nit can be properly incremented before storage/smap locking.(CVE-2024-58088)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/core: Prevent rescheduling when interrupts are disabled\n\nDavid reported a warning observed while loop testing kexec jump:\n\n  Interrupts enabled after irqrouter_resume+0x0/0x50\n  WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220\n   kernel_kexec+0xf6/0x180\n   __do_sys_reboot+0x206/0x250\n   do_syscall_64+0x95/0x180\n\nThe corresponding interrupt flag trace:\n\n  hardirqs last  enabled at (15573): [\u0026lt;ffffffffa8281b8e\u0026gt;] __up_console_sem+0x7e/0x90\n  hardirqs last disabled at (15580): [\u0026lt;ffffffffa8281b73\u0026gt;] __up_console_sem+0x63/0x90\n\nThat means __up_console_sem() was invoked with interrupts enabled. Further\ninstrumentation revealed that in the interrupt disabled section of kexec\njump one of the syscore_suspend() callbacks woke up a task, which set the\nNEED_RESCHED flag. A later callback in the resume path invoked\ncond_resched() which in turn led to the invocation of the scheduler:\n\n  __cond_resched+0x21/0x60\n  down_timeout+0x18/0x60\n  acpi_os_wait_semaphore+0x4c/0x80\n  acpi_ut_acquire_mutex+0x3d/0x100\n  acpi_ns_get_node+0x27/0x60\n  acpi_ns_evaluate+0x1cb/0x2d0\n  acpi_rs_set_srs_method_data+0x156/0x190\n  acpi_pci_link_set+0x11c/0x290\n  irqrouter_resume+0x54/0x60\n  syscore_resume+0x6a/0x200\n  kernel_kexec+0x145/0x1c0\n  __do_sys_reboot+0xeb/0x240\n  do_syscall_64+0x95/0x180\n\nThis is a long standing problem, which probably got more visible with\nthe recent printk changes. Something does a task wakeup and the\nscheduler sets the NEED_RESCHED flag. cond_resched() sees it set and\ninvokes schedule() from a completely bogus context. The scheduler\nenables interrupts after context switching, which causes the above\nwarning at the end.\n\nQuite some of the code paths in syscore_suspend()/resume() can result in\ntriggering a wakeup with the exactly same consequences. They might not\nhave done so yet, but as they share a lot of code with normal operations\nit\u0026apos;s just a question of time.\n\nThe problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling\nmodels. Full preemption is not affected as cond_resched() is disabled and\nthe preemption check preemptible() takes the interrupt disabled flag into\naccount.\n\nCure the problem by adding a corresponding check into cond_resched().(CVE-2024-58090)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: sysctl: plpmtud_probe_interval: avoid using current-\u0026gt;nsproxy\n\nAs mentioned in a previous commit of this series, using the \u0026apos;net\u0026apos;\nstructure via \u0026apos;current\u0026apos; is not recommended for different reasons:\n\n- Inconsistency: getting info from the reader\u0026apos;s/writer\u0026apos;s netns vs only\n  from the opener\u0026apos;s netns.\n\n- current-\u0026gt;nsproxy can be NULL in some cases, resulting in an \u0026apos;Oops\u0026apos;\n  (null-ptr-deref), e.g. when the current task is exiting, as spotted by\n  syzbot [1] using acct(2).\n\nThe \u0026apos;net\u0026apos; structure can be obtained from the table-\u0026gt;data using\ncontainer_of().\n\nNote that table-\u0026gt;data could also be used directly, as this is the only\nmember needed from the \u0026apos;net\u0026apos; structure, but that would increase the size\nof this fix, to use \u0026apos;*data\u0026apos; everywhere \u0026apos;net-\u0026gt;sctp.probe_interval\u0026apos; is\nused.(CVE-2025-21636)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: sysctl: udp_port: avoid using current-\u0026gt;nsproxy\n\nAs mentioned in a previous commit of this series, using the \u0026apos;net\u0026apos;\nstructure via \u0026apos;current\u0026apos; is not recommended for different reasons:\n\n- Inconsistency: getting info from the reader\u0026apos;s/writer\u0026apos;s netns vs only\n  from the opener\u0026apos;s netns.\n\n- current-\u0026gt;nsproxy can be NULL in some cases, resulting in an \u0026apos;Oops\u0026apos;\n  (null-ptr-deref), e.g. when the current task is exiting, as spotted by\n  syzbot [1] using acct(2).\n\nThe \u0026apos;net\u0026apos; structure can be obtained from the table-\u0026gt;data using\ncontainer_of().\n\nNote that table-\u0026gt;data could also be used directly, but that would\nincrease the size of this fix, while \u0026apos;sctp.ctl_sock\u0026apos; still needs to be\nretrieved from \u0026apos;net\u0026apos; structure.(CVE-2025-21637)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: sysctl: auth_enable: avoid using current-\u0026gt;nsproxy\n\nAs mentioned in a previous commit of this series, using the \u0026apos;net\u0026apos;\nstructure via \u0026apos;current\u0026apos; is not recommended for different reasons:\n\n- Inconsistency: getting info from the reader\u0026apos;s/writer\u0026apos;s netns vs only\n  from the opener\u0026apos;s netns.\n\n- current-\u0026gt;nsproxy can be NULL in some cases, resulting in an \u0026apos;Oops\u0026apos;\n  (null-ptr-deref), e.g. when the current task is exiting, as spotted by\n  syzbot [1] using acct(2).\n\nThe \u0026apos;net\u0026apos; structure can be obtained from the table-\u0026gt;data using\ncontainer_of().\n\nNote that table-\u0026gt;data could also be used directly, but that would\nincrease the size of this fix, while \u0026apos;sctp.ctl_sock\u0026apos; still needs to be\nretrieved from \u0026apos;net\u0026apos; structure.(CVE-2025-21638)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: sysctl: cookie_hmac_alg: avoid using current-\u0026gt;nsproxy\n\nAs mentioned in a previous commit of this series, using the \u0026apos;net\u0026apos;\nstructure via \u0026apos;current\u0026apos; is not recommended for different reasons:\n\n- Inconsistency: getting info from the reader\u0026apos;s/writer\u0026apos;s netns vs only\n  from the opener\u0026apos;s netns.\n\n- current-\u0026gt;nsproxy can be NULL in some cases, resulting in an \u0026apos;Oops\u0026apos;\n  (null-ptr-deref), e.g. when the current task is exiting, as spotted by\n  syzbot [1] using acct(2).\n\nThe \u0026apos;net\u0026apos; structure can be obtained from the table-\u0026gt;data using\ncontainer_of().\n\nNote that table-\u0026gt;data could also be used directly, as this is the only\nmember needed from the \u0026apos;net\u0026apos; structure, but that would increase the size\nof this fix, to use \u0026apos;*data\u0026apos; everywhere \u0026apos;net-\u0026gt;sctp.sctp_hmac_alg\u0026apos; is\nused.(CVE-2025-21640)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfilemap: avoid truncating 64-bit offset to 32 bits\n\nOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a\n64-bit value to 32 bits, leading to a possible infinite loop when writing\nto an xfs filesystem.(CVE-2025-21665)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: prevent null-ptr-deref in vsock_*[has_data|has_space]\n\nRecent reports have shown how we sometimes call vsock_*_has_data()\nwhen a vsock socket has been de-assigned from a transport (see attached\nlinks), but we shouldn\u0026apos;t.\n\nPrevious commits should have solved the real problems, but we may have\nmore in the future, so to avoid null-ptr-deref, we can return 0\n(no space, no data available) but with a warning.\n\nThis way the code should continue to run in a nearly consistent state\nand have a warning that allows us to debug future problems.(CVE-2025-21666)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock/virtio: discard packets if the transport changes\n\nIf the socket has been de-assigned or assigned to another transport,\nwe must discard any packets received because they are not expected\nand would cause issues when we access vsk-\u0026gt;transport.\n\nA possible scenario is described by Hyunwoo Kim in the attached link,\nwhere after a first connect() interrupted by a signal, and a second\nconnect() failed, we can find `vsk-\u0026gt;transport` at NULL, leading to a\nNULL pointer dereference.(CVE-2025-21669)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Clear port select structure when fail to create\n\nClear the port select structure on error so no stale values left after\ndefiners are destroyed. That\u0026apos;s because the mlx5_lag_destroy_definers()\nalways try to destroy all lag definers in the tt_map, so in the flow\nbelow lag definers get double-destroyed and cause kernel crash:\n\n  mlx5_lag_port_sel_create()\n    mlx5_lag_create_definers()\n      mlx5_lag_create_definer()     \u0026lt;- Failed on tt 1\n        mlx5_lag_destroy_definers() \u0026lt;- definers[tt=0] gets destroyed\n  mlx5_lag_port_sel_create()\n    mlx5_lag_create_definers()\n      mlx5_lag_create_definer()     \u0026lt;- Failed on tt 0\n        mlx5_lag_destroy_definers() \u0026lt;- definers[tt=0] gets double-destroyed\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008\n Mem abort info:\n   ESR = 0x0000000096000005\n   EC = 0x25: DABT (current EL), IL = 32 bits\n   SET = 0, FnV = 0\n   EA = 0, S1PTW = 0\n   FSC = 0x05: level 1 translation fault\n Data abort info:\n   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\n   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n user pgtable: 64k pages, 48-bit VAs, pgdp=0000000112ce2e00\n [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000\n Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP\n Modules linked in: iptable_raw bonding ip_gre ip6_gre gre ip6_tunnel tunnel6 geneve ip6_udp_tunnel udp_tunnel ipip tunnel4 ip_tunnel rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) mlx5_fwctl(OE) fwctl(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlxfw(OE) memtrack(OE) mlx_compat(OE) openvswitch nsh nf_conncount psample xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc netconsole overlay efi_pstore sch_fq_codel zram ip_tables crct10dif_ce qemu_fw_cfg fuse ipv6 crc_ccitt [last unloaded: mlx_compat(OE)]\n  CPU: 3 UID: 0 PID: 217 Comm: kworker/u53:2 Tainted: G           OE      6.11.0+ #2\n  Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n  Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n  Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core]\n  pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core]\n  lr : mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core]\n  sp : ffff800085fafb00\n  x29: ffff800085fafb00 x28: ffff0000da0c8000 x27: 0000000000000000\n  x26: ffff0000da0c8000 x25: ffff0000da0c8000 x24: ffff0000da0c8000\n  x23: ffff0000c31f81a0 x22: 0400000000000000 x21: ffff0000da0c8000\n  x20: 0000000000000000 x19: 0000000000000001 x18: 0000000000000000\n  x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8b0c9350\n  x14: 0000000000000000 x13: ffff800081390d18 x12: ffff800081dc3cc0\n  x11: 0000000000000001 x10: 0000000000000b10 x9 : ffff80007ab7304c\n  x8 : ffff0000d00711f0 x7 : 0000000000000004 x6 : 0000000000000190\n  x5 : ffff00027edb3010 x4 : 0000000000000000 x3 : 0000000000000000\n  x2 : ffff0000d39b8000 x1 : ffff0000d39b8000 x0 : 0400000000000000\n  Call trace:\n   mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core]\n   mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core]\n   mlx5_lag_destroy_definers+0xa0/0x108 [mlx5_core]\n   mlx5_lag_port_sel_create+0x2d4/0x6f8 [mlx5_core]\n   mlx5_activate_lag+0x60c/0x6f8 [mlx5_core]\n   mlx5_do_bond_work+0x284/0x5c8 [mlx5_core]\n   process_one_work+0x170/0x3e0\n   worker_thread+0x2d8/0x3e0\n   kthread+0x11c/0x128\n   ret_from_fork+0x10/0x20\n  Code: a9025bf5 aa0003f6 a90363f7 f90023f9 (f9400400)\n  ---[ end trace 0000000000000000 ]---(CVE-2025-21675)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: storvsc: Ratelimit warning logs to prevent VM denial of service\n\nIf there\u0026apos;s a persistent error in the hypervisor, the SCSI warning for\nfailed I/O can flood the kernel log and max out CPU utilization,\npreventing troubleshooting from the VM side. Ratelimit the warning so\nit doesn\u0026apos;t DoS the VM.(CVE-2025-21690)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: fix ets qdisc OOB Indexing\n\nHaowei Yan \u0026lt;g1042620637@gmail.com\u0026gt; found that ets_class_from_arg() can\nindex an Out-Of-Bound class in ets_class_from_arg() when passed clid of\n0. The overflow may cause local privilege escalation.\n\n [   18.852298] ------------[ cut here ]------------\n [   18.853271] UBSAN: array-index-out-of-bounds in net/sched/sch_ets.c:93:20\n [   18.853743] index 18446744073709551615 is out of range for type \u0026apos;ets_class [16]\u0026apos;\n [   18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17\n [   18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n [   18.856532] Call Trace:\n [   18.857441]  \u0026lt;TASK\u0026gt;\n [   18.858227]  dump_stack_lvl+0xc2/0xf0\n [   18.859607]  dump_stack+0x10/0x20\n [   18.860908]  __ubsan_handle_out_of_bounds+0xa7/0xf0\n [   18.864022]  ets_class_change+0x3d6/0x3f0\n [   18.864322]  tc_ctl_tclass+0x251/0x910\n [   18.864587]  ? lock_acquire+0x5e/0x140\n [   18.865113]  ? __mutex_lock+0x9c/0xe70\n [   18.866009]  ? __mutex_lock+0xa34/0xe70\n [   18.866401]  rtnetlink_rcv_msg+0x170/0x6f0\n [   18.866806]  ? __lock_acquire+0x578/0xc10\n [   18.867184]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n [   18.867503]  netlink_rcv_skb+0x59/0x110\n [   18.867776]  rtnetlink_rcv+0x15/0x30\n [   18.868159]  netlink_unicast+0x1c3/0x2b0\n [   18.868440]  netlink_sendmsg+0x239/0x4b0\n [   18.868721]  ____sys_sendmsg+0x3e2/0x410\n [   18.869012]  ___sys_sendmsg+0x88/0xe0\n [   18.869276]  ? rseq_ip_fixup+0x198/0x260\n [   18.869563]  ? rseq_update_cpu_node_id+0x10a/0x190\n [   18.869900]  ? trace_hardirqs_off+0x5a/0xd0\n [   18.870196]  ? syscall_exit_to_user_mode+0xcc/0x220\n [   18.870547]  ? do_syscall_64+0x93/0x150\n [   18.870821]  ? __memcg_slab_free_hook+0x69/0x290\n [   18.871157]  __sys_sendmsg+0x69/0xd0\n [   18.871416]  __x64_sys_sendmsg+0x1d/0x30\n [   18.871699]  x64_sys_call+0x9e2/0x2670\n [   18.871979]  do_syscall_64+0x87/0x150\n [   18.873280]  ? do_syscall_64+0x93/0x150\n [   18.874742]  ? lock_release+0x7b/0x160\n [   18.876157]  ? do_user_addr_fault+0x5ce/0x8f0\n [   18.877833]  ? irqentry_exit_to_user_mode+0xc2/0x210\n [   18.879608]  ? irqentry_exit+0x77/0xb0\n [   18.879808]  ? clear_bhb_loop+0x15/0x70\n [   18.880023]  ? clear_bhb_loop+0x15/0x70\n [   18.880223]  ? clear_bhb_loop+0x15/0x70\n [   18.880426]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n [   18.880683] RIP: 0033:0x44a957\n [   18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10\n [   18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n [   18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957\n [   18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003\n [   18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0\n [   18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001\n [   18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001\n [   18.888395]  \u0026lt;/TASK\u0026gt;\n [   18.888610] ---[ end trace ]---(CVE-2025-21692)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Ensure job pointer is set to NULL after job completion\n\nAfter a job completes, the corresponding pointer in the device must\nbe set to NULL. Failing to do so triggers a warning when unloading\nthe driver, as it appears the job is still active. To prevent this,\nassign the job pointer to NULL after completing the job, indicating\nthe job has finished.(CVE-2025-21697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: Disallow replacing of child qdisc from one parent to another\n\nLion Ackermann was able to create a UAF which can be abused for privilege\nescalation with the following script\n\nStep 1. create root qdisc\ntc qdisc add dev lo root handle 1:0 drr\n\nstep2. a class for packet aggregation do demonstrate uaf\ntc class add dev lo classid 1:1 drr\n\nstep3. a class for nesting\ntc class add dev lo classid 1:2 drr\n\nstep4. a class to graft qdisc to\ntc class add dev lo classid 1:3 drr\n\nstep5.\ntc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024\n\nstep6.\ntc qdisc add dev lo parent 1:2 handle 3:0 drr\n\nstep7.\ntc class add dev lo classid 3:1 drr\n\nstep 8.\ntc qdisc add dev lo parent 3:1 handle 4:0 pfifo\n\nstep 9. Display the class/qdisc layout\n\ntc class ls dev lo\n class drr 1:1 root leaf 2: quantum 64Kb\n class drr 1:2 root leaf 3: quantum 64Kb\n class drr 3:1 root leaf 4: quantum 64Kb\n\ntc qdisc ls\n qdisc drr 1: dev lo root refcnt 2\n qdisc plug 2: dev lo parent 1:1\n qdisc pfifo 4: dev lo parent 3:1 limit 1000p\n qdisc drr 3: dev lo parent 1:2\n\nstep10. trigger the bug \u0026lt;=== prevented by this patch\ntc qdisc replace dev lo parent 1:3 handle 4:0\n\nstep 11. Redisplay again the qdiscs/classes\n\ntc class ls dev lo\n class drr 1:1 root leaf 2: quantum 64Kb\n class drr 1:2 root leaf 3: quantum 64Kb\n class drr 1:3 root leaf 4: quantum 64Kb\n class drr 3:1 root leaf 4: quantum 64Kb\n\ntc qdisc ls\n qdisc drr 1: dev lo root refcnt 2\n qdisc plug 2: dev lo parent 1:1\n qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p\n qdisc drr 3: dev lo parent 1:2\n\nObserve that a) parent for 4:0 does not change despite the replace request.\nThere can only be one parent.  b) refcount has gone up by two for 4:0 and\nc) both class 1:3 and 3:1 are pointing to it.\n\nStep 12.  send one packet to plug\necho \u0026quot;\u0026quot; | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001))\nstep13.  send one packet to the grafted fifo\necho \u0026quot;\u0026quot; | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))\n\nstep14. lets trigger the uaf\ntc class delete dev lo classid 1:3\ntc class delete dev lo classid 1:1\n\nThe semantics of \u0026quot;replace\u0026quot; is for a del/add _on the same node_ and not\na delete from one node(3:1) and add to another node (1:3) as in step10.\nWhile we could \u0026quot;fix\u0026quot; with a more complex approach there could be\nconsequences to expectations so the patch takes the preventive approach of\n\u0026quot;disallow such config\u0026quot;.\n\nJoint work with Lion Ackermann \u0026lt;nnamrec@gmail.com\u0026gt;(CVE-2025-21700)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: avoid race between device unregistration and ethnl ops\n\nThe following trace can be seen if a device is being unregistered while\nits number of channels are being modified.\n\n  DEBUG_LOCKS_WARN_ON(lock-\u0026gt;magic != lock)\n  WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120\n  CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771\n  RIP: 0010:__mutex_lock+0xc8a/0x1120\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ethtool_check_max_channel+0x1ea/0x880\n   ethnl_set_channels+0x3c3/0xb10\n   ethnl_default_set_doit+0x306/0x650\n   genl_family_rcv_msg_doit+0x1e3/0x2c0\n   genl_rcv_msg+0x432/0x6f0\n   netlink_rcv_skb+0x13d/0x3b0\n   genl_rcv+0x28/0x40\n   netlink_unicast+0x42e/0x720\n   netlink_sendmsg+0x765/0xc20\n   __sys_sendto+0x3ac/0x420\n   __x64_sys_sendto+0xe0/0x1c0\n   do_syscall_64+0x95/0x180\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThis is because unregister_netdevice_many_notify might run before the\nrtnl lock section of ethnl operations, eg. set_channels in the above\nexample. In this example the rss lock would be destroyed by the device\nunregistration path before being used again, but in general running\nethnl operations while dismantle has started is not a good idea.\n\nFix this by denying any operation on devices being unregistered. A check\nwas already there in ethnl_ops_begin, but not wide enough.\n\nNote that the same issue cannot be seen on the ioctl version\n(__dev_ethtool) because the device reference is retrieved from within\nthe rtnl lock section there. Once dismantle started, the net device is\nunlisted and no reference will be found.(CVE-2025-21701)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkernel: be more careful about dup_mmap() failures and uprobe registering\n\nIf a memory allocation fails during dup_mmap(), the maple tree can be left\nin an unsafe state for other iterators besides the exit path.  All the\nlocks are dropped before the exit_mmap() call (in mm/mmap.c), but the\nincomplete mm_struct can be reached through (at least) the rmap finding\nthe vmas which have a pointer back to the mm_struct.\n\nUp to this point, there have been no issues with being able to find an\nmm_struct that was only partially initialised.  Syzbot was able to make\nthe incomplete mm_struct fail with recent forking changes, so it has been\nproven unsafe to use the mm_struct that hasn\u0026apos;t been initialised, as\nreferenced in the link below.\n\nAlthough 8ac662f5da19f (\u0026quot;fork: avoid inappropriate uprobe access to\ninvalid mm\u0026quot;) fixed the uprobe access, it does not completely remove the\nrace.\n\nThis patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on the\noom side (even though this is extremely unlikely to be selected as an oom\nvictim in the race window), and sets MMF_UNSTABLE to avoid other potential\nusers from using a partially initialised mm_struct.\n\nWhen registering vmas for uprobe, skip the vmas in an mm that is marked\nunstable.  Modifying a vma in an unstable mm may cause issues if the mm\nisn\u0026apos;t fully initialised.(CVE-2025-21709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime\n\nAfter commit ec6bb299c7c3 (\u0026quot;md/md-bitmap: add \u0026apos;sync_size\u0026apos; into struct\nmd_bitmap_stats\u0026quot;), following panic is reported:\n\nOops: general protection fault, probably for non-canonical address\nRIP: 0010:bitmap_get_stats+0x2b/0xa0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n md_seq_show+0x2d2/0x5b0\n seq_read_iter+0x2b9/0x470\n seq_read+0x12f/0x180\n proc_reg_read+0x57/0xb0\n vfs_read+0xf6/0x380\n ksys_read+0x6c/0xf0\n do_syscall_64+0x82/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nRoot cause is that bitmap_get_stats() can be called at anytime if mddev\nis still there, even if bitmap is destroyed, or not fully initialized.\nDeferenceing bitmap in this case can crash the kernel. Meanwhile, the\nabove commit start to deferencing bitmap-\u0026gt;storage, make the problem\neasier to trigger.\n\nFix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.(CVE-2025-21712)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: handle errors that nilfs_prepare_chunk() may return\n\nPatch series \u0026quot;nilfs2: fix issues with rename operations\u0026quot;.\n\nThis series fixes BUG_ON check failures reported by syzbot around rename\noperations, and a minor behavioral issue where the mtime of a child\ndirectory changes when it is renamed instead of moved.\n\n\nThis patch (of 2):\n\nThe directory manipulation routines nilfs_set_link() and\nnilfs_delete_entry() rewrite the directory entry in the folio/page\npreviously read by nilfs_find_entry(), so error handling is omitted on the\nassumption that nilfs_prepare_chunk(), which prepares the buffer for\nrewriting, will always succeed for these.  And if an error is returned, it\ntriggers the legacy BUG_ON() checks in each routine.\n\nThis assumption is wrong, as proven by syzbot: the buffer layer called by\nnilfs_prepare_chunk() may call nilfs_get_block() if necessary, which may\nfail due to metadata corruption or other reasons.  This has been there all\nalong, but improved sanity checks and error handling may have made it more\nreproducible in fuzzing tests.\n\nFix this issue by adding missing error paths in nilfs_set_link(),\nnilfs_delete_entry(), and their caller nilfs_rename().(CVE-2025-21721)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFC: nci: Add bounds checking in nci_hci_create_pipe()\n\nThe \u0026quot;pipe\u0026quot; variable is a u8 which comes from the network.  If it\u0026apos;s more\nthan 127, then it results in memory corruption in the caller,\nnci_hci_connect_gate().(CVE-2025-21735)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix use-after free in init error and remove paths\n\ndevm_blk_crypto_profile_init() registers a cleanup handler to run when\nthe associated (platform-) device is being released. For UFS, the\ncrypto private data and pointers are stored as part of the ufs_hba\u0026apos;s\ndata structure \u0026apos;struct ufs_hba::crypto_profile\u0026apos;. This structure is\nallocated as part of the underlying ufshcd and therefore Scsi_host\nallocation.\n\nDuring driver release or during error handling in ufshcd_pltfrm_init(),\nthis structure is released as part of ufshcd_dealloc_host() before the\n(platform-) device associated with the crypto call above is released.\nOnce this device is released, the crypto cleanup code will run, using\nthe just-released \u0026apos;struct ufs_hba::crypto_profile\u0026apos;. This causes a\nuse-after-free situation:\n\n  Call trace:\n   kfree+0x60/0x2d8 (P)\n   kvfree+0x44/0x60\n   blk_crypto_profile_destroy_callback+0x28/0x70\n   devm_action_release+0x1c/0x30\n   release_nodes+0x6c/0x108\n   devres_release_all+0x98/0x100\n   device_unbind_cleanup+0x20/0x70\n   really_probe+0x218/0x2d0\n\nIn other words, the initialisation code flow is:\n\n  platform-device probe\n    ufshcd_pltfrm_init()\n      ufshcd_alloc_host()\n        scsi_host_alloc()\n          allocation of struct ufs_hba\n          creation of scsi-host devices\n    devm_blk_crypto_profile_init()\n      devm registration of cleanup handler using platform-device\n\nand during error handling of ufshcd_pltfrm_init() or during driver\nremoval:\n\n  ufshcd_dealloc_host()\n    scsi_host_put()\n      put_device(scsi-host)\n        release of struct ufs_hba\n  put_device(platform-device)\n    crypto cleanup handler\n\nTo fix this use-after free, change ufshcd_alloc_host() to register a\ndevres action to automatically cleanup the underlying SCSI device on\nufshcd destruction, without requiring explicit calls to\nufshcd_dealloc_host(). This way:\n\n    * the crypto profile and all other ufs_hba-owned resources are\n      destroyed before SCSI (as they\u0026apos;ve been registered after)\n    * a memleak is plugged in tc-dwc-g210-pci.c remove() as a\n      side-effect\n    * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as\n      it\u0026apos;s not needed anymore\n    * no future drivers using ufshcd_alloc_host() could ever forget\n      adding the cleanup(CVE-2025-21739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: ipheth: fix DPE OoB read\n\nFix an out-of-bounds DPE read, limit the number of processed DPEs to\nthe amount that fits into the fixed-size NDP16 header.(CVE-2025-21741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: ipheth: use static NDP16 location in URB\n\nOriginal code allowed for the start of NDP16 to be anywhere within the\nURB based on the `wNdpIndex` value in NTH16. Only the start position of\nNDP16 was checked, so it was possible for even the fixed-length part\nof NDP16 to extend past the end of URB, leading to an out-of-bounds\nread.\n\nOn iOS devices, the NDP16 header always directly follows NTH16. Rely on\nand check for this specific format.\n\nThis, along with NCM-specific minimal URB length check that already\nexists, will ensure that the fixed-length part of NDP16 plus a set\namount of DPEs fit within the URB.\n\nNote that this commit alone does not fully address the OoB read.\nThe limit on the amount of DPEs needs to be enforced separately.(CVE-2025-21742)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()\n\nOn removal of the device or unloading of the kernel module a potential NULL\npointer dereference occurs.\n\nThe following sequence deletes the interface:\n\n  brcmf_detach()\n    brcmf_remove_interface()\n      brcmf_del_if()\n\nInside the brcmf_del_if() function the drvr-\u0026gt;if2bss[ifidx] is updated to\nBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.\n\nAfter brcmf_remove_interface() call the brcmf_proto_detach() function is\ncalled providing the following sequence:\n\n  brcmf_detach()\n    brcmf_proto_detach()\n      brcmf_proto_msgbuf_detach()\n        brcmf_flowring_detach()\n          brcmf_msgbuf_delete_flowring()\n            brcmf_msgbuf_remove_flowring()\n              brcmf_flowring_delete()\n                brcmf_get_ifp()\n                brcmf_txfinalize()\n\nSince brcmf_get_ip() can and actually will return NULL in this case the\ncall to brcmf_txfinalize() will result in a NULL pointer dereference inside\nbrcmf_txfinalize() when trying to update ifp-\u0026gt;ndev-\u0026gt;stats.tx_errors.\n\nThis will only happen if a flowring still has an skb.\n\nAlthough the NULL pointer dereference has only been seen when trying to\nupdate the tx statistic, all other uses of the ifp pointer have been\nguarded as well with an early return if ifp is NULL.(CVE-2025-21744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: synaptics - fix crash when enabling pass-through port\n\nWhen enabling a pass-through port an interrupt might come before psmouse\ndriver binds to the pass-through port. However synaptics sub-driver\ntries to access psmouse instance presumably associated with the\npass-through port to figure out if only 1 byte of response or entire\nprotocol packet needs to be forwarded to the pass-through port and may\ncrash if psmouse instance has not been attached to the port yet.\n\nFix the crash by introducing open() and close() methods for the port and\ncheck if the port is open before trying to access psmouse instance.\nBecause psmouse calls serio_open() only after attaching psmouse instance\nto serio port instance this prevents the potential crash.(CVE-2025-21746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix integer overflows on 32 bit systems\n\nOn 32bit systems the addition operations in ipc_msg_alloc() can\npotentially overflow leading to memory corruption.\nAdd bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow.(CVE-2025-21748)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: rose: lock the socket in rose_bind()\n\nsyzbot reported a soft lockup in rose_loopback_timer(),\nwith a repro calling bind() from multiple threads.\n\nrose_bind() must lock the socket to avoid this issue.(CVE-2025-21749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix use-after-free when attempting to join an aborted transaction\n\nWhen we are trying to join the current transaction and if it\u0026apos;s aborted,\nwe read its \u0026apos;aborted\u0026apos; field after unlocking fs_info-\u0026gt;trans_lock and\nwithout holding any extra reference count on it. This means that a\nconcurrent task that is aborting the transaction may free the transaction\nbefore we read its \u0026apos;aborted\u0026apos; field, leading to a use-after-free.\n\nFix this by reading the \u0026apos;aborted\u0026apos; field while holding fs_info-\u0026gt;trans_lock\nsince any freeing task must first acquire that lock and set\nfs_info-\u0026gt;running_transaction to NULL before freeing the transaction.\n\nThis was reported by syzbot and Dmitry with the following stack traces\nfrom KASAN:\n\n   ==================================================================\n   BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278\n   Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128\n\n   CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0\n   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n   Workqueue: events_unbound btrfs_async_reclaim_data_space\n   Call Trace:\n    \u0026lt;TASK\u0026gt;\n    __dump_stack lib/dump_stack.c:94 [inline]\n    dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n    print_address_description mm/kasan/report.c:378 [inline]\n    print_report+0x169/0x550 mm/kasan/report.c:489\n    kasan_report+0x143/0x180 mm/kasan/report.c:602\n    join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278\n    start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697\n    flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803\n    btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321\n    process_one_work kernel/workqueue.c:3236 [inline]\n    process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317\n    worker_thread+0x870/0xd30 kernel/workqueue.c:3398\n    kthread+0x2f0/0x390 kernel/kthread.c:389\n    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n    \u0026lt;/TASK\u0026gt;\n\n   Allocated by task 5315:\n    kasan_save_stack mm/kasan/common.c:47 [inline]\n    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n    poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n    __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394\n    kasan_kmalloc include/linux/kasan.h:260 [inline]\n    __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329\n    kmalloc_noprof include/linux/slab.h:901 [inline]\n    join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308\n    start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697\n    btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572\n    lookup_open fs/namei.c:3649 [inline]\n    open_last_lookups fs/namei.c:3748 [inline]\n    path_openat+0x1c03/0x3590 fs/namei.c:3984\n    do_filp_open+0x27f/0x4e0 fs/namei.c:4014\n    do_sys_openat2+0x13e/0x1d0 fs/open.c:1402\n    do_sys_open fs/open.c:1417 [inline]\n    __do_sys_creat fs/open.c:1495 [inline]\n    __se_sys_creat fs/open.c:1489 [inline]\n    __x64_sys_creat+0x123/0x170 fs/open.c:1489\n    do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n    do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n    entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n   Freed by task 5336:\n    kasan_save_stack mm/kasan/common.c:47 [inline]\n    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n    kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582\n    poison_slab_object mm/kasan/common.c:247 [inline]\n    __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264\n    kasan_slab_free include/linux/kasan.h:233 [inline]\n    slab_free_hook mm/slub.c:2353 [inline]\n    slab_free mm/slub.c:4613 [inline]\n    kfree+0x196/0x430 mm/slub.c:4761\n    cleanup_transaction fs/btrfs/transaction.c:2063 [inline]\n    btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598\n    insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757\n    btrfs_balance+0x992/\n---truncated---(CVE-2025-21753)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: add RCU protection to mld_newpack()\n\nmld_newpack() can be called without RTNL or RCU being held.\n\nNote that we no longer can use sock_alloc_send_skb() because\nipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.\n\nInstead use alloc_skb() and charge the net-\u0026gt;ipv6.igmp_sk\nsocket under RCU protection.(CVE-2025-21758)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: extend RCU protection in igmp6_send()\n\nigmp6_send() can be called without RTNL or RCU being held.\n\nExtend RCU protection so that we can safely fetch the net pointer\nand avoid a potential UAF.\n\nNote that we no longer can use sock_alloc_send_skb() because\nipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.\n\nInstead use alloc_skb() and charge the net-\u0026gt;ipv6.igmp_sk\nsocket under RCU protection.(CVE-2025-21759)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nndisc: extend RCU protection in ndisc_send_skb()\n\nndisc_send_skb() can be called without RTNL or RCU held.\n\nAcquire rcu_read_lock() earlier, so that we can use dev_net_rcu()\nand avoid a potential UAF.(CVE-2025-21760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: use RCU protection in ovs_vport_cmd_fill_info()\n\novs_vport_cmd_fill_info() can be called without RTNL or RCU.\n\nUse RCU protection and dev_net_rcu() to avoid potential UAF.(CVE-2025-21761)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narp: use RCU protection in arp_xmit()\n\narp_xmit() can be called without RTNL or RCU protection.\n\nUse RCU protection to avoid potential UAF.(CVE-2025-21762)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nneighbour: use RCU protection in __neigh_notify()\n\n__neigh_notify() can be called without RTNL or RCU protection.\n\nUse RCU protection to avoid potential UAF.(CVE-2025-21763)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nndisc: use RCU protection in ndisc_alloc_skb()\n\nndisc_alloc_skb() can be called without RTNL or RCU being held.\n\nAdd RCU protection to avoid possible UAF.(CVE-2025-21764)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: use RCU protection in ip6_default_advmss()\n\nip6_default_advmss() needs rcu protection to make\nsure the net structure it reads does not disappear.(CVE-2025-21765)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: use RCU protection in __ip_rt_update_pmtu()\n\n__ip_rt_update_pmtu() must use RCU protection to make\nsure the net structure it reads does not disappear.(CVE-2025-21766)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npartitions: mac: fix handling of bogus partition table\n\nFix several issues in partition probing:\n\n - The bailout for a bad partoffset must use put_dev_sector(), since the\n   preceding read_part_sector() succeeded.\n - If the partition table claims a silly sector size like 0xfff bytes\n   (which results in partition table entries straddling sector boundaries),\n   bail out instead of accessing out-of-bounds memory.\n - We must not assume that the partition table contains proper NUL\n   termination - use strnlen() and strncmp() instead of strlen() and\n   strcmp().(CVE-2025-21772)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: etas_es58x: fix potential NULL pointer dereference on udev-\u0026gt;serial\n\nThe driver assumed that es58x_dev-\u0026gt;udev-\u0026gt;serial could never be NULL.\nWhile this is true on commercially available devices, an attacker\ncould spoof the device identity providing a NULL USB serial number.\nThat would trigger a NULL pointer dereference.\n\nAdd a check on es58x_dev-\u0026gt;udev-\u0026gt;serial before accessing it.(CVE-2025-21773)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: ctucanfd: handle skb allocation failure\n\nIf skb allocation fails, the pointer to struct can_frame is NULL. This\nis actually handled everywhere inside ctucan_err_interrupt() except for\nthe only place.\n\nAdd the missed NULL check.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE static\nanalysis tool.(CVE-2025-21775)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Reject Hyper-V\u0026apos;s SEND_IPI hypercalls if local APIC isn\u0026apos;t in-kernel\n\nAdvertise support for Hyper-V\u0026apos;s SEND_IPI and SEND_IPI_EX hypercalls if and\nonly if the local API is emulated/virtualized by KVM, and explicitly reject\nsaid hypercalls if the local APIC is emulated in userspace, i.e. don\u0026apos;t rely\non userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.\n\nRejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if\nHyper-V enlightenments are exposed to the guest without an in-kernel local\nAPIC:\n\n  dump_stack+0xbe/0xfd\n  __kasan_report.cold+0x34/0x84\n  kasan_report+0x3a/0x50\n  __apic_accept_irq+0x3a/0x5c0\n  kvm_hv_send_ipi.isra.0+0x34e/0x820\n  kvm_hv_hypercall+0x8d9/0x9d0\n  kvm_emulate_hypercall+0x506/0x7e0\n  __vmx_handle_exit+0x283/0xb60\n  vmx_handle_exit+0x1d/0xd0\n  vcpu_enter_guest+0x16b0/0x24c0\n  vcpu_run+0xc0/0x550\n  kvm_arch_vcpu_ioctl_run+0x170/0x6d0\n  kvm_vcpu_ioctl+0x413/0xb20\n  __se_sys_ioctl+0x111/0x160\n  do_syscal1_64+0x30/0x40\n  entry_SYSCALL_64_after_hwframe+0x67/0xd1\n\nNote, checking the sending vCPU is sufficient, as the per-VM irqchip_mode\ncan\u0026apos;t be modified after vCPUs are created, i.e. if one vCPU has an\nin-kernel local APIC, then all vCPUs have an in-kernel local APIC.(CVE-2025-21779)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table()\n\nIt malicious user provides a small pptable through sysfs and then\na bigger pptable, it may cause buffer overflow attack in function\nsmu_sys_set_pp_table().(CVE-2025-21780)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: fix panic during interface removal\n\nReference counting is used to ensure that\nbatadv_hardif_neigh_node and batadv_hard_iface\nare not freed before/during\nbatadv_v_elp_throughput_metric_update work is\nfinished.\n\nBut there isn\u0026apos;t a guarantee that the hard if will\nremain associated with a soft interface up until\nthe work is finished.\n\nThis fixes a crash triggered by reboot that looks\nlike this:\n\nCall trace:\n batadv_v_mesh_free+0xd0/0x4dc [batman_adv]\n batadv_v_elp_throughput_metric_update+0x1c/0xa4\n process_one_work+0x178/0x398\n worker_thread+0x2e8/0x4d0\n kthread+0xd8/0xdc\n ret_from_fork+0x10/0x20\n\n(the batadv_v_mesh_free call is misleading,\nand does not actually happen)\n\nI was able to make the issue happen more reliably\nby changing hardif_neigh-\u0026gt;bat_v.metric_work work\nto be delayed work. This allowed me to track down\nand confirm the fix.\n\n[sven@narfation.org: prevent entering batadv_v_elp_get_throughput without\n soft_iface](CVE-2025-21781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: bail out when failed to load fw in psp_init_cap_microcode()\n\nIn function psp_init_cap_microcode(), it should bail out when failed to\nload firmware, otherwise it may cause invalid memory access.(CVE-2025-21784)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: check vxlan_vnigroup_init() return value\n\nvxlan_init() must check vxlan_vnigroup_init() success\notherwise a crash happens later, spotted by syzbot.\n\nOops: general protection fault, probably for non-canonical address 0xdffffc000000002c: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000160-0x0000000000000167]\nCPU: 0 UID: 0 PID: 7313 Comm: syz-executor147 Not tainted 6.14.0-rc1-syzkaller-00276-g69b54314c975 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n RIP: 0010:vxlan_vnigroup_uninit+0x89/0x500 drivers/net/vxlan/vxlan_vnifilter.c:912\nCode: 00 48 8b 44 24 08 4c 8b b0 98 41 00 00 49 8d 86 60 01 00 00 48 89 c2 48 89 44 24 10 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 4d 04 00 00 49 8b 86 60 01 00 00 48 ba 00 00 00\nRSP: 0018:ffffc9000cc1eea8 EFLAGS: 00010202\nRAX: dffffc0000000000 RBX: 0000000000000001 RCX: ffffffff8672effb\nRDX: 000000000000002c RSI: ffffffff8672ecb9 RDI: ffff8880461b4f18\nRBP: ffff8880461b4ef4 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000020000\nR13: ffff8880461b0d80 R14: 0000000000000000 R15: dffffc0000000000\nFS:  00007fecfa95d6c0(0000) GS:ffff88806a600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fecfa95cfb8 CR3: 000000004472c000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  vxlan_uninit+0x1ab/0x200 drivers/net/vxlan/vxlan_core.c:2942\n  unregister_netdevice_many_notify+0x12d6/0x1f30 net/core/dev.c:11824\n  unregister_netdevice_many net/core/dev.c:11866 [inline]\n  unregister_netdevice_queue+0x307/0x3f0 net/core/dev.c:11736\n  register_netdevice+0x1829/0x1eb0 net/core/dev.c:10901\n  __vxlan_dev_create+0x7c6/0xa30 drivers/net/vxlan/vxlan_core.c:3981\n  vxlan_newlink+0xd1/0x130 drivers/net/vxlan/vxlan_core.c:4407\n  rtnl_newlink_create net/core/rtnetlink.c:3795 [inline]\n  __rtnl_newlink net/core/rtnetlink.c:3906 [inline](CVE-2025-21790)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nax25: Fix refcount leak caused by setting SO_BINDTODEVICE sockopt\n\nIf an AX25 device is bound to a socket by setting the SO_BINDTODEVICE\nsocket option, a refcount leak will occur in ax25_release().\n\nCommit 9fd75b66b8f6 (\u0026quot;ax25: Fix refcount leaks caused by ax25_cb_del()\u0026quot;)\nadded decrement of device refcounts in ax25_release(). In order for that\nto work correctly the refcounts must already be incremented when the\ndevice is bound to the socket. An AX25 device can be bound to a socket\nby either calling ax25_bind() or setting SO_BINDTODEVICE socket option.\nIn both cases the refcounts should be incremented, but in fact it is done\nonly in ax25_bind().\n\nThis bug leads to the following issue reported by Syzkaller:\n\n================================================================\nrefcount_t: decrement hit 0; leaking memory.\nWARNING: CPU: 1 PID: 5932 at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31\nModules linked in:\nCPU: 1 UID: 0 PID: 5932 Comm: syz-executor424 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __refcount_dec include/linux/refcount.h:336 [inline]\n refcount_dec include/linux/refcount.h:351 [inline]\n ref_tracker_free+0x710/0x820 lib/ref_tracker.c:236\n netdev_tracker_free include/linux/netdevice.h:4156 [inline]\n netdev_put include/linux/netdevice.h:4173 [inline]\n netdev_put include/linux/netdevice.h:4169 [inline]\n ax25_release+0x33f/0xa10 net/ax25/af_ax25.c:1069\n __sock_release+0xb0/0x270 net/socket.c:640\n sock_close+0x1c/0x30 net/socket.c:1408\n ...\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n ...\n \u0026lt;/TASK\u0026gt;\n================================================================\n\nFix the implementation of ax25_setsockopt() by adding increment of\nrefcounts for the new device bound, and decrement of refcounts for\nthe old unbound device.(CVE-2025-21792)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: sn-f-ospi: Fix division by zero\n\nWhen there is no dummy cycle in the spi-nor commands, both dummy bus cycle\nbytes and width are zero. Because of the cpu\u0026apos;s warning when divided by\nzero, the warning should be avoided. Return just zero to avoid such\ncalculations.(CVE-2025-21793)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: omap: use threaded IRQ for LCD DMA\n\nWhen using touchscreen and framebuffer, Nokia 770 crashes easily with:\n\n    BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000\n    Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd\n    CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2\n    Hardware name: Nokia 770\n    Call trace:\n     unwind_backtrace from show_stack+0x10/0x14\n     show_stack from dump_stack_lvl+0x54/0x5c\n     dump_stack_lvl from __schedule_bug+0x50/0x70\n     __schedule_bug from __schedule+0x4d4/0x5bc\n     __schedule from schedule+0x34/0xa0\n     schedule from schedule_preempt_disabled+0xc/0x10\n     schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4\n     __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4\n     clk_prepare_lock from clk_set_rate+0x18/0x154\n     clk_set_rate from sossi_read_data+0x4c/0x168\n     sossi_read_data from hwa742_read_reg+0x5c/0x8c\n     hwa742_read_reg from send_frame_handler+0xfc/0x300\n     send_frame_handler from process_pending_requests+0x74/0xd0\n     process_pending_requests from lcd_dma_irq_handler+0x50/0x74\n     lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130\n     __handle_irq_event_percpu from handle_irq_event+0x28/0x68\n     handle_irq_event from handle_level_irq+0x9c/0x170\n     handle_level_irq from generic_handle_domain_irq+0x2c/0x3c\n     generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c\n     omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c\n     generic_handle_arch_irq from call_with_stack+0x1c/0x24\n     call_with_stack from __irq_svc+0x94/0xa8\n    Exception stack(0xc5255da0 to 0xc5255de8)\n    5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248\n    5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94\n    5de0: 60000013 ffffffff\n     __irq_svc from clk_prepare_lock+0x4c/0xe4\n     clk_prepare_lock from clk_get_rate+0x10/0x74\n     clk_get_rate from uwire_setup_transfer+0x40/0x180\n     uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c\n     spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664\n     spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498\n     __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8\n     __spi_sync from spi_sync+0x24/0x40\n     spi_sync from ads7846_halfd_read_state+0x5c/0x1c0\n     ads7846_halfd_read_state from ads7846_irq+0x58/0x348\n     ads7846_irq from irq_thread_fn+0x1c/0x78\n     irq_thread_fn from irq_thread+0x120/0x228\n     irq_thread from kthread+0xc8/0xe8\n     kthread from ret_from_fork+0x14/0x28\n\nAs a quick fix, switch to a threaded IRQ which provides a stable system.(CVE-2025-21821)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: reject mismatching sum of field_len with set key length\n\nThe field length description provides the length of each separated key\nfield in the concatenation, each field gets rounded up to 32-bits to\ncalculate the pipapo rule width from pipapo_init(). The set key length\nprovides the total size of the key aligned to 32-bits.\n\nRegister-based arithmetics still allows for combining mismatching set\nkey length and field length description, eg. set key length 10 and field\ndescription [ 5, 4 ] leading to pipapo width of 12.(CVE-2025-21826)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlandlock: Handle weird files\n\nA corrupted filesystem (e.g. bcachefs) might return weird files.\nInstead of throwing a warning and allowing access to such file, treat\nthem as regular files.(CVE-2025-21830)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1\n\ncommit 9d26d3a8f1b0 (\u0026quot;PCI: Put PCIe ports into D3 during suspend\u0026quot;) sets the\npolicy that all PCIe ports are allowed to use D3.  When the system is\nsuspended if the port is not power manageable by the platform and won\u0026apos;t be\nused for wakeup via a PME this sets up the policy for these ports to go\ninto D3hot.\n\nThis policy generally makes sense from an OSPM perspective but it leads to\nproblems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with a\nspecific old BIOS. This manifests as a system hang.\n\nOn the affected Device + BIOS combination, add a quirk for the root port of\nthe problematic controller to ensure that these root ports are not put into\nD3hot at suspend.\n\nThis patch is based on\n\n  https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.com\n\nbut with the added condition both in the documentation and in the code to\napply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and only\nthe affected root ports.(CVE-2025-21831)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_midi: fix MIDI Streaming descriptor lengths\n\nWhile the MIDI jacks are configured correctly, and the MIDIStreaming\nendpoint descriptors are filled with the correct information,\nbNumEmbMIDIJack and bLength are set incorrectly in these descriptors.\n\nThis does not matter when the numbers of in and out ports are equal, but\nwhen they differ the host will receive broken descriptors with\nuninitialized stack memory leaking into the descriptor for whichever\nvalue is smaller.\n\nThe precise meaning of \u0026quot;in\u0026quot; and \u0026quot;out\u0026quot; in the port counts is not clearly\ndefined and can be confusing.  But elsewhere the driver consistently\nuses this to match the USB meaning of IN and OUT viewed from the host,\nso that \u0026quot;in\u0026quot; ports send data to the host and \u0026quot;out\u0026quot; ports receive data\nfrom it.(CVE-2025-21835)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/kbuf: reallocate buf lists on upgrade\n\nIORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it\nwas created for legacy selected buffer and has been emptied. It violates\nthe requirement that most of the field should stay stable after publish.\nAlways reallocate it instead.(CVE-2025-21836)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: core: flush gadget workqueue after device removal\n\ndevice_del() can lead to new work being scheduled in gadget-\u0026gt;work\nworkqueue. This is observed, for example, with the dwc3 driver with the\nfollowing call stack:\n  device_del()\n    gadget_unbind_driver()\n      usb_gadget_disconnect_locked()\n        dwc3_gadget_pullup()\n\t  dwc3_gadget_soft_disconnect()\n\t    usb_gadget_set_state()\n\t      schedule_work(\u0026amp;gadget-\u0026gt;work)\n\nMove flush_work() after device_del() to ensure the workqueue is cleaned\nup.(CVE-2025-21838)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data()\n\nThe nullity of sps-\u0026gt;cstream should be checked similarly as it is done in\nsof_set_stream_data_offset() function.\nAssuming that it is not NULL if sps-\u0026gt;stream is NULL is incorrect and can\nlead to NULL pointer dereference.(CVE-2025-21847)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfp: bpf: Add check for nfp_app_ctrl_msg_alloc()\n\nAdd check for the return value of nfp_app_ctrl_msg_alloc() in\nnfp_bpf_cmsg_alloc() to prevent null pointer dereference.(CVE-2025-21848)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nibmvnic: Don\u0026apos;t reference skb after sending to VIOS\n\nPreviously, after successfully flushing the xmit buffer to VIOS,\nthe tx_bytes stat was incremented by the length of the skb.\n\nIt is invalid to access the skb memory after sending the buffer to\nthe VIOS because, at any point after sending, the VIOS can trigger\nan interrupt to free this memory. A race between reading skb-\u0026gt;len\nand freeing the skb is possible (especially during LPM) and will\nresult in use-after-free:\n ==================================================================\n BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic]\n Read of size 4 at addr c00000024eb48a70 by task hxecom/14495\n \u0026lt;...\u0026gt;\n Call Trace:\n [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable)\n [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0\n [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8\n [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0\n [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic]\n [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358\n \u0026lt;...\u0026gt;\n Freed by task 0:\n kasan_save_stack+0x34/0x68\n kasan_save_track+0x2c/0x50\n kasan_save_free_info+0x64/0x108\n __kasan_mempool_poison_object+0x148/0x2d4\n napi_skb_cache_put+0x5c/0x194\n net_tx_action+0x154/0x5b8\n handle_softirqs+0x20c/0x60c\n do_softirq_own_stack+0x6c/0x88\n \u0026lt;...\u0026gt;\n The buggy address belongs to the object at c00000024eb48a00 which\n  belongs to the cache skbuff_head_cache of size 224\n==================================================================(CVE-2025-21855)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: cls_api: fix error handling causing NULL dereference\n\ntcf_exts_miss_cookie_base_alloc() calls xa_alloc_cyclic() which can\nreturn 1 if the allocation succeeded after wrapping. This was treated as\nan error, with value 1 returned to caller tcf_exts_init_ex() which sets\nexts-\u0026gt;actions to NULL and returns 1 to caller fl_change().\n\nfl_change() treats err == 1 as success, calling tcf_exts_validate_ex()\nwhich calls tcf_action_init() with exts-\u0026gt;actions as argument, where it\nis dereferenced.\n\nExample trace:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nCPU: 114 PID: 16151 Comm: handler114 Kdump: loaded Not tainted 5.14.0-503.16.1.el9_5.x86_64 #1\nRIP: 0010:tcf_action_init+0x1f8/0x2c0\nCall Trace:\n tcf_action_init+0x1f8/0x2c0\n tcf_exts_validate_ex+0x175/0x190\n fl_change+0x537/0x1120 [cls_flower](CVE-2025-21857)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngeneve: Fix use-after-free in geneve_find_dev().\n\nsyzkaller reported a use-after-free in geneve_find_dev() [0]\nwithout repro.\n\ngeneve_configure() links struct geneve_dev.next to\nnet_generic(net, geneve_net_id)-\u0026gt;geneve_list.\n\nThe net here could differ from dev_net(dev) if IFLA_NET_NS_PID,\nIFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.\n\nWhen dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally\ncalls unregister_netdevice_queue() for each dev in the netns,\nand later the dev is freed.\n\nHowever, its geneve_dev.next is still linked to the backend UDP\nsocket netns.\n\nThen, use-after-free will occur when another geneve dev is created\nin the netns.\n\nLet\u0026apos;s call geneve_dellink() instead in geneve_destroy_tunnels().\n\n[0]:\nBUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]\nBUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343\nRead of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441\n\nCPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C)\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x16c/0x6f0 mm/kasan/report.c:489\n kasan_report+0xc0/0x120 mm/kasan/report.c:602\n __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379\n geneve_find_dev drivers/net/geneve.c:1295 [inline]\n geneve_configure+0x234/0x858 drivers/net/geneve.c:1343\n geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634\n rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795\n __rtnl_newlink net/core/rtnetlink.c:3906 [inline]\n rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021\n rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911\n netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543\n rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938\n netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]\n netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348\n netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892\n sock_sendmsg_nosec net/socket.c:713 [inline]\n __sock_sendmsg net/socket.c:728 [inline]\n ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568\n ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622\n __sys_sendmsg net/socket.c:2654 [inline]\n __do_sys_sendmsg net/socket.c:2659 [inline]\n __se_sys_sendmsg net/socket.c:2657 [inline]\n __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151\n el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600\n\nAllocated by task 13247:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x30/0x68 mm/kasan/common.c:68\n kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4298 [inline]\n __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304\n __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645\n alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470\n rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604\n rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780\n __rtnl_newlink net/core/rtnetlink.c:3906 [inline]\n rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021\n rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911\n netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543\n rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938\n netlink_unicast_kernel net/netlink/af_n\n---truncated---(CVE-2025-21858)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: f_midi: f_midi_complete to call queue_work\n\nWhen using USB MIDI, a lock is attempted to be acquired twice through a\nre-entrant call to f_midi_transmit, causing a deadlock.\n\nFix it by using queue_work() to schedule the inner f_midi_transmit() via\na high priority work queue from the completion handler.(CVE-2025-21859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrop_monitor: fix incorrect initialization order\n\nSyzkaller reports the following bug:\n\nBUG: spinlock bad magic on CPU#1, syz-executor.0/7995\n lock: 0xffff88805303f3e0, .magic: 00000000, .owner: \u0026lt;none\u0026gt;/-1, .owner_cpu: 0\nCPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G            E     5.10.209+ #1\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x119/0x179 lib/dump_stack.c:118\n debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]\n do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline]\n _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159\n reset_per_cpu_data+0xe6/0x240 [drop_monitor]\n net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor]\n genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739\n genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]\n genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800\n netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497\n genl_rcv+0x29/0x40 net/netlink/genetlink.c:811\n netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]\n netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348\n netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916\n sock_sendmsg_nosec net/socket.c:651 [inline]\n __sock_sendmsg+0x157/0x190 net/socket.c:663\n ____sys_sendmsg+0x712/0x870 net/socket.c:2378\n ___sys_sendmsg+0xf8/0x170 net/socket.c:2432\n __sys_sendmsg+0xea/0x1b0 net/socket.c:2461\n do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46\n entry_SYSCALL_64_after_hwframe+0x62/0xc7\nRIP: 0033:0x7f3f9815aee9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9\nRDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007\nRBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768\n\nIf drop_monitor is built as a kernel module, syzkaller may have time\nto send a netlink NET_DM_CMD_START message during the module loading.\nThis will call the net_dm_monitor_start() function that uses\na spinlock that has not yet been initialized.\n\nTo fix this, let\u0026apos;s place resource initialization above the registration\nof a generic netlink family.\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller.(CVE-2025-21862)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC\n\nErhard reported the following KASAN hit while booting his PowerMac G4\nwith a KASAN-enabled kernel 6.13-rc6:\n\n  BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8\n  Write of size 8 at addr f1000000 by task chronyd/1293\n\n  CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G        W          6.13.0-rc6-PMacG4 #2\n  Tainted: [W]=WARN\n  Hardware name: PowerMac3,6 7455 0x80010303 PowerMac\n  Call Trace:\n  [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable)\n  [c24375b0] [c0504998] print_report+0xdc/0x504\n  [c2437610] [c050475c] kasan_report+0xf8/0x108\n  [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c\n  [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8\n  [c24376c0] [c004c014] patch_instructions+0x15c/0x16c\n  [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c\n  [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac\n  [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec\n  [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478\n  [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14\n  [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4\n  [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890\n  [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420\n  [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c\n  --- interrupt: c00 at 0x5a1274\n  NIP:  005a1274 LR: 006a3b3c CTR: 005296c8\n  REGS: c2437f40 TRAP: 0c00   Tainted: G        W           (6.13.0-rc6-PMacG4)\n  MSR:  0200f932 \u0026lt;VEC,EE,PR,FP,ME,IR,DR,RI\u0026gt;  CR: 24004422  XER: 00000000\n\n  GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932\n  GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57\n  GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002\n  GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001\n  NIP [005a1274] 0x5a1274\n  LR [006a3b3c] 0x6a3b3c\n  --- interrupt: c00\n\n  The buggy address belongs to the virtual mapping at\n   [f1000000, f1002000) created by:\n   text_area_cpu_up+0x20/0x190\n\n  The buggy address belongs to the physical page:\n  page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30\n  flags: 0x80000000(zone=2)\n  raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001\n  raw: 00000000\n  page dumped because: kasan: bad access detected\n\n  Memory state around the buggy address:\n   f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n   f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  \u0026gt;f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n             ^\n   f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n   f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n  ==================================================================\n\nf8 corresponds to KASAN_VMALLOC_INVALID which means the area is not\ninitialised hence not supposed to be used yet.\n\nPowerpc text patching infrastructure allocates a virtual memory area\nusing get_vm_area() and flags it as VM_ALLOC. But that flag is meant\nto be used for vmalloc() and vmalloc() allocated memory is not\nsupposed to be used before a call to __vmalloc_node_range() which is\nnever called for that area.\n\nThat went undetected until commit e4137f08816b (\u0026quot;mm, kasan, kmsan:\ninstrument copy_from/to_kernel_nofault\u0026quot;)\n\nThe area allocated by text_area_cpu_up() is not vmalloc memory, it is\nmapped directly on demand when needed by map_kernel_page(). There is\nno VM flag corresponding to such usage, so just pass no flag. That way\nthe area will be unpoisonned and usable immediately.(CVE-2025-21866)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, test_run: Fix use-after-free issue in eth_skb_pkt_type()\n\nKMSAN reported a use-after-free issue in eth_skb_pkt_type()[1]. The\ncause of the issue was that eth_skb_pkt_type() accessed skb\u0026apos;s data\nthat didn\u0026apos;t contain an Ethernet header. This occurs when\nbpf_prog_test_run_xdp() passes an invalid value as the user_data\nargument to bpf_test_init().\n\nFix this by returning an error when user_data is less than ETH_HLEN in\nbpf_test_init(). Additionally, remove the check for \u0026quot;if (user_size \u0026gt;\nsize)\u0026quot; as it is unnecessary.\n\n[1]\nBUG: KMSAN: use-after-free in eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]\nBUG: KMSAN: use-after-free in eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165\n eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]\n eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165\n __xdp_build_skb_from_frame+0x5a8/0xa50 net/core/xdp.c:635\n xdp_recv_frames net/bpf/test_run.c:272 [inline]\n xdp_test_run_batch net/bpf/test_run.c:361 [inline]\n bpf_test_run_xdp_live+0x2954/0x3330 net/bpf/test_run.c:390\n bpf_prog_test_run_xdp+0x148e/0x1b10 net/bpf/test_run.c:1318\n bpf_prog_test_run+0x5b7/0xa30 kernel/bpf/syscall.c:4371\n __sys_bpf+0x6a6/0xe20 kernel/bpf/syscall.c:5777\n __do_sys_bpf kernel/bpf/syscall.c:5866 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5864 [inline]\n __x64_sys_bpf+0xa4/0xf0 kernel/bpf/syscall.c:5864\n x64_sys_call+0x2ea0/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n free_pages_prepare mm/page_alloc.c:1056 [inline]\n free_unref_page+0x156/0x1320 mm/page_alloc.c:2657\n __free_pages+0xa3/0x1b0 mm/page_alloc.c:4838\n bpf_ringbuf_free kernel/bpf/ringbuf.c:226 [inline]\n ringbuf_map_free+0xff/0x1e0 kernel/bpf/ringbuf.c:235\n bpf_map_free kernel/bpf/syscall.c:838 [inline]\n bpf_map_free_deferred+0x17c/0x310 kernel/bpf/syscall.c:862\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xa2b/0x1b60 kernel/workqueue.c:3310\n worker_thread+0xedf/0x1550 kernel/workqueue.c:3391\n kthread+0x535/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x6e/0x90 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\nCPU: 1 UID: 0 PID: 17276 Comm: syz.1.16450 Not tainted 6.12.0-05490-g9bb88c659673 #8\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014(CVE-2025-21867)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: ipc4-topology: Harden loops for looking up ALH copiers\n\nOther, non DAI copier widgets could have the same  stream name (sname) as\nthe ALH copier and in that case the copier-\u0026gt;data is NULL, no alh_data is\nattached, which could lead to NULL pointer dereference.\nWe could check for this NULL pointer in sof_ipc4_prepare_copier_module()\nand avoid the crash, but a similar loop in sof_ipc4_widget_setup_comp_dai()\nwill miscalculate the ALH device count, causing broken audio.\n\nThe correct fix is to harden the matching logic by making sure that the\n1. widget is a DAI widget - so dai = w-\u0026gt;private is valid\n2. the dai (and thus the copier) is ALH copier(CVE-2025-21870)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntee: optee: Fix supplicant wait loop\n\nOP-TEE supplicant is a user-space daemon and it\u0026apos;s possible for it\nbe hung or crashed or killed in the middle of processing an OP-TEE\nRPC call. It becomes more complicated when there is incorrect shutdown\nordering of the supplicant process vs the OP-TEE client application which\ncan eventually lead to system hang-up waiting for the closure of the\nclient application.\n\nAllow the client process waiting in kernel for supplicant response to\nbe killed rather than indefinitely waiting in an unkillable state. Also,\na normal uninterruptible wait should not have resulted in the hung-task\nwatchdog getting triggered, but the endless loop would.\n\nThis fixes issues observed during system reboot/shutdown when supplicant\ngot hung for some reason or gets crashed/killed which lead to client\ngetting hung in an unkillable state. It in turn lead to system being in\nhung up state requiring hard power off/on to recover.(CVE-2025-21871)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: bsg: Fix crash when arpmb command fails\n\nIf the device doesn\u0026apos;t support arpmb we\u0026apos;ll crash due to copying user data in\nbsg_transport_sg_io_fn().\n\nIn the case where ufs_bsg_exec_advanced_rpmb_req() returns an error, do not\nset the job\u0026apos;s reply_len.\n\nMemory crash backtrace:\n3,1290,531166405,-;ufshcd 0000:00:12.5: ARPMB OP failed: error code -22\n\n4,1308,531166555,-;Call Trace:\n\n4,1309,531166559,-; \u0026lt;TASK\u0026gt;\n\n4,1310,531166565,-; ? show_regs+0x6d/0x80\n\n4,1311,531166575,-; ? die+0x37/0xa0\n\n4,1312,531166583,-; ? do_trap+0xd4/0xf0\n\n4,1313,531166593,-; ? do_error_trap+0x71/0xb0\n\n4,1314,531166601,-; ? usercopy_abort+0x6c/0x80\n\n4,1315,531166610,-; ? exc_invalid_op+0x52/0x80\n\n4,1316,531166622,-; ? usercopy_abort+0x6c/0x80\n\n4,1317,531166630,-; ? asm_exc_invalid_op+0x1b/0x20\n\n4,1318,531166643,-; ? usercopy_abort+0x6c/0x80\n\n4,1319,531166652,-; __check_heap_object+0xe3/0x120\n\n4,1320,531166661,-; check_heap_object+0x185/0x1d0\n\n4,1321,531166670,-; __check_object_size.part.0+0x72/0x150\n\n4,1322,531166679,-; __check_object_size+0x23/0x30\n\n4,1323,531166688,-; bsg_transport_sg_io_fn+0x314/0x3b0(CVE-2025-21873)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: gl620a: fix endpoint checking in genelink_bind()\n\nSyzbot reports [1] a warning in usb_submit_urb() triggered by\ninconsistencies between expected and actually present endpoints\nin gl620a driver. Since genelink_bind() does not properly\nverify whether specified eps are in fact provided by the device,\nin this case, an artificially manufactured one, one may get a\nmismatch.\n\nFix the issue by resorting to a usbnet utility function\nusbnet_get_endpoints(), usually reserved for this very problem.\nCheck for endpoints and return early before proceeding further if\nany are missing.\n\n[1] Syzbot report:\nusb 5-1: Manufacturer: syz\nusb 5-1: SerialNumber: syz\nusb 5-1: config 0 descriptor??\ngl620a 5-1:0.23 usb0: register \u0026apos;gl620a\u0026apos; at usb-dummy_hcd.0-1, ...\n------------[ cut here ]------------\nusb 5-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503\nModules linked in:\nCPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nWorkqueue: mld mld_ifc_work\nRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467\n __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n xmit_one net/core/dev.c:3590 [inline]\n dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606\n sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343\n __dev_xmit_skb net/core/dev.c:3827 [inline]\n __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n neigh_resolve_output net/core/neighbour.c:1514 [inline]\n neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494\n neigh_output include/net/neighbour.h:539 [inline]\n ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141\n __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]\n ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226\n NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247\n dst_output include/net/dst.h:450 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n NF_HOOK include/linux/netfilter.h:308 [inline]\n mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819\n mld_send_cr net/ipv6/mcast.c:2120 [inline]\n mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651\n process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229\n process_scheduled_works kernel/workqueue.c:3310 [inline]\n worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391\n kthread+0x2c1/0x3a0 kernel/kthread.c:389\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;(CVE-2025-21877)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: npcm: disable interrupt enable bit before devm_request_irq\n\nThe customer reports that there is a soft lockup issue related to\nthe i2c driver. After checking, the i2c module was doing a tx transfer\nand the bmc machine reboots in the middle of the i2c transaction, the i2c\nmodule keeps the status without being reset.\n\nDue to such an i2c module status, the i2c irq handler keeps getting\ntriggered since the i2c irq handler is registered in the kernel booting\nprocess after the bmc machine is doing a warm rebooting.\nThe continuous triggering is stopped by the soft lockup watchdog timer.\n\nDisable the interrupt enable bit in the i2c module before calling\ndevm_request_irq to fix this issue since the i2c relative status bit\nis read-only.\n\nHere is the soft lockup log.\n[   28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1]\n[   28.183351] Modules linked in:\n[   28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1\n[   28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   28.208128] pc : __do_softirq+0xb0/0x368\n[   28.212055] lr : __do_softirq+0x70/0x368\n[   28.215972] sp : ffffff8035ebca00\n[   28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780\n[   28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0\n[   28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b\n[   28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff\n[   28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000\n[   28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2\n[   28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250\n[   28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434\n[   28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198\n[   28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40\n[   28.290611] Call trace:\n[   28.293052]  __do_softirq+0xb0/0x368\n[   28.296625]  __irq_exit_rcu+0xe0/0x100\n[   28.300374]  irq_exit+0x14/0x20\n[   28.303513]  handle_domain_irq+0x68/0x90\n[   28.307440]  gic_handle_irq+0x78/0xb0\n[   28.311098]  call_on_irq_stack+0x20/0x38\n[   28.315019]  do_interrupt_handler+0x54/0x5c\n[   28.319199]  el1_interrupt+0x2c/0x4c\n[   28.322777]  el1h_64_irq_handler+0x14/0x20\n[   28.326872]  el1h_64_irq+0x74/0x78\n[   28.330269]  __setup_irq+0x454/0x780\n[   28.333841]  request_threaded_irq+0xd0/0x1b4\n[   28.338107]  devm_request_threaded_irq+0x84/0x100\n[   28.342809]  npcm_i2c_probe_bus+0x188/0x3d0\n[   28.346990]  platform_probe+0x6c/0xc4\n[   28.350653]  really_probe+0xcc/0x45c\n[   28.354227]  __driver_probe_device+0x8c/0x160\n[   28.358578]  driver_probe_device+0x44/0xe0\n[   28.362670]  __driver_attach+0x124/0x1d0\n[   28.366589]  bus_for_each_dev+0x7c/0xe0\n[   28.370426]  driver_attach+0x28/0x30\n[   28.373997]  bus_add_driver+0x124/0x240\n[   28.377830]  driver_register+0x7c/0x124\n[   28.381662]  __platform_driver_register+0x2c/0x34\n[   28.386362]  npcm_i2c_init+0x3c/0x5c\n[   28.389937]  do_one_initcall+0x74/0x230\n[   28.393768]  kernel_init_freeable+0x24c/0x2b4\n[   28.398126]  kernel_init+0x28/0x130\n[   28.401614]  ret_from_fork+0x10/0x20\n[   28.405189] Kernel panic - not syncing: softlockup: hung tasks\n[   28.411011] SMP: stopping secondary CPUs\n[   28.414933] Kernel Offset: disabled\n[   28.418412] CPU features: 0x00000000,00000802\n[   28.427644] Rebooting in 20 seconds..(CVE-2025-21878)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuprobes: Reject the shared zeropage in uprobe_write_opcode()\n\nWe triggered the following crash in syzkaller tests:\n\n  BUG: Bad page state in process syz.7.38  pfn:1eff3\n  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3\n  flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)\n  raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000\n  raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000\n  page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x32/0x50\n   bad_page+0x69/0xf0\n   free_unref_page_prepare+0x401/0x500\n   free_unref_page+0x6d/0x1b0\n   uprobe_write_opcode+0x460/0x8e0\n   install_breakpoint.part.0+0x51/0x80\n   register_for_each_vma+0x1d9/0x2b0\n   __uprobe_register+0x245/0x300\n   bpf_uprobe_multi_link_attach+0x29b/0x4f0\n   link_create+0x1e2/0x280\n   __sys_bpf+0x75f/0xac0\n   __x64_sys_bpf+0x1a/0x30\n   do_syscall_64+0x56/0x100\n   entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\n   BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1\n\nThe following syzkaller test case can be used to reproduce:\n\n  r2 = creat(\u0026amp;(0x7f0000000000)=\u0026apos;./file0\\x00\u0026apos;, 0x8)\n  write$nbd(r2, \u0026amp;(0x7f0000000580)=ANY=[], 0x10)\n  r4 = openat(0xffffffffffffff9c, \u0026amp;(0x7f0000000040)=\u0026apos;./file0\\x00\u0026apos;, 0x42, 0x0)\n  mmap$IORING_OFF_SQ_RING(\u0026amp;(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)\n  r5 = userfaultfd(0x80801)\n  ioctl$UFFDIO_API(r5, 0xc018aa3f, \u0026amp;(0x7f0000000040)={0xaa, 0x20})\n  r6 = userfaultfd(0x80801)\n  ioctl$UFFDIO_API(r6, 0xc018aa3f, \u0026amp;(0x7f0000000140))\n  ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, \u0026amp;(0x7f0000000100)={{\u0026amp;(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})\n  ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, \u0026amp;(0x7f0000000000)={{\u0026amp;(0x7f0000ffd000/0x1000)=nil, 0x1000}})\n  r7 = bpf$PROG_LOAD(0x5, \u0026amp;(0x7f0000000140)={0x2, 0x3, \u0026amp;(0x7f0000000200)=ANY=[@ANYBLOB=\u0026quot;1800000000120000000000000000000095\u0026quot;], \u0026amp;(0x7f0000000000)=\u0026apos;GPL\\x00\u0026apos;, 0x7, 0x0, 0x0, 0x0, 0x0, \u0026apos;\\x00\u0026apos;, 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)\n  bpf$BPF_LINK_CREATE_XDP(0x1c, \u0026amp;(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={\u0026amp;(0x7f0000000080)=\u0026apos;./file0\\x00\u0026apos;, \u0026amp;(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)\n\nThe cause is that zero pfn is set to the PTE without increasing the RSS\ncount in mfill_atomic_pte_zeropage() and the refcount of zero folio does\nnot increase accordingly. Then, the operation on the same pfn is performed\nin uprobe_write_opcode()-\u0026gt;__replace_page() to unconditional decrease the\nRSS count and old_folio\u0026apos;s refcount.\n\nTherefore, two bugs are introduced:\n\n 1. The RSS count is incorrect, when process exit, the check_mm() report\n    error \u0026quot;Bad rss-count\u0026quot;.\n\n 2. The reserved folio (zero folio) is freed when folio-\u0026gt;refcount is zero,\n    then free_pages_prepare-\u0026gt;free_page_is_bad() report error\n    \u0026quot;Bad page state\u0026quot;.\n\nThere is more, the following warning could also theoretically be triggered:\n\n  __replace_page()\n    -\u0026gt; ...\n      -\u0026gt; folio_remove_rmap_pte()\n        -\u0026gt; VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)\n\nConsidering that uprobe hit on the zero folio is a very rare case, just\nreject zero old folio immediately after get_user_page_vma_remote().\n\n[ mingo: Cleaned up the changelog ](CVE-2025-21881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix deinitializing VF in error path\n\nIf ice_ena_vfs() fails after calling ice_create_vf_entries(), it frees\nall VFs without removing them from snapshot PF-VF mailbox list, leading\nto list corruption.\n\nReproducer:\n  devlink dev eswitch set $PF1_PCI mode switchdev\n  ip l s $PF1 up\n  ip l s $PF1 promisc on\n  sleep 1\n  echo 1 \u0026gt; /sys/class/net/$PF1/device/sriov_numvfs\n  sleep 1\n  echo 1 \u0026gt; /sys/class/net/$PF1/device/sriov_numvfs\n\nTrace (minimized):\n  list_add corruption. next-\u0026gt;prev should be prev (ffff8882e241c6f0), but was 0000000000000000. (next=ffff888455da1330).\n  kernel BUG at lib/list_debug.c:29!\n  RIP: 0010:__list_add_valid_or_report+0xa6/0x100\n   ice_mbx_init_vf_info+0xa7/0x180 [ice]\n   ice_initialize_vf_entry+0x1fa/0x250 [ice]\n   ice_sriov_configure+0x8d7/0x1520 [ice]\n   ? __percpu_ref_switch_mode+0x1b1/0x5d0\n   ? __pfx_ice_sriov_configure+0x10/0x10 [ice]\n\nSometimes a KASAN report can be seen instead with a similar stack trace:\n  BUG: KASAN: use-after-free in __list_add_valid_or_report+0xf1/0x100\n\nVFs are added to this list in ice_mbx_init_vf_info(), but only removed\nin ice_free_vfs(). Move the removing to ice_free_vf_entries(), which is\nalso being called in other places where VFs are being removed (including\nice_free_vfs() itself).(CVE-2025-21883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Fix the page details for the srq created by kernel consumers\n\nWhile using nvme target with use_srq on, below kernel panic is noticed.\n\n[  549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514)\n[  566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI\n..\n[  566.393799]  \u0026lt;TASK\u0026gt;\n[  566.393807]  ? __die_body+0x1a/0x60\n[  566.393823]  ? die+0x38/0x60\n[  566.393835]  ? do_trap+0xe4/0x110\n[  566.393847]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]\n[  566.393867]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]\n[  566.393881]  ? do_error_trap+0x7c/0x120\n[  566.393890]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]\n[  566.393911]  ? exc_divide_error+0x34/0x50\n[  566.393923]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]\n[  566.393939]  ? asm_exc_divide_error+0x16/0x20\n[  566.393966]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]\n[  566.393997]  bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re]\n[  566.394040]  bnxt_re_create_srq+0x335/0x3b0 [bnxt_re]\n[  566.394057]  ? srso_return_thunk+0x5/0x5f\n[  566.394068]  ? __init_swait_queue_head+0x4a/0x60\n[  566.394090]  ib_create_srq_user+0xa7/0x150 [ib_core]\n[  566.394147]  nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma]\n[  566.394174]  ? lock_release+0x22c/0x3f0\n[  566.394187]  ? srso_return_thunk+0x5/0x5f\n\nPage size and shift info is set only for the user space SRQs.\nSet page size and page shift for kernel space SRQs also.(CVE-2025-21885)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix a WARN during dereg_mr for DM type\n\nMemory regions (MR) of type DM (device memory) do not have an associated\numem.\n\nIn the __mlx5_ib_dereg_mr() -\u0026gt; mlx5_free_priv_descs() flow, the code\nincorrectly takes the wrong branch, attempting to call\ndma_unmap_single() on a DMA address that is not mapped.\n\nThis results in a WARN [1], as shown below.\n\nThe issue is resolved by properly accounting for the DM type and\nensuring the correct branch is selected in mlx5_free_priv_descs().\n\n[1]\nWARNING: CPU: 12 PID: 1346 at drivers/iommu/dma-iommu.c:1230 iommu_dma_unmap_page+0x79/0x90\nModules linked in: ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry ovelay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core\nCPU: 12 UID: 0 PID: 1346 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1631\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:iommu_dma_unmap_page+0x79/0x90\nCode: 2b 49 3b 29 72 26 49 3b 69 08 73 20 4d 89 f0 44 89 e9 4c 89 e2 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 07 b8 88 ff \u0026lt;0f\u0026gt; 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00\nRSP: 0018:ffffc90001913a10 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88810194b0a8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001\nRBP: ffff88810194b0a8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007f537abdd740(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f537aeb8000 CR3: 000000010c248001 CR4: 0000000000372eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n\u0026lt;TASK\u0026gt;\n? __warn+0x84/0x190\n? iommu_dma_unmap_page+0x79/0x90\n? report_bug+0xf8/0x1c0\n? handle_bug+0x55/0x90\n? exc_invalid_op+0x13/0x60\n? asm_exc_invalid_op+0x16/0x20\n? iommu_dma_unmap_page+0x79/0x90\ndma_unmap_page_attrs+0xe6/0x290\nmlx5_free_priv_descs+0xb0/0xe0 [mlx5_ib]\n__mlx5_ib_dereg_mr+0x37e/0x520 [mlx5_ib]\n? _raw_spin_unlock_irq+0x24/0x40\n? wait_for_completion+0xfe/0x130\n? rdma_restrack_put+0x63/0xe0 [ib_core]\nib_dereg_mr_user+0x5f/0x120 [ib_core]\n? lock_release+0xc6/0x280\ndestroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]\nuverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]\nuobj_destroy+0x3f/0x70 [ib_uverbs]\nib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]\n? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]\n? lock_acquire+0xc1/0x2f0\n? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]\n? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]\n? lock_release+0xc6/0x280\nib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]\n? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]\n__x64_sys_ioctl+0x1b0/0xa70\ndo_syscall_64+0x6b/0x140\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f537adaf17b\nCode: 0f 1e fa 48 8b 05 1d ad 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed ac 0c 00 f7 d8 64 89 01 48\nRSP: 002b:00007ffff218f0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007ffff218f1d8 RCX: 00007f537adaf17b\nRDX: 00007ffff218f1c0 RSI: 00000000c0181b01 RDI: 0000000000000003\nRBP: 00007ffff218f1a0 R08: 00007f537aa8d010 R09: 0000561ee2e4f270\nR10: 00007f537aace3a8 R11: 0000000000000246 R12: 00007ffff218f190\nR13: 000000000000001c R14: 0000561ee2e4d7c0 R15: 00007ffff218f450\n\u0026lt;/TASK\u0026gt;(CVE-2025-21888)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix the recovery flow of the UMR QP\n\nThis patch addresses an issue in the recovery flow of the UMR QP,\nensuring tasks do not get stuck, as highlighted by the call trace [1].\n\nDuring recovery, before transitioning the QP to the RESET state, the\nsoftware must wait for all outstanding WRs to complete.\n\nFailing to do so can cause the firmware to skip sending some flushed\nCQEs with errors and simply discard them upon the RESET, as per the IB\nspecification.\n\nThis race condition can result in lost CQEs and tasks becoming stuck.\n\nTo resolve this, the patch sends a final WR which serves only as a\nbarrier before moving the QP state to RESET.\n\nOnce a CQE is received for that final WR, it guarantees that no\noutstanding WRs remain, making it safe to transition the QP to RESET and\nsubsequently back to RTS, restoring proper functionality.\n\nNote:\nFor the barrier WR, we simply reuse the failed and ready WR.\nSince the QP is in an error state, it will only receive\nIB_WC_WR_FLUSH_ERR. However, as it serves only as a barrier we don\u0026apos;t\ncare about its status.\n\n[1]\nINFO: task rdma_resource_l:1922 blocked for more than 120 seconds.\nTainted: G        W          6.12.0-rc7+ #1626\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:rdma_resource_l state:D stack:0  pid:1922 tgid:1922  ppid:1369\n     flags:0x00004004\nCall Trace:\n\u0026lt;TASK\u0026gt;\n__schedule+0x420/0xd30\nschedule+0x47/0x130\nschedule_timeout+0x280/0x300\n? mark_held_locks+0x48/0x80\n? lockdep_hardirqs_on_prepare+0xe5/0x1a0\nwait_for_completion+0x75/0x130\nmlx5r_umr_post_send_wait+0x3c2/0x5b0 [mlx5_ib]\n? __pfx_mlx5r_umr_done+0x10/0x10 [mlx5_ib]\nmlx5r_umr_revoke_mr+0x93/0xc0 [mlx5_ib]\n__mlx5_ib_dereg_mr+0x299/0x520 [mlx5_ib]\n? _raw_spin_unlock_irq+0x24/0x40\n? wait_for_completion+0xfe/0x130\n? rdma_restrack_put+0x63/0xe0 [ib_core]\nib_dereg_mr_user+0x5f/0x120 [ib_core]\n? lock_release+0xc6/0x280\ndestroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]\nuverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]\nuobj_destroy+0x3f/0x70 [ib_uverbs]\nib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]\n? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]\n? __lock_acquire+0x64e/0x2080\n? mark_held_locks+0x48/0x80\n? find_held_lock+0x2d/0xa0\n? lock_acquire+0xc1/0x2f0\n? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]\n? __fget_files+0xc3/0x1b0\nib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]\n? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]\n__x64_sys_ioctl+0x1b0/0xa70\ndo_syscall_64+0x6b/0x140\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f99c918b17b\nRSP: 002b:00007ffc766d0468 EFLAGS: 00000246 ORIG_RAX:\n     0000000000000010\nRAX: ffffffffffffffda RBX: 00007ffc766d0578 RCX:\n     00007f99c918b17b\nRDX: 00007ffc766d0560 RSI: 00000000c0181b01 RDI:\n     0000000000000003\nRBP: 00007ffc766d0540 R08: 00007f99c8f99010 R09:\n     000000000000bd7e\nR10: 00007f99c94c1c70 R11: 0000000000000246 R12:\n     00007ffc766d0530\nR13: 000000000000001c R14: 0000000040246a80 R15:\n     0000000000000000\n\u0026lt;/TASK\u0026gt;(CVE-2025-21892)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Order the PMU list to fix warning about unordered pmu_ctx_list\n\nSyskaller triggers a warning due to prev_epc-\u0026gt;pmu != next_epc-\u0026gt;pmu in\nperf_event_swap_task_ctx_data(). vmcore shows that two lists have the same\nperf_event_pmu_context, but not in the same order.\n\nThe problem is that the order of pmu_ctx_list for the parent is impacted by\nthe time when an event/PMU is added. While the order for a child is\nimpacted by the event order in the pinned_groups and flexible_groups. So\nthe order of pmu_ctx_list in the parent and child may be different.\n\nTo fix this problem, insert the perf_event_pmu_context to its proper place\nafter iteration of the pmu_ctx_list.\n\nThe follow testcase can trigger above warning:\n\n # perf record -e cycles --call-graph lbr -- taskset -c 3 ./a.out \u0026amp;\n # perf stat -e cpu-clock,cs -p xxx // xxx is the pid of a.out\n\n test.c\n\n void main() {\n        int count = 0;\n        pid_t pid;\n\n        printf(\u0026quot;%d running\\n\u0026quot;, getpid());\n        sleep(30);\n        printf(\u0026quot;running\\n\u0026quot;);\n\n        pid = fork();\n        if (pid == -1) {\n                printf(\u0026quot;fork error\\n\u0026quot;);\n                return;\n        }\n        if (pid == 0) {\n                while (1) {\n                        count++;\n                }\n        } else {\n                while (1) {\n                        count++;\n                }\n        }\n }\n\nThe testcase first opens an LBR event, so it will allocate task_ctx_data,\nand then open tracepoint and software events, so the parent context will\nhave 3 different perf_event_pmu_contexts. On inheritance, child ctx will\ninsert the perf_event_pmu_context in another order and the warning will\ntrigger.\n\n[ mingo: Tidied up the changelog. ](CVE-2025-21895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Avoid potential division by zero in function_stat_show()\n\nCheck whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}\nproduce zero and skip stddev computation in that case.\n\nFor now don\u0026apos;t care about rec-\u0026gt;counter * rec-\u0026gt;counter overflow because\nrec-\u0026gt;time * rec-\u0026gt;time overflow will likely happen earlier.(CVE-2025-21898)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix bad hist from corrupting named_triggers list\n\nThe following commands causes a crash:\n\n ~# cd /sys/kernel/tracing/events/rcu/rcu_callback\n ~# echo \u0026apos;hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)\u0026apos; \u0026gt; trigger\n bash: echo: write error: Invalid argument\n ~# echo \u0026apos;hist:name=bad:keys=common_pid\u0026apos; \u0026gt; trigger\n\nBecause the following occurs:\n\nevent_trigger_write() {\n  trigger_process_regex() {\n    event_hist_trigger_parse() {\n\n      data = event_trigger_alloc(..);\n\n      event_trigger_register(.., data) {\n        cmd_ops-\u0026gt;reg(.., data, ..) [hist_register_trigger()] {\n          data-\u0026gt;ops-\u0026gt;init() [event_hist_trigger_init()] {\n            save_named_trigger(name, data) {\n              list_add(\u0026amp;data-\u0026gt;named_list, \u0026amp;named_triggers);\n            }\n          }\n        }\n      }\n\n      ret = create_actions(); (return -EINVAL)\n      if (ret)\n        goto out_unreg;\n[..]\n      ret = hist_trigger_enable(data, ...) {\n        list_add_tail_rcu(\u0026amp;data-\u0026gt;list, \u0026amp;file-\u0026gt;triggers); \u0026lt;\u0026lt;\u0026lt;---- SKIPPED!!! (this is important!)\n[..]\n out_unreg:\n      event_hist_unregister(.., data) {\n        cmd_ops-\u0026gt;unreg(.., data, ..) [hist_unregister_trigger()] {\n          list_for_each_entry(iter, \u0026amp;file-\u0026gt;triggers, list) {\n            if (!hist_trigger_match(data, iter, named_data, false))   \u0026lt;- never matches\n                continue;\n            [..]\n            test = iter;\n          }\n          if (test \u0026amp;\u0026amp; test-\u0026gt;ops-\u0026gt;free) \u0026lt;\u0026lt;\u0026lt;-- test is NULL\n\n            test-\u0026gt;ops-\u0026gt;free(test) [event_hist_trigger_free()] {\n              [..]\n              if (data-\u0026gt;name)\n                del_named_trigger(data) {\n                  list_del(\u0026amp;data-\u0026gt;named_list);  \u0026lt;\u0026lt;\u0026lt;\u0026lt;-- NEVER gets removed!\n                }\n              }\n           }\n         }\n\n         [..]\n         kfree(data); \u0026lt;\u0026lt;\u0026lt;-- frees item but it is still on list\n\nThe next time a hist with name is registered, it causes an u-a-f bug and\nthe kernel can crash.\n\nMove the code around such that if event_trigger_register() succeeds, the\nnext thing called is hist_trigger_enable() which adds it to the list.\n\nA bunch of actions is called if get_named_trigger_data() returns false.\nBut that doesn\u0026apos;t need to be called after event_trigger_register(), so it\ncan be moved up, allowing event_trigger_register() to be called just\nbefore hist_trigger_enable() keeping them together and allowing the\nfile-\u0026gt;triggers to be properly populated.(CVE-2025-21899)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: regulatory: improve invalid hints checking\n\nSyzbot keeps reporting an issue [1] that occurs when erroneous symbols\nsent from userspace get through into user_alpha2[] via\nregulatory_hint_user() call. Such invalid regulatory hints should be\nrejected.\n\nWhile a sanity check from commit 47caf685a685 (\u0026quot;cfg80211: regulatory:\nreject invalid hints\u0026quot;) looks to be enough to deter these very cases,\nthere is a way to get around it due to 2 reasons.\n\n1) The way isalpha() works, symbols other than latin lower and\nupper letters may be used to determine a country/domain.\nFor instance, greek letters will also be considered upper/lower\nletters and for such characters isalpha() will return true as well.\nHowever, ISO-3166-1 alpha2 codes should only hold latin\ncharacters.\n\n2) While processing a user regulatory request, between\nreg_process_hint_user() and regulatory_hint_user() there happens to\nbe a call to queue_regulatory_request() which modifies letters in\nrequest-\u0026gt;alpha2[] with toupper(). This works fine for latin symbols,\nless so for weird letter characters from the second part of _ctype[].\n\nSyzbot triggers a warning in is_user_regdom_saved() by first sending\nover an unexpected non-latin letter that gets malformed by toupper()\ninto a character that ends up failing isalpha() check.\n\nPrevent this by enhancing is_an_alpha2() to ensure that incoming\nsymbols are latin letters and nothing else.\n\n[1] Syzbot report:\n------------[ cut here ]------------\nUnexpected user alpha2: A�\nWARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]\nWARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]\nWARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516\nModules linked in:\nCPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nWorkqueue: events_power_efficient crda_timeout_work\nRIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]\nRIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]\nRIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n crda_timeout_work+0x27/0x50 net/wireless/reg.c:542\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310\n worker_thread+0x870/0xd30 kernel/workqueue.c:3391\n kthread+0x2f2/0x390 kernel/kthread.c:389\n ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;(CVE-2025-21910)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nslimbus: messaging: Free transaction ID in delayed interrupt scenario\n\nIn case of interrupt delay for any reason, slim_do_transfer()\nreturns timeout error but the transaction ID (TID) is not freed.\nThis results into invalid memory access inside\nqcom_slim_ngd_rx_msgq_cb() due to invalid TID.\n\nFix the issue by freeing the TID in slim_do_transfer() before\nreturning timeout error to avoid invalid memory access.\n\nCall trace:\n__memcpy_fromio+0x20/0x190\nqcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]\nvchan_complete+0x2a0/0x4a0\ntasklet_action_common+0x274/0x700\ntasklet_action+0x28/0x3c\n_stext+0x188/0x620\nrun_ksoftirqd+0x34/0x74\nsmpboot_thread_fn+0x1d8/0x464\nkthread+0x178/0x238\nret_from_fork+0x10/0x20\nCode: aa0003e8 91000429 f100044a 3940002b (3800150b)\n---[ end trace 0fe00bec2b975c99 ]---\nKernel panic - not syncing: Oops: Fatal exception in interrupt.(CVE-2025-21914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hid-steam: Fix use-after-free when detaching device\n\nWhen a hid-steam device is removed it must clean up the client_hdev used for\nintercepting hidraw access. This can lead to scheduling deferred work to\nreattach the input device. Though the cleanup cancels the deferred work, this\nwas done before the client_hdev itself is cleaned up, so it gets rescheduled.\nThis patch fixes the ordering to make sure the deferred work is properly\ncanceled.(CVE-2025-21923)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()\n\nnvme_tcp_recv_pdu() doesn\u0026apos;t check the validity of the header length.\nWhen header digests are enabled, a target might send a packet with an\ninvalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()\nto access memory outside the allocated area and cause memory corruptions\nby overwriting it with the calculated digest.\n\nFix this by rejecting packets with an unexpected header length.(CVE-2025-21927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()\n\nThe system can experience a random crash a few minutes after the driver is\nremoved. This issue occurs due to improper handling of memory freeing in\nthe ishtp_hid_remove() function.\n\nThe function currently frees the `driver_data` directly within the loop\nthat destroys the HID devices, which can lead to accessing freed memory.\nSpecifically, `hid_destroy_device()` uses `driver_data` when it calls\n`hid_ishtp_set_feature()` to power off the sensor, so freeing\n`driver_data` beforehand can result in accessing invalid memory.\n\nThis patch resolves the issue by storing the `driver_data` in a temporary\nvariable before calling `hid_destroy_device()`, and then freeing the\n`driver_data` after the device is destroyed.(CVE-2025-21928)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrapidio: add check for rio_add_net() in rio_scan_alloc_net()\n\nThe return value of rio_add_net() should be checked.  If it fails,\nput_device() should be called to free the memory and give up the reference\ninitialized in rio_add_net().(CVE-2025-21935)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix null check for pipe_ctx-\u0026gt;plane_state in resource_build_scaling_params\n\nNull pointer dereference issue could occur when pipe_ctx-\u0026gt;plane_state\nis null. The fix adds a check to ensure \u0026apos;pipe_ctx-\u0026gt;plane_state\u0026apos; is not\nnull before accessing. This prevents a null pointer dereference.\n\nFound by code review.\n\n(cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)(CVE-2025-21941)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpio: aggregator: protect driver attr handlers against module unload\n\nBoth new_device_store and delete_device_store touch module global\nresources (e.g. gpio_aggregator_lock). To prevent race conditions with\nmodule unload, a reference needs to be held.\n\nAdd try_module_get() in these handlers.\n\nFor new_device_store, this eliminates what appears to be the most dangerous\nscenario: if an id is allocated from gpio_aggregator_idr but\nplatform_device_register has not yet been called or completed, a concurrent\nmodule unload could fail to unregister/delete the device, leaving behind a\ndangling platform device/GPIO forwarder. This can result in various issues.\nThe following simple reproducer demonstrates these problems:\n\n  #!/bin/bash\n  while :; do\n    # note: whether \u0026apos;gpiochip0 0\u0026apos; exists or not does not matter.\n    echo \u0026apos;gpiochip0 0\u0026apos; \u0026gt; /sys/bus/platform/drivers/gpio-aggregator/new_device\n  done \u0026amp;\n  while :; do\n    modprobe gpio-aggregator\n    modprobe -r gpio-aggregator\n  done \u0026amp;\n  wait\n\n  Starting with the following warning, several kinds of warnings will appear\n  and the system may become unstable:\n\n  ------------[ cut here ]------------\n  list_del corruption, ffff888103e2e980-\u0026gt;next is LIST_POISON1 (dead000000000100)\n  WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120\n  [...]\n  RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120\n  [...]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __list_del_entry_valid_or_report+0xa3/0x120\n   ? __warn.cold+0x93/0xf2\n   ? __list_del_entry_valid_or_report+0xa3/0x120\n   ? report_bug+0xe6/0x170\n   ? __irq_work_queue_local+0x39/0xe0\n   ? handle_bug+0x58/0x90\n   ? exc_invalid_op+0x13/0x60\n   ? asm_exc_invalid_op+0x16/0x20\n   ? __list_del_entry_valid_or_report+0xa3/0x120\n   gpiod_remove_lookup_table+0x22/0x60\n   new_device_store+0x315/0x350 [gpio_aggregator]\n   kernfs_fop_write_iter+0x137/0x1f0\n   vfs_write+0x262/0x430\n   ksys_write+0x60/0xd0\n   do_syscall_64+0x6c/0x180\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   [...]\n   \u0026lt;/TASK\u0026gt;\n  ---[ end trace 0000000000000000 ]---(CVE-2025-21943)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix out-of-bounds in parse_sec_desc()\n\nIf osidoffset, gsidoffset and dacloffset could be greater than smb_ntsd\nstruct size. If it is smaller, It could cause slab-out-of-bounds.\nAnd when validating sid, It need to check it included subauth array size.(CVE-2025-21946)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Set hugetlb mmap base address aligned with pmd size\n\nWith ltp test case \u0026quot;testcases/bin/hugefork02\u0026quot;, there is a dmesg error\nreport message such as:\n\n kernel BUG at mm/hugetlb.c:5550!\n Oops - BUG[#1]:\n CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241\n Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022\n pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940\n a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000\n a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000\n t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000\n t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001\n t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280\n s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10\n s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08\n    ra: 9000000000485538 unmap_vmas+0x130/0x218\n   ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0\n  PRMD: 00000004 (PPLV0 +PIE -PWE)\n  EUEN: 00000007 (+FPE +SXE +ASXE -BTE)\n  ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)\n ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)\n PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)\n Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64)\n Call Trace:\n [\u0026lt;90000000004eaf1c\u0026gt;] __unmap_hugepage_range+0x6f4/0x7d0\n [\u0026lt;9000000000485534\u0026gt;] unmap_vmas+0x12c/0x218\n [\u0026lt;9000000000494068\u0026gt;] exit_mmap+0xe0/0x308\n [\u0026lt;900000000025fdc4\u0026gt;] mmput+0x74/0x180\n [\u0026lt;900000000026a284\u0026gt;] do_exit+0x294/0x898\n [\u0026lt;900000000026aa30\u0026gt;] do_group_exit+0x30/0x98\n [\u0026lt;900000000027bed4\u0026gt;] get_signal+0x83c/0x868\n [\u0026lt;90000000002457b4\u0026gt;] arch_do_signal_or_restart+0x54/0xfa0\n [\u0026lt;90000000015795e8\u0026gt;] irqentry_exit_to_user_mode+0xb8/0x138\n [\u0026lt;90000000002572d0\u0026gt;] tlb_do_page_fault_1+0x114/0x1b4\n\nThe problem is that base address allocated from hugetlbfs is not aligned\nwith pmd size. Here add a checking for hugetlbfs and align base address\nwith pmd size. After this patch the test case \u0026quot;testcases/bin/hugefork02\u0026quot;\npasses to run.\n\nThis is similar to the commit 7f24cbc9c4d42db8a3c8484d1 (\u0026quot;mm/mmap: teach\ngeneric_get_unmapped_area{_topdown} to handle hugetlb mappings\u0026quot;).(CVE-2025-21949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix integer overflow while processing acdirmax mount option\n\nUser-provided mount parameter acdirmax of type u32 is intended to have\nan upper limit, but before it is validated, the value is converted from\nseconds to jiffies which can lead to an integer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21963)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix integer overflow while processing acregmax mount option\n\nUser-provided mount parameter acregmax of type u32 is intended to have\nan upper limit, but before it is validated, the value is converted from\nseconds to jiffies which can lead to an integer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21964)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: hyperv_fb: Allow graceful removal of framebuffer\n\nWhen a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to\nrelease the framebuffer forcefully. If this framebuffer is in use it\nproduce the following WARN and hence this framebuffer is never released.\n\n[   44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40\n\u0026lt; snip \u0026gt;\n[   44.111289] Call Trace:\n[   44.111290]  \u0026lt;TASK\u0026gt;\n[   44.111291]  ? show_regs+0x6c/0x80\n[   44.111295]  ? __warn+0x8d/0x150\n[   44.111298]  ? framebuffer_release+0x2c/0x40\n[   44.111300]  ? report_bug+0x182/0x1b0\n[   44.111303]  ? handle_bug+0x6e/0xb0\n[   44.111306]  ? exc_invalid_op+0x18/0x80\n[   44.111308]  ? asm_exc_invalid_op+0x1b/0x20\n[   44.111311]  ? framebuffer_release+0x2c/0x40\n[   44.111313]  ? hvfb_remove+0x86/0xa0 [hyperv_fb]\n[   44.111315]  vmbus_remove+0x24/0x40 [hv_vmbus]\n[   44.111323]  device_remove+0x40/0x80\n[   44.111325]  device_release_driver_internal+0x20b/0x270\n[   44.111327]  ? bus_find_device+0xb3/0xf0\n\nFix this by moving the release of framebuffer and assosiated memory\nto fb_ops.fb_destroy function, so that framebuffer framework handles\nit gracefully.\n\nWhile we fix this, also replace manual registrations/unregistration of\nframebuffer with devm_register_framebuffer.(CVE-2025-21976)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/hyperv: Fix address space leak when Hyper-V DRM device is removed\n\nWhen a Hyper-V DRM device is probed, the driver allocates MMIO space for\nthe vram, and maps it cacheable. If the device removed, or in the error\npath for device probing, the MMIO space is released but no unmap is done.\nConsequently the kernel address space for the mapping is leaked.\n\nFix this by adding iounmap() calls in the device removal path, and in the\nerror path during device probing.(CVE-2025-21978)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()\n\nWhen performing an iSCSI boot using IPv6, iscsistart still reads the\n/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix\nlength is 64, this causes the shift exponent to become negative,\ntriggering a UBSAN warning. As the concept of a subnet mask does not\napply to IPv6, the value is set to ~0 to suppress the warning message.(CVE-2025-21993)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix incorrect validation for num_aces field of smb_acl\n\nparse_dcal() validate num_aces to allocate posix_ace_state_array.\n\nif (num_aces \u0026gt; ULONG_MAX / sizeof(struct smb_ace *))\n\nIt is an incorrect validation that we can create an array of size ULONG_MAX.\nsmb_acl has -\u0026gt;size field to calculate actual number of aces in request buffer\nsize. Use this to check invalid num_aces.(CVE-2025-21994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nproc: fix UAF in proc_get_inode()\n\nFix race between rmmod and /proc/XXX\u0026apos;s inode instantiation.\n\nThe bug is that pde-\u0026gt;proc_ops don\u0026apos;t belong to /proc, it belongs to a\nmodule, therefore dereferencing it after /proc entry has been registered\nis a bug unless use_pde/unuse_pde() pair has been used.\n\nuse_pde/unuse_pde can be avoided (2 atomic ops!) because pde-\u0026gt;proc_ops\nnever changes so information necessary for inode instantiation can be\nsaved _before_ proc_register() in PDE itself and used later, avoiding\npde-\u0026gt;proc_ops-\u0026gt;...  dereference.\n\n      rmmod                         lookup\nsys_delete_module\n                         proc_lookup_de\n\t\t\t   pde_get(de);\n\t\t\t   proc_get_inode(dir-\u0026gt;i_sb, de);\n  mod-\u0026gt;exit()\n    proc_remove\n      remove_proc_subtree\n       proc_entry_rundown(de);\n  free_module(mod);\n\n                               if (S_ISREG(inode-\u0026gt;i_mode))\n\t                         if (de-\u0026gt;proc_ops-\u0026gt;proc_read_iter)\n                           --\u0026gt; As module is already freed, will trigger UAF\n\nBUG: unable to handle page fault for address: fffffbfff80a702b\nPGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nRIP: 0010:proc_get_inode+0x302/0x6e0\nRSP: 0018:ffff88811c837998 EFLAGS: 00010a06\nRAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007\nRDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158\nRBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20\nR10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0\nR13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001\nFS:  00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n proc_lookup_de+0x11f/0x2e0\n __lookup_slow+0x188/0x350\n walk_component+0x2ab/0x4f0\n path_lookupat+0x120/0x660\n filename_lookup+0x1ce/0x560\n vfs_statx+0xac/0x150\n __do_sys_newstat+0x96/0x110\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n[adobriyan@gmail.com: don\u0026apos;t do 2 atomic ops on the common path](CVE-2025-21999)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: check that dummy regulator has been probed before using it\n\nDue to asynchronous driver probing there is a chance that the dummy\nregulator hasn\u0026apos;t already been probed when first accessing it.(CVE-2025-22008)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state\n\nThere are several problems with the way hyp code lazily saves the host\u0026apos;s\nFPSIMD/SVE state, including:\n\n* Host SVE being discarded unexpectedly due to inconsistent\n  configuration of TIF_SVE and CPACR_ELx.ZEN. This has been seen to\n  result in QEMU crashes where SVE is used by memmove(), as reported by\n  Eric Auger:\n\n  https://issues.redhat.com/browse/RHEL-68997\n\n* Host SVE state is discarded *after* modification by ptrace, which was an\n  unintentional ptrace ABI change introduced with lazy discarding of SVE state.\n\n* The host FPMR value can be discarded when running a non-protected VM,\n  where FPMR support is not exposed to a VM, and that VM uses\n  FPSIMD/SVE. In these cases the hyp code does not save the host\u0026apos;s FPMR\n  before unbinding the host\u0026apos;s FPSIMD/SVE/SME state, leaving a stale\n  value in memory.\n\nAvoid these by eagerly saving and \u0026quot;flushing\u0026quot; the host\u0026apos;s FPSIMD/SVE/SME\nstate when loading a vCPU such that KVM does not need to save any of the\nhost\u0026apos;s FPSIMD/SVE/SME state. For clarity, fpsimd_kvm_prepare() is\nremoved and the necessary call to fpsimd_save_and_flush_cpu_state() is\nplaced in kvm_arch_vcpu_load_fp(). As \u0026apos;fpsimd_state\u0026apos; and \u0026apos;fpmr_ptr\u0026apos;\nshould not be used, they are set to NULL; all uses of these will be\nremoved in subsequent patches.\n\nHistorical problems go back at least as far as v5.17, e.g. erroneous\nassumptions about TIF_SVE being clear in commit:\n\n  8383741ab2e773a9 (\u0026quot;KVM: arm64: Get rid of host SVE tracking/saving\u0026quot;)\n\n... and so this eager save+flush probably needs to be backported to ALL\nstable trees.(CVE-2025-22013)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix use-after-free in print_graph_function_flags during tracer switching\n\nKairui reported a UAF issue in print_graph_function_flags() during\nftrace stress testing [1]. This issue can be reproduced if puting a\n\u0026apos;mdelay(10)\u0026apos; after \u0026apos;mutex_unlock(\u0026amp;trace_types_lock)\u0026apos; in s_start(),\nand executing the following script:\n\n  $ echo function_graph \u0026gt; current_tracer\n  $ cat trace \u0026gt; /dev/null \u0026amp;\n  $ sleep 5  # Ensure the \u0026apos;cat\u0026apos; reaches the \u0026apos;mdelay(10)\u0026apos; point\n  $ echo timerlat \u0026gt; current_tracer\n\nThe root cause lies in the two calls to print_graph_function_flags\nwithin print_trace_line during each s_show():\n\n  * One through \u0026apos;iter-\u0026gt;trace-\u0026gt;print_line()\u0026apos;;\n  * Another through \u0026apos;event-\u0026gt;funcs-\u0026gt;trace()\u0026apos;, which is hidden in\n    print_trace_fmt() before print_trace_line returns.\n\nTracer switching only updates the former, while the latter continues\nto use the print_line function of the old tracer, which in the script\nabove is print_graph_function_flags.\n\nMoreover, when switching from the \u0026apos;function_graph\u0026apos; tracer to the\n\u0026apos;timerlat\u0026apos; tracer, s_start only calls graph_trace_close of the\n\u0026apos;function_graph\u0026apos; tracer to free \u0026apos;iter-\u0026gt;private\u0026apos;, but does not set\nit to NULL. This provides an opportunity for \u0026apos;event-\u0026gt;funcs-\u0026gt;trace()\u0026apos;\nto use an invalid \u0026apos;iter-\u0026gt;private\u0026apos;.\n\nTo fix this issue, set \u0026apos;iter-\u0026gt;private\u0026apos; to NULL immediately after\nfreeing it in graph_trace_close(), ensuring that an invalid pointer\nis not passed to other tracers. Additionally, clean up the unnecessary\n\u0026apos;iter-\u0026gt;private = NULL\u0026apos; during each \u0026apos;cat trace\u0026apos; when using wakeup and\nirqsoff tracers.\n\n [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/(CVE-2025-22035)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: validate zero num_subauth before sub_auth is accessed\n\nAccess psid-\u0026gt;sub_auth[psid-\u0026gt;num_subauth - 1] without checking\nif num_subauth is non-zero leads to an out-of-bounds read.\nThis patch adds a validation step to ensure num_subauth != 0\nbefore sub_auth is accessed.(CVE-2025-22038)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Increase ARCH_DMA_MINALIGN up to 16\n\nARCH_DMA_MINALIGN is 1 by default, but some LoongArch-specific devices\n(such as APBDMA) require 16 bytes alignment. When the data buffer length\nis too small, the hardware may make an error writing cacheline. Thus, it\nis dangerous to allocate a small memory buffer for DMA. It\u0026apos;s always safe\nto define ARCH_DMA_MINALIGN as L1_CACHE_BYTES but unnecessary (kmalloc()\nneed small memory objects). Therefore, just increase it to 16.(CVE-2025-22049)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: imx-card: Add NULL check in imx_card_probe()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\nimx_card_probe() does not check for this case, which results in a NULL\npointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue.(CVE-2025-22066)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: goto right label \u0026apos;out_mmap_sem\u0026apos; in ext4_setattr()\n\nOtherwise, if ext4_inode_attach_jinode() fails, a hung task will\nhappen because filemap_invalidate_unlock() isn\u0026apos;t called to unlock\nmapping-\u0026gt;invalidate_lock. Like this:\n\nEXT4-fs error (device sda) in ext4_setattr:5557: Out of memory\nINFO: task fsstress:374 blocked for more than 122 seconds.\n      Not tainted 6.14.0-rc1-next-20250206-xfstests-dirty #726\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:fsstress state:D stack:0     pid:374   tgid:374   ppid:373\n                                  task_flags:0x440140 flags:0x00000000\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __schedule+0x2c9/0x7f0\n schedule+0x27/0xa0\n schedule_preempt_disabled+0x15/0x30\n rwsem_down_read_slowpath+0x278/0x4c0\n down_read+0x59/0xb0\n page_cache_ra_unbounded+0x65/0x1b0\n filemap_get_pages+0x124/0x3e0\n filemap_read+0x114/0x3d0\n vfs_read+0x297/0x360\n ksys_read+0x6c/0xe0\n do_syscall_64+0x4b/0x110\n entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-22120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nthermal: int340x: Add NULL check for adev\n\nNot all devices have an ACPI companion fwnode, so adev might be NULL.\nThis is similar to the commit cd2fd6eab480\n(\u0026quot;platform/x86: int3472: Check for adev == NULL\u0026quot;).\n\nAdd a check for adev not being set and return -ENODEV in that case to\navoid a possible NULL pointer deref in int3402_thermal_probe().\n\nNote, under the same directory, int3400_thermal_probe() has such a\ncheck.\n\n[ rjw: Subject edit, added Fixes: ](CVE-2025-23136)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: dp: drm_err =\u0026gt; dev_err in HPD path to avoid NULL ptr\n\nThe function mtk_dp_wait_hpd_asserted() may be called before the\n`mtk_dp-\u0026gt;drm_dev` pointer is assigned in mtk_dp_bridge_attach().\nSpecifically it can be called via this callpath:\n - mtk_edp_wait_hpd_asserted\n - [panel probe]\n - dp_aux_ep_probe\n\nUsing \u0026quot;drm\u0026quot; level prints anywhere in this callpath causes a NULL\npointer dereference. Change the error message directly in\nmtk_dp_wait_hpd_asserted() to dev_err() to avoid this. Also change the\nerror messages in mtk_dp_parse_capabilities(), which is called by\nmtk_dp_wait_hpd_asserted().\n\nWhile touching these prints, also add the error code to them to make\nfuture debugging easier.(CVE-2025-38240)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-87.0.0.93.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","kernel-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","perf-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-87.0.0.93.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-87.0.0.93.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","kernel-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","perf-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-87.0.0.93.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1446"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53034"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-52559"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-52560"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53162"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53179"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-54458"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-55881"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56616"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56664"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56710"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57795"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57857"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57908"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57911"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57912"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57929"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57952"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57996"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57999"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58002"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58003"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58007"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58009"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58011"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58013"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58014"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58016"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58017"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58076"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58079"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58083"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58086"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58088"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58090"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21636"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21637"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21638"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21640"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21665"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21666"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21669"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21675"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21690"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21692"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21697"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21700"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21701"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21709"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21712"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21721"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21735"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21739"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21741"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21742"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21744"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21746"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21748"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21749"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21753"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21758"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21759"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21760"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21761"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21762"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21763"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21764"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21765"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21766"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21772"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21773"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21775"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21779"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21780"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21781"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21784"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21790"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21792"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21793"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21821"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21826"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21830"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21831"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21835"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21836"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21838"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21847"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21848"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21855"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21857"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21858"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21859"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21862"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21866"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21867"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21870"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21871"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21873"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21877"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21878"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21881"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21883"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21885"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21888"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21892"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21895"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21898"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21899"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21910"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21914"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21923"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21927"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21928"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21935"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21941"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21943"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21946"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21949"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21963"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21964"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21976"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21978"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21993"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21994"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21999"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22008"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22013"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22035"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22038"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22049"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22066"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22120"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23136"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38240"}],"database_specific":{"severity":"High"}}