{"schema_version":"1.7.2","id":"OESA-2025-1729","modified":"2025-07-04T14:43:27Z","published":"2025-07-04T14:43:27Z","upstream":["CVE-2024-38385","CVE-2024-42127","CVE-2024-42131","CVE-2024-45015","CVE-2024-47732","CVE-2024-57896","CVE-2024-58085","CVE-2025-21854","CVE-2025-21861","CVE-2025-21944","CVE-2025-21996","CVE-2025-23149","CVE-2025-37849","CVE-2025-37930","CVE-2025-37937","CVE-2025-37948","CVE-2025-37963","CVE-2025-38007","CVE-2025-38031","CVE-2025-38034","CVE-2025-38060","CVE-2025-38065","CVE-2025-38074","CVE-2025-38078","CVE-2025-38080","CVE-2025-38152","CVE-2025-39735","CVE-2025-40014","CVE-2025-40364"],"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:genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after()irq_find_at_or_after() dereferences the interrupt descriptor which isreturned by mt_find() while neither holding sparse_irq_lock nor RCU readlock, which means the descriptor can be freed between mt_find() and thedereference:    CPU0                            CPU1    desc = mt_find()                                    delayed_free_desc(desc)    irq_desc_get_irq(desc)The use-after-free is reported by KASAN:    Call trace:     irq_get_next_irq+0x58/0x84     show_stat+0x638/0x824     seq_read_iter+0x158/0x4ec     proc_reg_read_iter+0x94/0x12c     vfs_read+0x1e0/0x2c8    Freed by task 4471:     slab_free_freelist_hook+0x174/0x1e0     __kmem_cache_free+0xa4/0x1dc     kfree+0x64/0x128     irq_kobj_release+0x28/0x3c     kobject_put+0xcc/0x1e0     delayed_free_desc+0x14/0x2c     rcu_do_batch+0x214/0x720Guard the access with a RCU read lock section.(CVE-2024-38385)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/lima: fix shared irq handling on driver remove\n\nlima uses a shared interrupt, so the interrupt handlers must be prepared\nto be called at any time. At driver removal time, the clocks are\ndisabled early and the interrupts stay registered until the very end of\nthe remove process due to the devm usage.\nThis is potentially a bug as the interrupts access device registers\nwhich assumes clocks are enabled. A crash can be triggered by removing\nthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.\nThis patch frees the interrupts at each lima device finishing callback\nso that the handlers are already unregistered by the time we fully\ndisable clocks.(CVE-2024-42127)\n\nIn the Linux kernel, the following vulnerability has been resolved:mm: avoid overflows in dirty throttling logicThe dirty throttling logic is interspersed with assumptions that dirtylimits in PAGE_SIZE units fit into 32-bit (so that various multiplicationsfit into 64-bits).  If limits end up being larger, we will hit overflows,possible divisions by 0 etc.  Fix these problems by never allowing solarge dirty limits as they have dubious practical value anyway.  Fordirty_bytes / dirty_background_bytes interfaces we can just refuse to setso large limits.  For dirty_ratio / dirty_background_ratio it isn t sosimple as the dirty limit is computed from the amount of available memorywhich can change due to memory hotplug etc.  So when converting dirtylimits from ratios to numbers of pages, we just don t allow the result toexceed UINT_MAX.This is root-only triggerable problem which occurs when the operatorsets dirty limits to \u0026gt;16 TB.(CVE-2024-42131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dpu: move dpu_encoder\u0026apos;s connector assignment to atomic_enable()\n\nFor cases where the crtc\u0026apos;s connectors_changed was set without enable/active\ngetting toggled , there is an atomic_enable() call followed by an\natomic_disable() but without an atomic_mode_set().\n\nThis results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in\nthe atomic_enable() as the dpu_encoder\u0026apos;s connector was cleared in the\natomic_disable() but not re-assigned as there was no atomic_mode_set() call.\n\nFix the NULL ptr access by moving the assignment for atomic_enable() and also\nuse drm_atomic_get_new_connector_for_encoder() to get the connector from\nthe atomic_state.\n\nPatchwork: https://patchwork.freedesktop.org/patch/606729/(CVE-2024-45015)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: iaa - Fix potential use after free bug\n\nThe free_device_compression_mode(iaa_device, device_mode) function frees\n\u0026quot;device_mode\u0026quot; but it iss passed to iaa_compression_modes[i]-\u0026gt;free() a few\nlines later resulting in a use after free.\n\nThe good news is that, so far as I can tell, nothing implements the\n-\u0026gt;free() function and the use after free happens in dead code.  But, with\nthis fix, when something does implement it, we\u0026apos;ll be ready.  :)(CVE-2024-47732)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: flush delalloc workers queue before stopping cleaner kthread during unmount\n\nDuring the unmount path, at close_ctree(), we first stop the cleaner\nkthread, using kthread_stop() which frees the associated task_struct, and\nthen stop and destroy all the work queues. However after we stopped the\ncleaner we may still have a worker from the delalloc_workers queue running\ninode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),\nwhich in turn tries to wake up the cleaner kthread - which was already\ndestroyed before, resulting in a use-after-free on the task_struct.\n\nSyzbot reported this with the following stack traces:\n\n  BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089\n  Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52\n\n  CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n  Workqueue: btrfs-delalloc btrfs_work_helper\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   __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089\n   lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n   __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n   _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162\n   class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]\n   try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205\n   submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615\n   run_ordered_work fs/btrfs/async-thread.c:288 [inline]\n   btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324\n   process_one_work kernel/workqueue.c:3229 [inline]\n   process_scheduled_works+0xa66/0x1840 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\n  Allocated by task 2:\n   kasan_save_stack mm/kasan/common.c:47 [inline]\n   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n   unpoison_slab_object mm/kasan/common.c:319 [inline]\n   __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345\n   kasan_slab_alloc include/linux/kasan.h:250 [inline]\n   slab_post_alloc_hook mm/slub.c:4104 [inline]\n   slab_alloc_node mm/slub.c:4153 [inline]\n   kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205\n   alloc_task_struct_node kernel/fork.c:180 [inline]\n   dup_task_struct+0x57/0x8c0 kernel/fork.c:1113\n   copy_process+0x5d1/0x3d50 kernel/fork.c:2225\n   kernel_clone+0x223/0x870 kernel/fork.c:2807\n   kernel_thread+0x1bc/0x240 kernel/fork.c:2869\n   create_kthread kernel/kthread.c:412 [inline]\n   kthreadd+0x60d/0x810 kernel/kthread.c:767\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\n  Freed by task 24:\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   kmem_cache_free+0x195/0x410 mm/slub.c:4700\n   put_task_struct include/linux/sched/task.h:144 [inline]\n   delayed_put_task_struct+0x125/0x300 kernel/exit.c:227\n   rcu_do_batch kernel/rcu/tree.c:2567 [inline]\n   rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823\n   handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554\n   run_ksoftirqd+0xca/0x130 kernel/softirq.c:943\n  \n---truncated---(CVE-2024-57896)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntomoyo: don\u0026apos;t emit warning in tomoyo_write_control()\n\nsyzbot is reporting too large allocation warning at tomoyo_write_control(),\nfor one can write a very very long line without new line character. To fix\nthis warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE,\nfor practically a valid line should be always shorter than 32KB where the\n\u0026quot;too small to fail\u0026quot; memory-allocation rule applies.\n\nOne might try to write a valid line that is longer than 32KB, but such\nrequest will likely fail with -ENOMEM. Therefore, I feel that separately\nreturning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant.\nThere is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.(CVE-2024-58085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsockmap, vsock: For connectible sockets allow only connected\n\nsockmap expects all vsocks to have a transport assigned, which is expressed\nin vsock_proto::psock_update_sk_prot(). However, there is an edge case\nwhere an unconnected (connectible) socket may lose its previously assigned\ntransport. This is handled with a NULL check in the vsock/BPF recv path.\n\nAnother design detail is that listening vsocks are not supposed to have any\ntransport assigned at all. Which implies they are not supported by the\nsockmap. But this is complicated by the fact that a socket, before\nswitching to TCP_LISTEN, may have had some transport assigned during a\nfailed connect() attempt. Hence, we may end up with a listening vsock in a\nsockmap, which blows up quickly:\n\nKASAN: null-ptr-deref in range [0x0000000000000120-0x0000000000000127]\nCPU: 7 UID: 0 PID: 56 Comm: kworker/7:0 Not tainted 6.14.0-rc1+\nWorkqueue: vsock-loopback vsock_loopback_work\nRIP: 0010:vsock_read_skb+0x4b/0x90\nCall Trace:\n sk_psock_verdict_data_ready+0xa4/0x2e0\n virtio_transport_recv_pkt+0x1ca8/0x2acc\n vsock_loopback_work+0x27d/0x3f0\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x35a/0x700\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n\nFor connectible sockets, instead of relying solely on the state of\nvsk-\u0026gt;transport, tell sockmap to only allow those representing established\nconnections. This aligns with the behaviour for AF_INET and AF_UNIX.(CVE-2025-21854)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/migrate_device: don\u0026apos;t add folio to be freed to LRU in migrate_device_finalize()\n\nIf migration succeeded, we called\nfolio_migrate_flags()-\u0026gt;mem_cgroup_migrate() to migrate the memcg from the\nold to the new folio.  This will set memcg_data of the old folio to 0.\n\nSimilarly, if migration failed, memcg_data of the dst folio is left unset.\n\nIf we call folio_putback_lru() on such folios (memcg_data == 0), we will\nadd the folio to be freed to the LRU, making memcg code unhappy.  Running\nthe hmm selftests:\n\n  # ./hmm-tests\n  ...\n  #  RUN           hmm.hmm_device_private.migrate ...\n  [  102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00\n  [  102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff)\n  [  102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9\n  [  102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000\n  [  102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg \u0026amp;\u0026amp; !mem_cgroup_disabled())\n  [  102.087230][T14893] ------------[ cut here ]------------\n  [  102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170\n  [  102.090478][T14893] Modules linked in:\n  [  102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151\n  [  102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\n  [  102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170\n  [  102.096104][T14893] Code: ...\n  [  102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293\n  [  102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426\n  [  102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880\n  [  102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000\n  [  102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8\n  [  102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000\n  [  102.108830][T14893] FS:  00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000\n  [  102.110643][T14893] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [  102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0\n  [  102.113478][T14893] PKRU: 55555554\n  [  102.114172][T14893] Call Trace:\n  [  102.114805][T14893]  \u0026lt;TASK\u0026gt;\n  [  102.115397][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170\n  [  102.116547][T14893]  ? __warn.cold+0x110/0x210\n  [  102.117461][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170\n  [  102.118667][T14893]  ? report_bug+0x1b9/0x320\n  [  102.119571][T14893]  ? handle_bug+0x54/0x90\n  [  102.120494][T14893]  ? exc_invalid_op+0x17/0x50\n  [  102.121433][T14893]  ? asm_exc_invalid_op+0x1a/0x20\n  [  102.122435][T14893]  ? __wake_up_klogd.part.0+0x76/0xd0\n  [  102.123506][T14893]  ? dump_page+0x4f/0x60\n  [  102.124352][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170\n  [  102.125500][T14893]  folio_batch_move_lru+0xd4/0x200\n  [  102.126577][T14893]  ? __pfx_lru_add+0x10/0x10\n  [  102.127505][T14893]  __folio_batch_add_and_move+0x391/0x720\n  [  102.128633][T14893]  ? __pfx_lru_add+0x10/0x10\n  [  102.129550][T14893]  folio_putback_lru+0x16/0x80\n  [  102.130564][T14893]  migrate_device_finalize+0x9b/0x530\n  [  102.131640][T14893]  dmirror_migrate_to_device.constprop.0+0x7c5/0xad0\n  [  102.133047][T14893]  dmirror_fops_unlocked_ioctl+0x89b/0xc80\n\nLikely, nothing else goes wrong: putting the last folio reference will\nremove the folio from the LRU again.  So besides memcg complaining, adding\nthe folio to be freed to the LRU is just an unnecessary step.\n\nThe new flow resembles what we have in migrate_folio_move(): add the dst\nto the lru, rem\n---truncated---(CVE-2025-21861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix bug on trap in smb2_lock\n\nIf lock count is greater than 1, flags could be old value.\nIt should be checked with flags of smb_lock, not flags.\nIt will cause bug-on trap from locks_free_lock in error handling\nroutine.(CVE-2025-21944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()\n\nOn the off chance that command stream passed from userspace via\nioctl() call to radeon_vce_cs_parse() is weirdly crafted and\nfirst command to execute is to encode (case 0x03000001), the function\nin question will attempt to call radeon_vce_cs_reloc() with size\nargument that has not been properly initialized. Specifically, \u0026apos;size\u0026apos;\nwill point to \u0026apos;tmp\u0026apos; variable before the latter had a chance to be\nassigned any value.\n\nPlay it safe and init \u0026apos;tmp\u0026apos; with 0, thus ensuring that\nradeon_vce_cs_reloc() will catch an early error in cases like these.\n\nFound by Linux Verification Center (linuxtesting.org) with static\nanalysis tool SVACE.\n\n(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)(CVE-2025-21996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: do not start chip while suspended\n\nChecking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can\nlead to a spurious tpm_chip_start() call:\n\n[35985.503771] i2c i2c-1: Transfer while suspended\n[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810\n[35985.503802] Modules linked in:\n[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G        W          6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f\n[35985.503814] Tainted: [W]=WARN\n[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810\n[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe \u0026lt;0f\u0026gt; 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5\n[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246\n[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000\n[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001\n[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000\n[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820\n[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120\n[35985.503846] FS:  0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000\n[35985.503849] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0\n[35985.503855] Call Trace:\n[35985.503859]  \u0026lt;TASK\u0026gt;\n[35985.503863]  ? __warn+0xd4/0x260\n[35985.503868]  ? __i2c_transfer+0xbe/0x810\n[35985.503874]  ? report_bug+0xf3/0x210\n[35985.503882]  ? handle_bug+0x63/0xb0\n[35985.503887]  ? exc_invalid_op+0x16/0x50\n[35985.503892]  ? asm_exc_invalid_op+0x16/0x20\n[35985.503904]  ? __i2c_transfer+0xbe/0x810\n[35985.503913]  tpm_cr50_i2c_transfer_message+0x24/0xf0\n[35985.503920]  tpm_cr50_i2c_read+0x8e/0x120\n[35985.503928]  tpm_cr50_request_locality+0x75/0x170\n[35985.503935]  tpm_chip_start+0x116/0x160\n[35985.503942]  tpm_try_get_ops+0x57/0x90\n[35985.503948]  tpm_find_get_ops+0x26/0xd0\n[35985.503955]  tpm_get_random+0x2d/0x80\n\nDon\u0026apos;t move forward with tpm_chip_start() inside tpm_try_get_ops(), unless\nTPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in\nsuch a failure case.(CVE-2025-23149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Tear down vGIC on failed vCPU creation\n\nIf kvm_arch_vcpu_create() fails to share the vCPU page with the\nhypervisor, we propagate the error back to the ioctl but leave the\nvGIC vCPU data initialised. Note only does this leak the corresponding\nmemory when the vCPU is destroyed but it can also lead to use-after-free\nif the redistributor device handling tries to walk into the vCPU.\n\nAdd the missing cleanup to kvm_arch_vcpu_create(), ensuring that the\nvGIC vCPU structures are destroyed on error.(CVE-2025-37849)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()\n\nNouveau is mostly designed in a way that it\u0026apos;s expected that fences only\never get signaled through nouveau_fence_signal(). However, in at least\none other place, nouveau_fence_done(), can signal fences, too. If that\nhappens (race) a signaled fence remains in the pending list for a while,\nuntil it gets removed by nouveau_fence_update().\n\nShould nouveau_fence_context_kill() run in the meantime, this would be\na bug because the function would attempt to set an error code on an\nalready signaled fence.\n\nHave nouveau_fence_context_kill() check for a fence being signaled.(CVE-2025-37930)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()\n\nIf dib8000_set_dds()\u0026apos;s call to dib8000_read32() returns zero, the result\nis a divide-by-zero.  Prevent that from happening.\n\nFixes the following warning with an UBSAN kernel:\n\n  drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()(CVE-2025-37937)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: bpf: Add BHB mitigation to the epilogue for cBPF programs\n\nA malicious BPF program may manipulate the branch history to influence\nwhat the hardware speculates will happen next.\n\nOn exit from a BPF program, emit the BHB mititgation sequence.\n\nThis is only applied for \u0026apos;classic\u0026apos; cBPF programs that are loaded by\nseccomp.(CVE-2025-37948)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: bpf: Only mitigate cBPF programs loaded by unprivileged users\n\nSupport for eBPF programs loaded by unprivileged users is typically\ndisabled. This means only cBPF programs need to be mitigated for BHB.\n\nIn addition, only mitigate cBPF programs that were loaded by an\nunprivileged user. Privileged users can also load the same program\nvia eBPF, making the mitigation pointless.(CVE-2025-37963)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: uclogic: Add NULL check in uclogic_input_configured()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\nuclogic_input_configured() does not check for this case, which results\nin a NULL pointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue.(CVE-2025-38007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: do not leak refcount in reorder_work\n\nA recent patch that addressed a UAF introduced a reference count leak:\nthe parallel_data refcount is incremented unconditionally, regardless\nof the return value of queue_work(). If the work item is already queued,\nthe incremented refcount is never decremented.\n\nFix this by checking the return value of queue_work() and decrementing\nthe refcount when necessary.\n\nResolves:\n\nUnreferenced object 0xffff9d9f421e3d80 (size 192):\n  comm \u0026quot;cryptomgr_probe\u0026quot;, pid 157, jiffies 4294694003\n  hex dump (first 32 bytes):\n    80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff  ...A............\n    d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00  ..............#.\n  backtrace (crc 838fb36):\n    __kmalloc_cache_noprof+0x284/0x320\n    padata_alloc_pd+0x20/0x1e0\n    padata_alloc_shell+0x3b/0xa0\n    0xffffffffc040a54d\n    cryptomgr_probe+0x43/0xc0\n    kthread+0xf6/0x1f0\n    ret_from_fork+0x2f/0x50\n    ret_from_fork_asm+0x1a/0x30(CVE-2025-38031)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref\n\nbtrfs_prelim_ref() calls the old and new reference variables in the\nincorrect order. This causes a NULL pointer dereference because oldref\nis passed as NULL to trace_btrfs_prelim_ref_insert().\n\nNote, trace_btrfs_prelim_ref_insert() is being called with newref as\noldref (and oldref as NULL) on purpose in order to print out\nthe values of newref.\n\nTo reproduce:\necho 1 \u0026gt; /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable\n\nPerform some writeback operations.\n\nBacktrace:\nBUG: kernel NULL pointer dereference, address: 0000000000000018\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0\n Oops: Oops: 0000 [#1] SMP NOPTI\n CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary)  7ca2cef72d5e9c600f0c7718adb6462de8149622\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014\n RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130\n Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 \u0026lt;49\u0026gt; 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88\n RSP: 0018:ffffce44820077a0 EFLAGS: 00010286\n RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b\n RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010\n RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010\n R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000\n R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540\n FS:  00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0\n PKRU: 55555554\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  prelim_ref_insert+0x1c1/0x270\n  find_parent_nodes+0x12a6/0x1ee0\n  ? __entry_text_end+0x101f06/0x101f09\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  btrfs_is_data_extent_shared+0x167/0x640\n  ? fiemap_process_hole+0xd0/0x2c0\n  extent_fiemap+0xa5c/0xbc0\n  ? __entry_text_end+0x101f05/0x101f09\n  btrfs_fiemap+0x7e/0xd0\n  do_vfs_ioctl+0x425/0x9d0\n  __x64_sys_ioctl+0x75/0xc0(CVE-2025-38034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: copy_verifier_state() should copy \u0026apos;loop_entry\u0026apos; field\n\nThe bpf_verifier_state.loop_entry state should be copied by\ncopy_verifier_state(). Otherwise, .loop_entry values from unrelated\nstates would poison env-\u0026gt;cur_state.\n\nAdditionally, env-\u0026gt;stack should not contain any states with\n.loop_entry != NULL. The states in env-\u0026gt;stack are yet to be verified,\nwhile .loop_entry is set for states that reached an equivalent state.\nThis means that env-\u0026gt;cur_state-\u0026gt;loop_entry should always be NULL after\npop_stack().\n\nSee the selftest in the next commit for an example of the program that\nis not safe yet is accepted by verifier w/o this fix.\n\nThis change has some verification performance impact for selftests:\n\nFile                                Program                       Insns (A)  Insns (B)  Insns   (DIFF)  States (A)  States (B)  States (DIFF)\n----------------------------------  ----------------------------  ---------  ---------  --------------  ----------  ----------  -------------\narena_htab.bpf.o                    arena_htab_llvm                     717        426  -291 (-40.59%)          57          37  -20 (-35.09%)\narena_htab_asm.bpf.o                arena_htab_asm                      597        445  -152 (-25.46%)          47          37  -10 (-21.28%)\narena_list.bpf.o                    arena_list_del                      309        279    -30 (-9.71%)          23          14   -9 (-39.13%)\niters.bpf.o                         iter_subprog_check_stacksafe        155        141    -14 (-9.03%)          15          14    -1 (-6.67%)\niters.bpf.o                         iter_subprog_iters                 1094       1003    -91 (-8.32%)          88          83    -5 (-5.68%)\niters.bpf.o                         loop_state_deps2                    479        725  +246 (+51.36%)          46          63  +17 (+36.96%)\nkmem_cache_iter.bpf.o               open_coded_iter                      63         59     -4 (-6.35%)           7           6   -1 (-14.29%)\nverifier_bits_iter.bpf.o            max_words                            92         84     -8 (-8.70%)           8           7   -1 (-12.50%)\nverifier_iterating_callbacks.bpf.o  cond_break2                         113        107     -6 (-5.31%)          12          12    +0 (+0.00%)\n\nAnd significant negative impact for sched_ext:\n\nFile               Program                 Insns (A)  Insns (B)  Insns         (DIFF)  States (A)  States (B)  States      (DIFF)\n-----------------  ----------------------  ---------  ---------  --------------------  ----------  ----------  ------------------\nbpf.bpf.o          lavd_init                    7039      14723      +7684 (+109.16%)         490        1139     +649 (+132.45%)\nbpf.bpf.o          layered_dispatch            11485      10548         -937 (-8.16%)         848         762       -86 (-10.14%)\nbpf.bpf.o          layered_dump                 7422    1000001  +992579 (+13373.47%)         681       31178  +30497 (+4478.27%)\nbpf.bpf.o          layered_enqueue             16854      71127     +54273 (+322.02%)        1611        6450    +4839 (+300.37%)\nbpf.bpf.o          p2dq_dispatch                 665        791        +126 (+18.95%)          68          78       +10 (+14.71%)\nbpf.bpf.o          p2dq_init                    2343       2980        +637 (+27.19%)         201         237       +36 (+17.91%)\nbpf.bpf.o          refresh_layer_cpumasks      16487     674760   +658273 (+3992.68%)        1770       65370  +63600 (+3593.22%)\nbpf.bpf.o          rusty_select_cpu             1937      40872    +38935 (+2010.07%)         177        3210   +3033 (+1713.56%)\nscx_central.bpf.o  central_dispatch              636       2687      +2051 (+322.48%)          63         227     +164 (+260.32%)\nscx_nest.bpf.o     nest_init                     636        815        +179 (+28.14%)          60          73       +13 (+21.67%)\nscx_qmap.bpf.o     qmap_dispatch      \n---truncated---(CVE-2025-38060)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\norangefs: Do not truncate file size\n\n\u0026apos;len\u0026apos; is used to store the result of i_size_read(), so making \u0026apos;len\u0026apos;\na size_t results in truncation to 4GiB on 32-bit systems.(CVE-2025-38065)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: protect vq-\u0026gt;log_used with vq-\u0026gt;mutex\n\nThe vhost-scsi completion path may access vq-\u0026gt;log_base when vq-\u0026gt;log_used is\nalready set to false.\n\n    vhost-thread                       QEMU-thread\n\nvhost_scsi_complete_cmd_work()\n-\u0026gt; vhost_add_used()\n   -\u0026gt; vhost_add_used_n()\n      if (unlikely(vq-\u0026gt;log_used))\n                                      QEMU disables vq-\u0026gt;log_used\n                                      via VHOST_SET_VRING_ADDR.\n                                      mutex_lock(\u0026amp;vq-\u0026gt;mutex);\n                                      vq-\u0026gt;log_used = false now!\n                                      mutex_unlock(\u0026amp;vq-\u0026gt;mutex);\n\n\t\t\t\t      QEMU gfree(vq-\u0026gt;log_base)\n        log_used()\n        -\u0026gt; log_write(vq-\u0026gt;log_base)\n\nAssuming the VMM is QEMU. The vq-\u0026gt;log_base is from QEMU userpace and can be\nreclaimed via gfree(). As a result, this causes invalid memory writes to\nQEMU userspace.\n\nThe control queue path has the same issue.(CVE-2025-38074)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: pcm: Fix race of buffer access at PCM OSS layer\n\nThe PCM OSS layer tries to clear the buffer with the silence data at\ninitialization (or reconfiguration) of a stream with the explicit call\nof snd_pcm_format_set_silence() with runtime-\u0026gt;dma_area.  But this may\nlead to a UAF because the accessed runtime-\u0026gt;dma_area might be freed\nconcurrently, as it\u0026apos;s performed outside the PCM ops.\n\nFor avoiding it, move the code into the PCM core and perform it inside\nthe buffer access lock, so that it won\u0026apos;t be changed during the\noperation.(CVE-2025-38078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Increase block_sequence array size\n\n[Why]\nIt\u0026apos;s possible to generate more than 50 steps in hwss_build_fast_sequence,\nfor example with a 6-pipe asic where all pipes are in one MPC chain. This\noverflows the block_sequence buffer and corrupts block_sequence_steps,\ncausing a crash.\n\n[How]\nExpand block_sequence to 100 items. A naive upper bound on the possible\nnumber of steps for a 6-pipe asic, ignoring the potential for steps to be\nmutually exclusive, is 91 with current code, therefore 100 is sufficient.(CVE-2025-38080)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Clear table_sz when rproc_shutdown\n\nThere is case as below could trigger kernel dump:\nUse U-Boot to start remote processor(rproc) with resource table\npublished to a fixed address by rproc. After Kernel boots up,\nstop the rproc, load a new firmware which doesn\u0026apos;t have resource table\n,and start rproc.\n\nWhen starting rproc with a firmware not have resource table,\n`memcpy(loaded_table, rproc-\u0026gt;cached_table, rproc-\u0026gt;table_sz)` will\ntrigger dump, because rproc-\u0026gt;cache_table is set to NULL during the last\nstop operation, but rproc-\u0026gt;table_sz is still valid.\n\nThis issue is found on i.MX8MP and i.MX9.\n\nDump as below:\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000000\nMem abort info:\n  ESR = 0x0000000096000004\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x04: level 0 translation fault\nData abort info:\n  ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n  CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000\n[0000000000000000] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nModules linked in:\nCPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38\nHardware name: NXP i.MX8MPlus EVK board (DT)\npstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __pi_memcpy_generic+0x110/0x22c\nlr : rproc_start+0x88/0x1e0\nCall trace:\n __pi_memcpy_generic+0x110/0x22c (P)\n rproc_boot+0x198/0x57c\n state_store+0x40/0x104\n dev_attr_store+0x18/0x2c\n sysfs_kf_write+0x7c/0x94\n kernfs_fop_write_iter+0x120/0x1cc\n vfs_write+0x240/0x378\n ksys_write+0x70/0x108\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x30/0xcc\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n\nClear rproc-\u0026gt;table_sz to address the issue.(CVE-2025-38152)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: fix slab-out-of-bounds read in ea_get()\n\nDuring the \u0026quot;size_check\u0026quot; label in ea_get(), the code checks if the extended\nattribute list (xattr) size matches ea_size. If not, it logs\n\u0026quot;ea_get: invalid extended attribute\u0026quot; and calls print_hex_dump().\n\nHere, EALIST_SIZE(ea_buf-\u0026gt;xattr) returns 4110417968, which exceeds\nINT_MAX (2,147,483,647). Then ea_size is clamped:\n\n\tint size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf-\u0026gt;xattr));\n\nAlthough clamp_t aims to bound ea_size between 0 and 4110417968, the upper\nlimit is treated as an int, causing an overflow above 2^31 - 1. This leads\n\u0026quot;size\u0026quot; to wrap around and become negative (-184549328).\n\nThe \u0026quot;size\u0026quot; is then passed to print_hex_dump() (called \u0026quot;len\u0026quot; in\nprint_hex_dump()), it is passed as type size_t (an unsigned\ntype), this is then stored inside a variable called\n\u0026quot;int remaining\u0026quot;, which is then assigned to \u0026quot;int linelen\u0026quot; which\nis then passed to hex_dump_to_buffer(). In print_hex_dump()\nthe for loop, iterates through 0 to len-1, where len is\n18446744073525002176, calling hex_dump_to_buffer()\non each iteration:\n\n\tfor (i = 0; i \u0026lt; len; i += rowsize) {\n\t\tlinelen = min(remaining, rowsize);\n\t\tremaining -= rowsize;\n\n\t\thex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,\n\t\t\t\t   linebuf, sizeof(linebuf), ascii);\n\n\t\t...\n\t}\n\nThe expected stopping condition (i \u0026lt; len) is effectively broken\nsince len is corrupted and very large. This eventually leads to\nthe \u0026quot;ptr+i\u0026quot; being passed to hex_dump_to_buffer() to get closer\nto the end of the actual bounds of \u0026quot;ptr\u0026quot;, eventually an out of\nbounds access is done in hex_dump_to_buffer() in the following\nfor loop:\n\n\tfor (j = 0; j \u0026lt; len; j++) {\n\t\t\tif (linebuflen \u0026lt; lx + 2)\n\t\t\t\tgoto overflow2;\n\t\t\tch = ptr[j];\n\t\t...\n\t}\n\nTo fix this we should validate \u0026quot;EALIST_SIZE(ea_buf-\u0026gt;xattr)\u0026quot;\nbefore it is utilised.(CVE-2025-39735)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()\n\nIf speed_hz \u0026lt; AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the\nentire amd_spi_freq array without breaking out early, causing \u0026apos;i\u0026apos; to go\nbeyond the array bounds.\n\nFix that by stopping the loop when it gets to the last entry, so the low\nspeed_hz value gets clamped up to AMD_SPI_MIN_HZ.\n\nFixes the following warning with an UBSAN kernel:\n\n  drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()(CVE-2025-40014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix io_req_prep_async with provided buffers\n\nio_req_prep_async() can import provided buffers, commit the ring state\nby giving up on that before, it\u0026apos;ll be reimported later if needed.(CVE-2025-40364)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-99.0.0.91.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-99.0.0.91.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-99.0.0.91.oe2403.aarch64.rpm","kernel-6.6.0-99.0.0.91.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-99.0.0.91.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-99.0.0.91.oe2403.aarch64.rpm","kernel-devel-6.6.0-99.0.0.91.oe2403.aarch64.rpm","kernel-headers-6.6.0-99.0.0.91.oe2403.aarch64.rpm","kernel-source-6.6.0-99.0.0.91.oe2403.aarch64.rpm","kernel-tools-6.6.0-99.0.0.91.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-99.0.0.91.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-99.0.0.91.oe2403.aarch64.rpm","perf-6.6.0-99.0.0.91.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-99.0.0.91.oe2403.aarch64.rpm","python3-perf-6.6.0-99.0.0.91.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-99.0.0.91.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-99.0.0.91.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-99.0.0.91.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-99.0.0.91.oe2403.x86_64.rpm","kernel-6.6.0-99.0.0.91.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-99.0.0.91.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-99.0.0.91.oe2403.x86_64.rpm","kernel-devel-6.6.0-99.0.0.91.oe2403.x86_64.rpm","kernel-headers-6.6.0-99.0.0.91.oe2403.x86_64.rpm","kernel-source-6.6.0-99.0.0.91.oe2403.x86_64.rpm","kernel-tools-6.6.0-99.0.0.91.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-99.0.0.91.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-99.0.0.91.oe2403.x86_64.rpm","perf-6.6.0-99.0.0.91.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-99.0.0.91.oe2403.x86_64.rpm","python3-perf-6.6.0-99.0.0.91.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-99.0.0.91.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1729"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38385"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42127"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42131"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45015"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47732"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57896"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58085"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21854"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21861"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21944"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21996"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23149"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37849"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37930"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37937"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37948"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37963"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38007"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38031"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38034"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38060"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38065"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38074"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38078"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38080"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38152"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39735"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40014"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40364"}],"database_specific":{"severity":"High"}}