{"schema_version":"1.7.2","id":"OESA-2025-1823","modified":"2025-07-11T12:27:10Z","published":"2025-07-11T12:27:10Z","upstream":["CVE-2025-22033","CVE-2025-23141","CVE-2025-37739","CVE-2025-37784","CVE-2025-37808","CVE-2025-37842","CVE-2025-37854","CVE-2025-37887","CVE-2025-37933","CVE-2025-37951","CVE-2025-37968","CVE-2025-37984","CVE-2025-37991","CVE-2025-38023","CVE-2025-38050","CVE-2025-38067","CVE-2025-38072","CVE-2025-38081","CVE-2025-38090","CVE-2025-38094","CVE-2025-38095","CVE-2025-38099","CVE-2025-38108","CVE-2025-38118","CVE-2025-38142","CVE-2025-38146","CVE-2025-38159","CVE-2025-38163","CVE-2025-38170","CVE-2025-38182","CVE-2025-38195","CVE-2025-38202"],"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\narm64: Don\u0026apos;t call NULL in do_compat_alignment_fixup()\n\ndo_alignment_t32_to_handler() only fixes up alignment faults for\nspecific instructions; it returns NULL otherwise (e.g. LDREX). When\nthat\u0026apos;s the case, signal to the caller that it needs to proceed with the\nregular alignment fault handling (i.e. SIGBUS). Without this patch, the\nkernel panics:\n\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n  Mem abort info:\n    ESR = 0x0000000086000006\n    EC = 0x21: IABT (current EL), IL = 32 bits\n    SET = 0, FnV = 0\n    EA = 0, S1PTW = 0\n    FSC = 0x06: level 2 translation fault\n  user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000\n  [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000\n  Internal error: Oops: 0000000086000006 [#1] SMP\n  Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa\u0026gt;\n   libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c\u0026gt;\n  CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1  Debian 6.1.128-1\n  Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021\n  pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : 0x0\n  lr : do_compat_alignment_fixup+0xd8/0x3dc\n  sp : ffff80000f973dd0\n  x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000\n  x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n  x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001\n  x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000\n  x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n  x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488\n  x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\n  x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000\n  x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001\n  Call trace:\n   0x0\n   do_alignment_fault+0x40/0x50\n   do_mem_abort+0x4c/0xa0\n   el0_da+0x48/0xf0\n   el0t_32_sync_handler+0x110/0x140\n   el0t_32_sync+0x190/0x194\n  Code: bad PC value\n  ---[ end trace 0000000000000000 ]---(CVE-2025-22033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses\n\nAcquire a lock on kvm-\u0026gt;srcu when userspace is getting MP state to handle a\nrather extreme edge case where \u0026quot;accepting\u0026quot; APIC events, i.e. processing\npending INIT or SIPI, can trigger accesses to guest memory.  If the vCPU\nis in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP\nstate will trigger a nested VM-Exit by way of -\u0026gt;check_nested_events(), and\nemuating the nested VM-Exit can access guest memory.\n\nThe splat was originally hit by syzkaller on a Google-internal kernel, and\nreproduced on an upstream kernel by hacking the triple_fault_event_test\nselftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a\nmemory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.\n\n  =============================\n  WARNING: suspicious RCU usage\n  6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted\n  -----------------------------\n  include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!\n\n  other info that might help us debug this:\n\n  rcu_scheduler_active = 2, debug_locks = 1\n  1 lock held by triple_fault_ev/1256:\n   #0: ffff88810df5a330 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]\n\n  stack backtrace:\n  CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x7f/0x90\n   lockdep_rcu_suspicious+0x144/0x190\n   kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]\n   kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n   read_and_check_msr_entry+0x2e/0x180 [kvm_intel]\n   __nested_vmx_vmexit+0x550/0xde0 [kvm_intel]\n   kvm_check_nested_events+0x1b/0x30 [kvm]\n   kvm_apic_accept_events+0x33/0x100 [kvm]\n   kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]\n   kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]\n   __x64_sys_ioctl+0x8b/0xb0\n   do_syscall_64+0x6c/0x170\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n   \u0026lt;/TASK\u0026gt;(CVE-2025-23141)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()\n\nsyzbot reports an UBSAN issue as below:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10\nindex 18446744073709550692 is out of range for type \u0026apos;__le32[5]\u0026apos; (aka \u0026apos;unsigned int[5]\u0026apos;)\nCPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0\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 ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429\n get_nid fs/f2fs/node.h:381 [inline]\n f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181\n f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808\n f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836\n f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886\n f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093\n aio_write+0x56b/0x7c0 fs/aio.c:1633\n io_submit_one+0x8a7/0x18a0 fs/aio.c:2052\n __do_sys_io_submit fs/aio.c:2111 [inline]\n __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081\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\nRIP: 0033:0x7f238798cde9\n\nindex 18446744073709550692 (decimal, unsigned long long)\n= 0xfffffffffffffc64 (hexadecimal, unsigned long long)\n= -924 (decimal, long long)\n\nIn f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to\naccess .i_nid[-924], it means both offset[0] and level should zero.\n\nThe possible case should be in f2fs_do_truncate_blocks(), we try to\ntruncate inode size to zero, however, dn.ofs_in_node is zero and\ndn.node_page is not an inode page, so it fails to truncate inode page,\nand then pass zeroed free_from to f2fs_truncate_inode_blocks(), result\nin this issue.\n\n\tif (dn.ofs_in_node || IS_INODE(dn.node_page)) {\n\t\tf2fs_truncate_data_blocks_range(\u0026amp;dn, count);\n\t\tfree_from += count;\n\t}\n\nI guess the reason why dn.node_page is not an inode page could be: there\nare multiple nat entries share the same node block address, once the node\nblock address was reused, f2fs_get_node_page() may load a non-inode block.\n\nLet\u0026apos;s add a sanity check for such condition to avoid out-of-bounds access\nissue.(CVE-2025-37739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ti: icss-iep: Fix possible NULL pointer dereference for perout request\n\nThe ICSS IEP driver tracks perout and pps enable state with flags.\nCurrently when disabling pps and perout signals during icss_iep_exit(),\nresults in NULL pointer dereference for perout.\n\nTo fix the null pointer dereference issue, the icss_iep_perout_enable_hw\nfunction can be modified to directly clear the IEP CMP registers when\ndisabling PPS or PEROUT, without referencing the ptp_perout_request\nstructure, as its contents are irrelevant in this case.(CVE-2025-37784)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: null - Use spin lock instead of mutex\n\nAs the null algorithm may be freed in softirq context through\naf_alg, use spin locks instead of mutexes to protect the default\nnull algorithm.(CVE-2025-37808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: fsl-qspi: use devm function instead of driver remove\n\nDriver use devm APIs to manage clk/irq/resources and register the spi\ncontroller, but the legacy remove function will be called first during\ndevice detach and trigger kernel panic. Drop the remove function and use\ndevm_add_action_or_reset() for driver cleanup to ensure the release\nsequence.\n\nTrigger kernel panic on i.MX8MQ by\necho 30bb0000.spi \u0026gt;/sys/bus/platform/drivers/fsl-quadspi/unbind(CVE-2025-37842)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix mode1 reset crash issue\n\nIf HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal\nuser space to abort the processes. After process abort exit, user queues\nstill use the GPU to access system memory before h/w is reset while KFD\ncleanup worker free system memory and free VRAM.\n\nThere is use-after-free race bug that KFD allocate and reuse the freed\nsystem memory, and user queue write to the same system memory to corrupt\nthe data structure and cause driver crash.\n\nTo fix this race, KFD cleanup worker terminate user queues, then flush\nreset_domain wq to wait for any GPU ongoing reset complete, and then\nfree outstanding BOs.(CVE-2025-37854)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result\n\nIf the FW doesn\u0026apos;t support the PDS_CORE_CMD_FW_CONTROL command\nthe driver might at the least print garbage and at the worst\ncrash when the user runs the \u0026quot;devlink dev info\u0026quot; devlink command.\n\nThis happens because the stack variable fw_list is not 0\ninitialized which results in fw_list.num_fw_slots being a\ngarbage value from the stack.  Then the driver tries to access\nfw_list.fw_names[i] with i \u0026gt;= ARRAY_SIZE and runs off the end\nof the array.\n\nFix this by initializing the fw_list and by not failing\ncompletely if the devcmd fails because other useful information\nis printed via devlink dev info even if the devcmd fails.(CVE-2025-37887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteon_ep: Fix host hang issue during device reboot\n\nWhen the host loses heartbeat messages from the device,\nthe driver calls the device-specific ndo_stop function,\nwhich frees the resources. If the driver is unloaded in\nthis scenario, it calls ndo_stop again, attempting to free\nresources that have already been freed, leading to a host\nhang issue. To resolve this, dev_close should be called\ninstead of the device-specific stop function.dev_close\ninternally calls ndo_stop to stop the network interface\nand performs additional cleanup tasks. During the driver\nunload process, if the device is already down, ndo_stop\nis not called.(CVE-2025-37933)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Add job to pending list if the reset was skipped\n\nWhen a CL/CSD job times out, we check if the GPU has made any progress\nsince the last timeout. If so, instead of resetting the hardware, we skip\nthe reset and let the timer get rearmed. This gives long-running jobs a\nchance to complete.\n\nHowever, when `timedout_job()` is called, the job in question is removed\nfrom the pending list, which means it won\u0026apos;t be automatically freed through\n`free_job()`. Consequently, when we skip the reset and keep the job\nrunning, the job won\u0026apos;t be freed when it finally completes.\n\nThis situation leads to a memory leak, as exposed in [1] and [2].\n\nSimilarly to commit 704d3d60fec4 (\u0026quot;drm/etnaviv: don\u0026apos;t block scheduler when\nGPU is still active\u0026quot;), this patch ensures the job is put back on the\npending list when extending the timeout.(CVE-2025-37951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: light: opt3001: fix deadlock due to concurrent flag access\n\nThe threaded IRQ function in this driver is reading the flag twice: once to\nlock a mutex and once to unlock it. Even though the code setting the flag\nis designed to prevent it, there are subtle cases where the flag could be\ntrue at the mutex_lock stage and false at the mutex_unlock stage. This\nresults in the mutex not being unlocked, resulting in a deadlock.\n\nFix it by making the opt3001_irq() code generally more robust, reading the\nflag into a variable and using the variable value at both stages.(CVE-2025-37968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()\n\nHerbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa\nimplementation\u0026apos;s -\u0026gt;key_size() callback returns an unusually large value.\nHerbert instead suggests (for a division by 8):\n\n  X / 8 + !!(X \u0026amp; 7)\n\nBased on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and\nuse it in lieu of DIV_ROUND_UP() for -\u0026gt;key_size() return values.\n\nAdditionally, use the macro in ecc_digits_from_bytes(), whose \u0026quot;nbytes\u0026quot;\nparameter is a -\u0026gt;key_size() return value in some instances, or a\nuser-specified ASN.1 length in the case of ecdsa_get_signature_rs().(CVE-2025-37984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler.  Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0.  The latter cancels all pending traps.  Let\u0026apos;s fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n        sigset_t set;\n        sigemptyset(\u0026amp;set);\n        sigaddset(\u0026amp;set, SIGFPE);\n        sigprocmask(SIG_UNBLOCK, \u0026amp;set, NULL);\n        printf(\u0026quot;GOT signal %d with si_code %ld\\n\u0026quot;, sig, i-\u0026gt;si_code);\n}\n\nint main() {\n        struct sigaction action = {\n                .sa_sigaction = fpe_func,\n                .sa_flags = SA_RESTART|SA_SIGINFO };\n        sigaction(SIGFPE, \u0026amp;action, 0);\n        feenableexcept(FE_OVERFLOW);\n        return printf(\u0026quot;%lf\\n\u0026quot;,1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve(\u0026quot;./a.out\u0026quot;, [\u0026quot;./a.out\u0026quot;], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception(CVE-2025-37991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs: handle failure of nfs_get_lock_context in unlock path\n\nWhen memory is insufficient, the allocation of nfs_lock_context in\nnfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat\nan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)\nas valid and proceed to execute rpc_run_task(), this will trigger a NULL\npointer dereference in nfs4_locku_prepare. For example:\n\nBUG: kernel NULL pointer dereference, address: 000000000000000c\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP PTI\nCPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40\nWorkqueue: rpciod rpc_async_schedule\nRIP: 0010:nfs4_locku_prepare+0x35/0xc2\nCode: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3\nRSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246\nRAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40\nRBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38\nR10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030\nR13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30\nFS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __rpc_execute+0xbc/0x480\n rpc_async_schedule+0x2f/0x40\n process_one_work+0x232/0x5d0\n worker_thread+0x1da/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x10d/0x240\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\nCR2: 000000000000000c\n---[ end trace 0000000000000000 ]---\n\nFree the allocated nfs4_unlockdata when nfs_get_lock_context() fails and\nreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointer\ndereference.(CVE-2025-38023)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios\n\nA kernel crash was observed when replacing free hugetlb folios:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000028\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 28 UID: 0 PID: 29639 Comm: test_cma.sh Tainted 6.15.0-rc6-zp #41 PREEMPT(voluntary)\nRIP: 0010:alloc_and_dissolve_hugetlb_folio+0x1d/0x1f0\nRSP: 0018:ffffc9000b30fa90 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: 0000000000342cca RCX: ffffea0043000000\nRDX: ffffc9000b30fb08 RSI: ffffea0043000000 RDI: 0000000000000000\nRBP: ffffc9000b30fb20 R08: 0000000000001000 R09: 0000000000000000\nR10: ffff88886f92eb00 R11: 0000000000000000 R12: ffffea0043000000\nR13: 0000000000000000 R14: 00000000010c0200 R15: 0000000000000004\nFS:  00007fcda5f14740(0000) GS:ffff8888ec1d8000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000028 CR3: 0000000391402000 CR4: 0000000000350ef0\nCall Trace:\n\u0026lt;TASK\u0026gt;\n replace_free_hugepage_folios+0xb6/0x100\n alloc_contig_range_noprof+0x18a/0x590\n ? srso_return_thunk+0x5/0x5f\n ? down_read+0x12/0xa0\n ? srso_return_thunk+0x5/0x5f\n cma_range_alloc.constprop.0+0x131/0x290\n __cma_alloc+0xcf/0x2c0\n cma_alloc_write+0x43/0xb0\n simple_attr_write_xsigned.constprop.0.isra.0+0xb2/0x110\n debugfs_attr_write+0x46/0x70\n full_proxy_write+0x62/0xa0\n vfs_write+0xf8/0x420\n ? srso_return_thunk+0x5/0x5f\n ? filp_flush+0x86/0xa0\n ? srso_return_thunk+0x5/0x5f\n ? filp_close+0x1f/0x30\n ? srso_return_thunk+0x5/0x5f\n ? do_dup2+0xaf/0x160\n ? srso_return_thunk+0x5/0x5f\n ksys_write+0x65/0xe0\n do_syscall_64+0x64/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThere is a potential race between __update_and_free_hugetlb_folio() and\nreplace_free_hugepage_folios():\n\nCPU1                              CPU2\n__update_and_free_hugetlb_folio   replace_free_hugepage_folios\n                                    folio_test_hugetlb(folio)\n                                    -- It\u0026apos;s still hugetlb folio.\n\n  __folio_clear_hugetlb(folio)\n  hugetlb_free_folio(folio)\n                                    h = folio_hstate(folio)\n                                    -- Here, h is NULL pointer\n\nWhen the above race condition occurs, folio_hstate(folio) returns NULL,\nand subsequent access to this NULL pointer will cause the system to crash.\nTo resolve this issue, execute folio_hstate(folio) under the protection\nof the hugetlb_lock lock, ensuring that folio_hstate(folio) does not\nreturn NULL.(CVE-2025-38050)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrseq: Fix segfault on registration when rseq_cs is non-zero\n\nThe rseq_cs field is documented as being set to 0 by user-space prior to\nregistration, however this is not currently enforced by the kernel. This\ncan result in a segfault on return to user-space if the value stored in\nthe rseq_cs field doesn\u0026apos;t point to a valid struct rseq_cs.\n\nThe correct solution to this would be to fail the rseq registration when\nthe rseq_cs field is non-zero. However, some older versions of glibc\nwill reuse the rseq area of previous threads without clearing the\nrseq_cs field and will also terminate the process if the rseq\nregistration fails in a secondary thread. This wasn\u0026apos;t caught in testing\nbecause in this case the leftover rseq_cs does point to a valid struct\nrseq_cs.\n\nWhat we can do is clear the rseq_cs field on registration when it\u0026apos;s\nnon-zero which will prevent segfaults on registration and won\u0026apos;t break\nthe glibc versions that reuse rseq areas on thread creation.(CVE-2025-38067)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibnvdimm/labels: Fix divide error in nd_label_data_init()\n\nIf a faulty CXL memory device returns a broken zero LSA size in its\nmemory device information (Identify Memory Device (Opcode 4000h), CXL\nspec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm\ndriver:\n\n Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI\n RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]\n\nCode and flow:\n\n1) CXL Command 4000h returns LSA size = 0\n2) config_size is assigned to zero LSA size (CXL pmem driver):\n\ndrivers/cxl/pmem.c:             .config_size = mds-\u0026gt;lsa_size,\n\n3) max_xfer is set to zero (nvdimm driver):\n\ndrivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd-\u0026gt;nsarea.max_xfer, config_size);\n\n4) A subsequent DIV_ROUND_UP() causes a division by zero:\n\ndrivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */\ndrivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,\ndrivers/nvdimm/label.c-                 config_size);\n\nFix this by checking the config size parameter by extending an\nexisting check.(CVE-2025-38072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi-rockchip: Fix register out of bounds access\n\nDo not write native chip select stuff for GPIO chip selects.\nGPIOs can be numbered much higher than native CS.\nAlso, it makes no sense.(CVE-2025-38081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/rapidio/rio_cm.c: prevent possible heap overwrite\n\nIn\n\nriocm_cdev_ioctl(RIO_CM_CHAN_SEND)\n   -\u0026gt; cm_chan_msg_send()\n      -\u0026gt; riocm_ch_send()\n\ncm_chan_msg_send() checks that userspace didn\u0026apos;t send too much data but\nriocm_ch_send() failed to check that userspace sent sufficient data.  The\nresult is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr\nwhich were outside the bounds of the space which cm_chan_msg_send()\nallocated.\n\nAddress this by teaching riocm_ch_send() to check that the entire\nrio_ch_chan_hdr was copied in from userspace.(CVE-2025-38090)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: cadence: macb: Fix a possible deadlock in macb_halt_tx.\n\nThere is a situation where after THALT is set high, TGO stays high as\nwell. Because jiffies are never updated, as we are in a context with\ninterrupts disabled, we never exit that loop and have a deadlock.\n\nThat deadlock was noticed on a sama5d4 device that stayed locked for days.\n\nUse retries instead of jiffies so that the timeout really works and we do\nnot have a deadlock anymore.(CVE-2025-38094)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf: insert memory barrier before updating num_fences\n\nsmp_store_mb() inserts memory barrier after storing operation.\nIt is different with what the comment is originally aiming so Null\npointer dereference can be happened if memory update is reordered.(CVE-2025-38095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken\n\nA SCO connection without the proper voice_setting can cause\nthe controller to lock up.(CVE-2025-38099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: red: fix a race in __red_change()\n\nGerrard Tai reported a race condition in RED, whenever SFQ perturb timer\nfires at the wrong time.\n\nThe race is as follows:\n\nCPU 0                                 CPU 1\n[1]: lock root\n[2]: qdisc_tree_flush_backlog()\n[3]: unlock root\n |\n |                                    [5]: lock root\n |                                    [6]: rehash\n |                                    [7]: qdisc_tree_reduce_backlog()\n |\n[4]: qdisc_put()\n\nThis can be abused to underflow a parent\u0026apos;s qlen.\n\nCalling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()\nshould fix the race, because all packets will be purged from the qdisc\nbefore releasing the lock.(CVE-2025-38108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete\n\nThis reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add to\navoid crashes like bellow:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406\nRead of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341\n\nCPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nWorkqueue: hci0 hci_cmd_sync_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xd2/0x2b0 mm/kasan/report.c:521\n kasan_report+0x118/0x150 mm/kasan/report.c:634\n mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406\n hci_cmd_sync_work+0x261/0x3a0 net/bluetooth/hci_sync.c:334\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x711/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5987:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4358\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n mgmt_pending_new+0x65/0x240 net/bluetooth/mgmt_util.c:252\n mgmt_pending_add+0x34/0x120 net/bluetooth/mgmt_util.c:279\n remove_adv_monitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:727\n sock_write_iter+0x258/0x330 net/socket.c:1131\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x548/0xa90 fs/read_write.c:686\n ksys_write+0x145/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 5989:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576\n poison_slab_object mm/kasan/common.c:247 [inline]\n __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2380 [inline]\n slab_free mm/slub.c:4642 [inline]\n kfree+0x18e/0x440 mm/slub.c:4841\n mgmt_pending_foreach+0xc9/0x120 net/bluetooth/mgmt_util.c:242\n mgmt_index_removed+0x10d/0x2f0 net/bluetooth/mgmt.c:9366\n hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314\n __sys_bind_socket net/socket.c:1810 [inline]\n __sys_bind+0x2c3/0x3e0 net/socket.c:1841\n __do_sys_bind net/socket.c:1846 [inline]\n __se_sys_bind net/socket.c:1844 [inline]\n __x64_sys_bind+0x7a/0x90 net/socket.c:1844\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-38118)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (asus-ec-sensors) check sensor index in read_string()\n\nPrevent a potential invalid memory access when the requested sensor\nis not found.\n\nfind_ec_sensor_index() may return a negative value (e.g. -ENOENT),\nbut its result was used without checking, which could lead to\nundefined behavior when passed to get_sensor_info().\n\nAdd a proper check to return -EINVAL if sensor_index is negative.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n[groeck: Return error code returned from find_ec_sensor_index](CVE-2025-38142)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: Fix the dead loop of MPLS parse\n\nThe unexpected MPLS packet may not end with the bottom label stack.\nWhen there are many stacks, The label count value has wrapped around.\nA dead loop occurs, soft lockup/CPU stuck finally.\n\nstack backtrace:\nUBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26\nindex -1 is out of range for type \u0026apos;__be32 [3]\u0026apos;\nCPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G           OE   5.15.0-121-generic #131-Ubuntu\nHardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n show_stack+0x52/0x5c\n dump_stack_lvl+0x4a/0x63\n dump_stack+0x10/0x16\n ubsan_epilogue+0x9/0x36\n __ubsan_handle_out_of_bounds.cold+0x44/0x49\n key_extract_l3l4+0x82a/0x840 [openvswitch]\n ? kfree_skbmem+0x52/0xa0\n key_extract+0x9c/0x2b0 [openvswitch]\n ovs_flow_key_extract+0x124/0x350 [openvswitch]\n ovs_vport_receive+0x61/0xd0 [openvswitch]\n ? kernel_init_free_pages.part.0+0x4a/0x70\n ? get_page_from_freelist+0x353/0x540\n netdev_port_receive+0xc4/0x180 [openvswitch]\n ? netdev_port_receive+0x180/0x180 [openvswitch]\n netdev_frame_hook+0x1f/0x40 [openvswitch]\n __netif_receive_skb_core.constprop.0+0x23a/0xf00\n __netif_receive_skb_list_core+0xfa/0x240\n netif_receive_skb_list_internal+0x18e/0x2a0\n napi_complete_done+0x7a/0x1c0\n bnxt_poll+0x155/0x1c0 [bnxt_en]\n __napi_poll+0x30/0x180\n net_rx_action+0x126/0x280\n ? bnxt_msix+0x67/0x80 [bnxt_en]\n handle_softirqs+0xda/0x2d0\n irq_exit_rcu+0x96/0xc0\n common_interrupt+0x8e/0xa0\n \u0026lt;/IRQ\u0026gt;(CVE-2025-38146)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: fix the \u0026apos;para\u0026apos; buffer size to avoid reading out of bounds\n\nSet the size to 6 instead of 2, since \u0026apos;para\u0026apos; array is passed to\n\u0026apos;rtw_fw_bt_wifi_control(rtwdev, para[0], \u0026amp;para[1])\u0026apos;, which reads\n5 bytes:\n\nvoid rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)\n{\n    ...\n    SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);\n    SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));\n    ...\n    SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));\n\nDetected using the static analysis tool - Svace.(CVE-2025-38159)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to do sanity check on sbi-\u0026gt;total_valid_block_count\n\nsyzbot reported a f2fs bug as below:\n\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/f2fs.h:2521!\nRIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521\nCall Trace:\n f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695\n truncate_dnode+0x417/0x740 fs/f2fs/node.c:973\n truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014\n f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197\n f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810\n f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838\n f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888\n f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112\n notify_change+0xbca/0xe90 fs/attr.c:552\n do_truncate+0x222/0x310 fs/open.c:65\n handle_truncate fs/namei.c:3466 [inline]\n do_open fs/namei.c:3849 [inline]\n path_openat+0x2e4f/0x35d0 fs/namei.c:4004\n do_filp_open+0x284/0x4e0 fs/namei.c:4031\n do_sys_openat2+0x12b/0x1d0 fs/open.c:1429\n do_sys_open fs/open.c:1444 [inline]\n __do_sys_creat fs/open.c:1522 [inline]\n __se_sys_creat fs/open.c:1516 [inline]\n __x64_sys_creat+0x124/0x170 fs/open.c:1516\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94\n\nThe reason is: in fuzzed image, sbi-\u0026gt;total_valid_block_count is\ninconsistent w/ mapped blocks indexed by inode, so, we should\nnot trigger panic for such case, instead, let\u0026apos;s print log and\nset fsck flag.(CVE-2025-38163)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: Discard stale CPU state when handling SME traps\n\nThe logic for handling SME traps manipulates saved FPSIMD/SVE/SME state\nincorrectly, and a race with preemption can result in a task having\nTIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state\nis stale (e.g. with SME traps enabled). This can result in warnings from\ndo_sme_acc() where SME traps are not expected while TIF_SME is set:\n\n|        /* With TIF_SME userspace shouldn\u0026apos;t generate any traps */\n|        if (test_and_set_thread_flag(TIF_SME))\n|                WARN_ON(1);\n\nThis is very similar to the SVE issue we fixed in commit:\n\n  751ecf6afd6568ad (\u0026quot;arm64/sve: Discard stale CPU state when handling SVE traps\u0026quot;)\n\nThe race can occur when the SME trap handler is preempted before and\nafter manipulating the saved FPSIMD/SVE/SME state, starting and ending on\nthe same CPU, e.g.\n\n| void do_sme_acc(unsigned long esr, struct pt_regs *regs)\n| {\n|         // Trap on CPU 0 with TIF_SME clear, SME traps enabled\n|         // task-\u0026gt;fpsimd_cpu is 0.\n|         // per_cpu_ptr(\u0026amp;fpsimd_last_state, 0) is task.\n|\n|         ...\n|\n|         // Preempted; migrated from CPU 0 to CPU 1.\n|         // TIF_FOREIGN_FPSTATE is set.\n|\n|         get_cpu_fpsimd_context();\n|\n|         /* With TIF_SME userspace shouldn\u0026apos;t generate any traps */\n|         if (test_and_set_thread_flag(TIF_SME))\n|                 WARN_ON(1);\n|\n|         if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {\n|                 unsigned long vq_minus_one =\n|                         sve_vq_from_vl(task_get_sme_vl(current)) - 1;\n|                 sme_set_vq(vq_minus_one);\n|\n|                 fpsimd_bind_task_to_cpu();\n|         }\n|\n|         put_cpu_fpsimd_context();\n|\n|         // Preempted; migrated from CPU 1 to CPU 0.\n|         // task-\u0026gt;fpsimd_cpu is still 0\n|         // If per_cpu_ptr(\u0026amp;fpsimd_last_state, 0) is still task then:\n|         // - Stale HW state is reused (with SME traps enabled)\n|         // - TIF_FOREIGN_FPSTATE is cleared\n|         // - A return to userspace skips HW state restore\n| }\n\nFix the case where the state is not live and TIF_FOREIGN_FPSTATE is set\nby calling fpsimd_flush_task_state() to detach from the saved CPU\nstate. This ensures that a subsequent context switch will not reuse the\nstale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the\nnew state to be reloaded from memory prior to a return to userspace.\n\nNote: this was originallly posted as [1].\n\n[ Rutland: rewrite commit message ](CVE-2025-38170)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nublk: santizize the arguments from userspace when adding a device\n\nSanity check the values for queue depth and number of queues\nwe get from userspace when adding a device.(CVE-2025-38182)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()\n\nERROR INFO:\n\nCPU 25 Unable to handle kernel paging request at virtual address 0x0\n         ...\n Call Trace:\n [\u0026lt;900000000023c30c\u0026gt;] huge_pte_offset+0x3c/0x58\n [\u0026lt;900000000057fd4c\u0026gt;] hugetlb_follow_page_mask+0x74/0x438\n [\u0026lt;900000000051fee8\u0026gt;] __get_user_pages+0xe0/0x4c8\n [\u0026lt;9000000000522414\u0026gt;] faultin_page_range+0x84/0x380\n [\u0026lt;9000000000564e8c\u0026gt;] madvise_vma_behavior+0x534/0xa48\n [\u0026lt;900000000056689c\u0026gt;] do_madvise+0x1bc/0x3e8\n [\u0026lt;9000000000566df4\u0026gt;] sys_madvise+0x24/0x38\n [\u0026lt;90000000015b9e88\u0026gt;] do_syscall+0x78/0x98\n [\u0026lt;9000000000221f18\u0026gt;] handle_syscall+0xb8/0x158\n\nIn some cases, pmd may be NULL and rely on NULL as the return value for\nprocessing, so it is necessary to determine this situation here.(CVE-2025-38195)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()\n\nbpf_map_lookup_percpu_elem() helper is also available for sleepable bpf\nprogram. When BPF JIT is disabled or under 32-bit host,\nbpf_map_lookup_percpu_elem() will not be inlined. Using it in a\nsleepable bpf program will trigger the warning in\nbpf_map_lookup_percpu_elem(), because the bpf program only holds\nrcu_read_lock_trace lock. Therefore, add the missed check.(CVE-2025-38202)","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-100.0.0.92.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-100.0.0.92.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-100.0.0.92.oe2403.aarch64.rpm","kernel-6.6.0-100.0.0.92.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-100.0.0.92.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-100.0.0.92.oe2403.aarch64.rpm","kernel-devel-6.6.0-100.0.0.92.oe2403.aarch64.rpm","kernel-headers-6.6.0-100.0.0.92.oe2403.aarch64.rpm","kernel-source-6.6.0-100.0.0.92.oe2403.aarch64.rpm","kernel-tools-6.6.0-100.0.0.92.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-100.0.0.92.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-100.0.0.92.oe2403.aarch64.rpm","perf-6.6.0-100.0.0.92.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-100.0.0.92.oe2403.aarch64.rpm","python3-perf-6.6.0-100.0.0.92.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-100.0.0.92.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-100.0.0.92.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-100.0.0.92.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-100.0.0.92.oe2403.x86_64.rpm","kernel-6.6.0-100.0.0.92.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-100.0.0.92.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-100.0.0.92.oe2403.x86_64.rpm","kernel-devel-6.6.0-100.0.0.92.oe2403.x86_64.rpm","kernel-headers-6.6.0-100.0.0.92.oe2403.x86_64.rpm","kernel-source-6.6.0-100.0.0.92.oe2403.x86_64.rpm","kernel-tools-6.6.0-100.0.0.92.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-100.0.0.92.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-100.0.0.92.oe2403.x86_64.rpm","perf-6.6.0-100.0.0.92.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-100.0.0.92.oe2403.x86_64.rpm","python3-perf-6.6.0-100.0.0.92.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-100.0.0.92.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1823"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22033"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23141"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37739"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37784"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37808"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37842"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37854"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37887"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37933"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37951"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37968"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37984"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37991"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38023"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38050"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38067"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38072"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38081"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38090"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38094"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38095"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38099"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38108"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38118"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38142"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38146"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38159"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38163"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38170"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38182"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38195"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38202"}],"database_specific":{"severity":"High"}}