{"schema_version":"1.7.2","id":"OESA-2025-2270","modified":"2025-09-12T14:25:49Z","published":"2025-09-12T14:25:49Z","upstream":["CVE-2025-21962","CVE-2025-21967","CVE-2025-37924","CVE-2025-38102","CVE-2025-38119","CVE-2025-38227","CVE-2025-38305","CVE-2025-38312","CVE-2025-38334","CVE-2025-38399","CVE-2025-38502","CVE-2025-38574","CVE-2025-38584","CVE-2025-38590","CVE-2025-38593","CVE-2025-38621","CVE-2025-38635","CVE-2025-38645","CVE-2025-38687","CVE-2025-39689"],"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\ncifs: Fix integer overflow while processing closetimeo mount option\n\nUser-provided mount parameter closetimeo 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-21962)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in ksmbd_free_work_struct\n\n->interim_entry of ksmbd_work could be deleted after oplock is freed.\nWe don't need to manage it with linked list. The interim request could be\nimmediately sent whenever a oplock break wait is needed.(CVE-2025-21967)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in kerberos authentication\n\nSetting sess->user = NULL was introduced to fix the dangling pointer\ncreated by ksmbd_free_user. However, it is possible another thread could\nbe operating on the session and make use of sess->user after it has been\npassed to ksmbd_free_user but before sess->user is set to NULL.(CVE-2025-37924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify\n\nDuring our test, it is found that a warning can be trigger in try_grab_folio\nas follow:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)\n  RIP: 0010:try_grab_folio+0x106/0x130\n  Call Trace:\n   <TASK>\n   follow_huge_pmd+0x240/0x8e0\n   follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0\n   follow_pud_mask.constprop.0.isra.0+0x14a/0x170\n   follow_page_mask+0x1c2/0x1f0\n   __get_user_pages+0x176/0x950\n   __gup_longterm_locked+0x15b/0x1060\n   ? gup_fast+0x120/0x1f0\n   gup_fast_fallback+0x17e/0x230\n   get_user_pages_fast+0x5f/0x80\n   vmci_host_unlocked_ioctl+0x21c/0xf80\n  RIP: 0033:0x54d2cd\n  ---[ end trace 0000000000000000 ]---\n\nDigging into the source, context->notify_page may init by get_user_pages_fast\nand can be seen in vmci_ctx_unset_notify which will try to put_page. However\nget_user_pages_fast is not finished here and lead to following\ntry_grab_folio warning. The race condition is shown as follow:\n\ncpu0\t\t\tcpu1\nvmci_host_do_set_notify\nvmci_host_setup_notify\nget_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);\nlockless_pages_from_mm\ngup_pgd_range\ngup_huge_pmd  // update &context->notify_page\n\t\t\tvmci_host_do_set_notify\n\t\t\tvmci_ctx_unset_notify\n\t\t\tnotify_page = context->notify_page;\n\t\t\tif (notify_page)\n\t\t\tput_page(notify_page);\t// page is freed\n__gup_longterm_locked\n__get_user_pages\nfollow_trans_huge_pmd\ntry_grab_folio // warn here\n\nTo slove this, use local variable page to make notify_page can be seen\nafter finish get_user_pages_fast.(CVE-2025-38102)\n\nIn the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler. ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before.(CVE-2025-38119)\n\nIn the Linux kernel's vidtv driver, a slab-use-after-free vulnerability was discovered when the program incorrectly continued accessing the freed memory structure member 'si' after PSI initialization failure. This vulnerability could potentially lead to kernel crashes or information disclosure.(CVE-2025-38227)\n\nIn the Linux kernel, a recursive locking issue was identified in the ptp_vclock_in_use() function. When reading ptp->n_vclocks through ptp->n_vclocks_mux, it triggers a recursive lock call chain starting from n_vclocks_store(), leading to a potential deadlock. The root cause is the redundant check for ptp->n_vclocks in ptp_vclock_in_use(), as other functions already ensure ptp->n_vclocks is checked before unregistering vclocks.(CVE-2025-38305)\n\nIn the Linux kernel, a vulnerability has been identified in the fbdev core component's fbcvt module. When mode->refresh is set to 0x80000000, in the fb_find_mode_cvt() function, cvt.f_refresh becomes 0 due to overflow. This value is then passed to fb_cvt_hperiod() where it is used as a divisor, leading to a division by zero error and potential kernel crash. This vulnerability was discovered by the Linux Verification Center using the Svace static analysis tool.(CVE-2025-38312)\n\nIn the Linux kernel's x86/sgx component, a vulnerability exists that allows attempts to reclaim SGX pages marked as poisoned. The SGX page reclamation process accesses page contents to copy them to secondary storage, but SGX instructions cannot gracefully handle Machine Check Exceptions (MCE). Existing code fails to check the epc_page->poison flag, potentially causing reclamation operations on known poisoned pages, which may lead to core shutdowns or kernel panics. This vulnerability is triggered through the memory error notification path and requires prevention of poisoned pages being added to reclamation candidate lists.(CVE-2025-38334)\n\nA NULL pointer dereference vulnerability exists in the Linux kernel's target subsystem. The function core_scsi3_decode_spec_i_port() unconditionally calls core_scsi3_lunacl_undepend_item() passing a potentially NULL dest_se_deve pointer in its error handling path, leading to kernel NULL pointer dereference. This vulnerability could be exploited to cause kernel crashes.(CVE-2025-38399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix oob access in cgroup local storage\n\nLonial reported that an out-of-bounds access in cgroup local storage\ncan be crafted via tail calls. Given two programs each utilizing a\ncgroup local storage with a different value size, and one program\ndoing a tail call into the other. The verifier will validate each of\nthe indivial programs just fine. However, in the runtime context\nthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains the\nBPF program as well as any cgroup local storage flavor the program\nuses. Helpers such as bpf_get_local_storage() pick this up from the\nruntime context:\n\n  ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx);\n  storage = ctx->prog_item->cgroup_storage[stype];\n\n  if (stype == BPF_CGROUP_STORAGE_SHARED)\n    ptr = &READ_ONCE(storage->buf)->data[0];\n  else\n    ptr = this_cpu_ptr(storage->percpu_buf);\n\nFor the second program which was called from the originally attached\none, this means bpf_get_local_storage() will pick up the former\nprogram's map, not its own. With mismatching sizes, this can result\nin an unintended out-of-bounds access.\n\nTo fix this issue, we need to extend bpf_map_owner with an array of\nstorage_cookie[] to match on i) the exact maps from the original\nprogram if the second program was using bpf_get_local_storage(), or\nii) allow the tail call combination if the second program was not\nusing any of the cgroup local storage maps.(CVE-2025-38502)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npptp: ensure minimal skb length in pptp_xmit()\n\nCommit aabc6596ffb3 ("net: ppp: Add bound checking for skb data\non ppp_sync_txmung") fixed ppp_sync_txmunge()\n\nWe need a similar fix in pptp_xmit(), otherwise we might\nread uninit data as reported by syzbot.\n\nBUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n  pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n  ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]\n  ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314\n  pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379\n  sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148\n  __release_sock+0x1d3/0x330 net/core/sock.c:3213\n  release_sock+0x6b/0x270 net/core/sock.c:3767\n  pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904\n  sock_sendmsg_nosec net/socket.c:712 [inline]\n  __sock_sendmsg+0x330/0x3d0 net/socket.c:727\n  ____sys_sendmsg+0x893/0xd80 net/socket.c:2566\n  ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620\n  __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix pd UAF once and for all\n\nThere is a race condition/UAF in padata_reorder that goes back\nto the initial commit.  A reference count is taken at the start\nof the process in padata_do_parallel, and released at the end in\npadata_serial_worker.\n\nThis reference count is (and only is) required for padata_replace\nto function correctly.  If padata_replace is never called then\nthere is no issue.\n\nIn the function padata_reorder which serves as the core of padata,\nas soon as padata is added to queue->serial.list, and the associated\nspin lock released, that padata may be processed and the reference\ncount on pd would go away.\n\nFix this by getting the next padata before the squeue->serial lock\nis released.\n\nIn order to make this possible, simplify padata_reorder by only\ncalling it once the next padata arrives.(CVE-2025-38584)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Remove skb secpath if xfrm state is not found\n\nHardware returns a unique identifier for a decrypted packet's xfrm\nstate, this state is looked up in an xarray. However, the state might\nhave been freed by the time of this lookup.\n\nCurrently, if the state is not found, only a counter is incremented.\nThe secpath (sp) extension on the skb is not removed, resulting in\nsp->len becoming 0.\n\nSubsequently, functions like __xfrm_policy_check() attempt to access\nfields such as xfrm_input_state(skb)->xso.type (which dereferences\nsp->xvec[sp->len - 1]) without first validating sp->len. This leads to\na crash when dereferencing an invalid state pointer.\n\nThis patch prevents the crash by explicitly removing the secpath\nextension from the skb if the xfrm state is not found after hardware\ndecryption. This ensures downstream functions do not operate on a\nzero-length secpath.\n\n BUG: unable to handle page fault for address: ffffffff000002c8\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 282e067 P4D 282e067 PUD 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:__xfrm_policy_check+0x61a/0xa30\n Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa\n RSP: 0018:ffff88885fb04918 EFLAGS: 00010297\n RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000\n RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000\n RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353\n R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8\n R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00\n FS:  0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  <IRQ>\n  ? try_to_wake_up+0x108/0x4c0\n  ? udp4_lib_lookup2+0xbe/0x150\n  ? udp_lib_lport_inuse+0x100/0x100\n  ? __udp4_lib_lookup+0x2b0/0x410\n  __xfrm_policy_check2.constprop.0+0x11e/0x130\n  udp_queue_rcv_one_skb+0x1d/0x530\n  udp_unicast_rcv_skb+0x76/0x90\n  __udp4_lib_rcv+0xa64/0xe90\n  ip_protocol_deliver_rcu+0x20/0x130\n  ip_local_deliver_finish+0x75/0xa0\n  ip_local_deliver+0xc1/0xd0\n  ? ip_protocol_deliver_rcu+0x130/0x130\n  ip_sublist_rcv+0x1f9/0x240\n  ? ip_rcv_finish_core+0x430/0x430\n  ip_list_rcv+0xfc/0x130\n  __netif_receive_skb_list_core+0x181/0x1e0\n  netif_receive_skb_list_internal+0x200/0x360\n  ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core]\n  gro_receive_skb+0xfd/0x210\n  mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core]\n  mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core]\n  ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core]\n  mlx5e_napi_poll+0x114/0xab0 [mlx5_core]\n  __napi_poll+0x25/0x170\n  net_rx_action+0x32d/0x3a0\n  ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core]\n  ? notifier_call_chain+0x33/0xa0\n  handle_softirqs+0xda/0x250\n  irq_exit_rcu+0x6d/0xc0\n  common_interrupt+0x81/0xa0\n  </IRQ>(CVE-2025-38590)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'\n\nFunction 'hci_discovery_filter_clear()' frees 'uuids' array and then\nsets it to NULL. There is a tiny chance of the following race:\n\n'hci_cmd_sync_work()'\n\n 'update_passive_scan_sync()'\n\n   'hci_update_passive_scan_sync()'\n\n     'hci_discovery_filter_clear()'\n       kfree(uuids);\n\n       <-------------------------preempted-------------------------------->\n                                           'start_service_discovery()'\n\n                                             'hci_discovery_filter_clear()'\n                                               kfree(uuids); // DOUBLE FREE\n\n       <-------------------------preempted-------------------------------->\n\n      uuids = NULL;\n\nTo fix it let's add locking around 'kfree()' call and NULL pointer\nassignment. Otherwise the following backtrace fires:\n\n[ ] ------------[ cut here ]------------\n[ ] kernel BUG at mm/slub.c:547!\n[ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n[ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1\n[ ] Tainted: [O]=OOT_MODULE\n[ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ ] pc : __slab_free+0xf8/0x348\n[ ] lr : __slab_free+0x48/0x348\n...\n[ ] Call trace:\n[ ]  __slab_free+0xf8/0x348\n[ ]  kfree+0x164/0x27c\n[ ]  start_service_discovery+0x1d0/0x2c0\n[ ]  hci_sock_sendmsg+0x518/0x924\n[ ]  __sock_sendmsg+0x54/0x60\n[ ]  sock_write_iter+0x98/0xf8\n[ ]  do_iter_readv_writev+0xe4/0x1c8\n[ ]  vfs_writev+0x128/0x2b0\n[ ]  do_writev+0xfc/0x118\n[ ]  __arm64_sys_writev+0x20/0x2c\n[ ]  invoke_syscall+0x68/0xf0\n[ ]  el0_svc_common.constprop.0+0x40/0xe0\n[ ]  do_el0_svc+0x1c/0x28\n[ ]  el0_svc+0x30/0xd0\n[ ]  el0t_64_sync_handler+0x100/0x12c\n[ ]  el0t_64_sync+0x194/0x198\n[ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)\n[ ] ---[ end trace 0000000000000000 ]---(CVE-2025-38593)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: make rdev_addable usable for rcu mode\n\nOur testcase trigger panic:\n\nBUG: kernel NULL pointer dereference, address: 00000000000000e0\n...\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94\nPREEMPT(none)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nWorkqueue: md_misc md_start_sync\nRIP: 0010:rdev_addable+0x4d/0xf0\n...\nCall Trace:\n <TASK>\n md_start_sync+0x329/0x480\n process_one_work+0x226/0x6d0\n worker_thread+0x19e/0x340\n kthread+0x10f/0x250\n ret_from_fork+0x14d/0x180\n ret_from_fork_asm+0x1a/0x30\n </TASK>\nModules linked in: raid10\nCR2: 00000000000000e0\n---[ end trace 0000000000000000 ]---\nRIP: 0010:rdev_addable+0x4d/0xf0\n\nmd_spares_need_change in md_start_sync will call rdev_addable which\nprotected by rcu_read_lock/rcu_read_unlock. This rcu context will help\nprotect rdev won't be released, but rdev->mddev will be set to NULL\nbefore we call synchronize_rcu in md_kick_rdev_from_array. Fix this by\nusing READ_ONCE and check does rdev->mddev still alive.(CVE-2025-38621)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: davinci: Add NULL check in davinci_lpsc_clk_register()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\ndavinci_lpsc_clk_register() does not check for this case, which results\nin a NULL pointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue and ensuring\nno resources are left allocated.(CVE-2025-38635)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Check device memory pointer before usage\n\nAdd a NULL check before accessing device memory to prevent a crash if\ndev->dm allocation in mlx5_init_once() fails.(CVE-2025-38645)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: fix race between polling and detaching\n\nsyzbot reports a use-after-free in comedi in the below link, which is\ndue to comedi gladly removing the allocated async area even though poll\nrequests are still active on the wait_queue_head inside of it. This can\ncause a use-after-free when the poll entries are later triggered or\nremoved, as the memory for the wait_queue_head has been freed.  We need\nto check there are no tasks queued on any of the subdevices' wait queues\nbefore allowing the device to be detached by the `COMEDI_DEVCONFIG`\nioctl.\n\nTasks will read-lock `dev->attach_lock` before adding themselves to the\nsubdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl\nhandler by write-locking `dev->attach_lock` before checking that all of\nthe subdevices are safe to be deleted.  This includes testing for any\nsleepers on the subdevices' wait queues.  It remains locked until the\ndevice has been detached.  This requires the `comedi_device_detach()`\nfunction to be refactored slightly, moving the bulk of it into new\nfunction `comedi_device_detach_locked()`.\n\nNote that the refactor of `comedi_device_detach()` results in\n`comedi_device_cancel_all()` now being called while `dev->attach_lock`\nis write-locked, which wasn't the case previously, but that does not\nmatter.\n\nThanks to Jens Axboe for diagnosing the problem and co-developing this\npatch.(CVE-2025-38687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Also allocate and copy hash for reading of filter files\n\nCurrently the reader of set_ftrace_filter and set_ftrace_notrace just adds\nthe pointer to the global tracer hash to its iterator. Unlike the writer\nthat allocates a copy of the hash, the reader keeps the pointer to the\nfilter hashes. This is problematic because this pointer is static across\nfunction calls that release the locks that can update the global tracer\nhashes. This can cause UAF and similar bugs.\n\nAllocate and copy the hash for reading the filter files like it is done\nfor the writers. This not only fixes UAF bugs, but also makes the code a\nbit simpler as it doesn't have to differentiate when to free the\niterator's hash between writers and readers.(CVE-2025-39689)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP2","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP2"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-109.0.0.115.oe2403sp2"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","bpftool-debuginfo-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","kernel-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","kernel-debuginfo-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","kernel-debugsource-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","kernel-devel-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","kernel-extra-modules-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","kernel-headers-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","kernel-source-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","kernel-tools-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","kernel-tools-debuginfo-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","kernel-tools-devel-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","perf-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","perf-debuginfo-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","python3-perf-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm","python3-perf-debuginfo-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm"],"src":["kernel-6.6.0-109.0.0.115.oe2403sp2.src.rpm"],"x86_64":["bpftool-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","bpftool-debuginfo-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","kernel-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","kernel-debuginfo-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","kernel-debugsource-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","kernel-devel-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","kernel-extra-modules-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","kernel-headers-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","kernel-source-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","kernel-tools-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","kernel-tools-debuginfo-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","kernel-tools-devel-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","perf-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","perf-debuginfo-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","python3-perf-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm","python3-perf-debuginfo-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2270"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21962"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21967"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37924"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38102"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38119"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38227"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38305"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38312"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38334"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38399"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38502"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38574"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38584"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38590"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38593"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38621"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38635"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38645"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38687"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39689"}],"database_specific":{"severity":"High"}}