{"schema_version":"1.7.2","id":"OESA-2025-2408","modified":"2025-10-11T13:21:15Z","published":"2025-10-11T13:21:15Z","upstream":["CVE-2022-49234","CVE-2022-50350","CVE-2022-50404","CVE-2023-53241","CVE-2023-53259","CVE-2023-53438","CVE-2025-21801","CVE-2025-22073","CVE-2025-38086","CVE-2025-38313","CVE-2025-38615","CVE-2025-39752","CVE-2025-39865","CVE-2025-39866","CVE-2025-39883"],"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\nnet: dsa: Avoid cross-chip syncing of VLAN filtering\n\nChanges to VLAN filtering are not applicable to cross-chip\nnotifications.\n\nOn a system like this:\n\n.-----.   .-----.   .-----.\n| sw1 +---+ sw2 +---+ sw3 |\n'-1-2-'   '-1-2-'   '-1-2-'\n\nBefore this change, upon sw1p1 leaving a bridge, a call to\ndsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.\n\nIn this scenario:\n\n.---------.   .-----.   .-----.\n|   sw1   +---+ sw2 +---+ sw3 |\n'-1-2-3-4-'   '-1-2-'   '-1-2-'\n\nWhen sw1p4 would leave a bridge, dsa_port_vlan_filtering would be\ncalled for sw2 and sw3 with a non-existing port - leading to array\nout-of-bounds accesses and crashes on mv88e6xxx.(CVE-2022-49234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix a race condition between login_work and the login thread\n\nIn case a malicious initiator sends some random data immediately after a\nlogin PDU; the iscsi_target_sk_data_ready() callback will schedule the\nlogin_work and, at the same time, the negotiation may end without clearing\nthe LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are\nrequired to complete the login).\n\nThe login has been completed but the login_work function will find the\nLOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling\nitself; at this point, if the initiator drops the connection, the\niscsit_conn structure will be freed, login_work will dereference a released\nsocket structure and the kernel crashes.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000230\nPF: supervisor write access in kernel mode\nPF: error_code(0x0002) - not-present page\nWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]\nRIP: 0010:_raw_read_lock_bh+0x15/0x30\nCall trace:\n iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod]\n process_one_work+0x1e8/0x3c0\n\nFix this bug by forcing login_work to stop after the login has been\ncompleted and the socket callbacks have been restored.\n\nAdd a comment to clearify the return values of iscsi_target_do_login()(CVE-2022-50350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: fbcon: release buffer when fbcon_do_set_font() failed\n\nsyzbot is reporting memory leak at fbcon_do_set_font() [1], for\ncommit a5a923038d70 ("fbdev: fbcon: Properly revert changes when\nvc_resize() failed") missed that the buffer might be newly allocated\nby fbcon_set_font().(CVE-2022-50404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: call op_release, even when op_func returns an error\n\nFor ops with "trivial" replies, nfsd4_encode_operation will shortcut\nmost of the encoding work and skip to just marshalling up the status.\nOne of the things it skips is calling op_release. This could cause a\nmemory leak in the layoutget codepath if there is an error at an\ninopportune time.\n\nHave the compound processing engine always call op_release, even when\nop_func sets an error in op->status. With this change, we also need\nnfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL\non error to avoid a double free.(CVE-2023-53241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPF\n\nThe call to get_user_pages_fast() in vmci_host_setup_notify() can return\nNULL context->notify_page causing a GPF. To avoid GPF check if\ncontext->notify_page == NULL and return error if so.\n\ngeneral protection fault, probably for non-canonical address\n    0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: maybe wild-memory-access in range [0x0005088000000300-\n    0x0005088000000307]\nCPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1\nHardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014\nRIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0\nCall Trace:\n <TASK>\n vmci_host_unlocked_ioctl+0x362/0x1f40\n __x64_sys_ioctl+0x1a1/0x230\n do_syscall_64+0x3a/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-53259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/MCE: Always save CS register on AMD Zen IF Poison errors\n\nThe Instruction Fetch (IF) units on current AMD Zen-based systems do not\nguarantee a synchronous #MC is delivered for poison consumption errors.\nTherefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the\nmicroarchitecture does guarantee that the exception is delivered within\nthe same context. In other words, the exact rIP is not known, but the\ncontext is known to not have changed.\n\nThere is no architecturally-defined method to determine this behavior.\n\nThe Code Segment (CS) register is always valid on such IF unit poison\nerrors regardless of the value of MCG_STATUS[EIPV|RIPV].\n\nAdd a quirk to save the CS register for poison consumption from the IF\nunit banks.\n\nThis is needed to properly determine the context of the error.\nOtherwise, the severity grading function will assume the context is\nIN_KERNEL due to the m->cs value being 0 (the initialized value). This\nleads to unnecessary kernel panics on data poison errors due to the\nkernel believing the poison consumption occurred in kernel context.(CVE-2023-53438)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ravb: Fix missing rtnl lock in suspend/resume path\n\nFix the suspend/resume path by ensuring the rtnl lock is held where\nrequired. Calls to ravb_open, ravb_close and wol operations must be\nperformed under the rtnl lock to prevent conflicts with ongoing ndo\noperations.\n\nWithout this fix, the following warning is triggered:\n[   39.032969] =============================\n[   39.032983] WARNING: suspicious RCU usage\n[   39.033019] -----------------------------\n[   39.033033] drivers/net/phy/phy_device.c:2004 suspicious\nrcu_dereference_protected() usage!\n...\n[   39.033597] stack backtrace:\n[   39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted\n6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7\n[   39.033623] Hardware name: Renesas SMARC EVK version 2 based on\nr9a08g045s33 (DT)\n[   39.033628] Call trace:\n[   39.033633]  show_stack+0x14/0x1c (C)\n[   39.033652]  dump_stack_lvl+0xb4/0xc4\n[   39.033664]  dump_stack+0x14/0x1c\n[   39.033671]  lockdep_rcu_suspicious+0x16c/0x22c\n[   39.033682]  phy_detach+0x160/0x190\n[   39.033694]  phy_disconnect+0x40/0x54\n[   39.033703]  ravb_close+0x6c/0x1cc\n[   39.033714]  ravb_suspend+0x48/0x120\n[   39.033721]  dpm_run_callback+0x4c/0x14c\n[   39.033731]  device_suspend+0x11c/0x4dc\n[   39.033740]  dpm_suspend+0xdc/0x214\n[   39.033748]  dpm_suspend_start+0x48/0x60\n[   39.033758]  suspend_devices_and_enter+0x124/0x574\n[   39.033769]  pm_suspend+0x1ac/0x274\n[   39.033778]  state_store+0x88/0x124\n[   39.033788]  kobj_attr_store+0x14/0x24\n[   39.033798]  sysfs_kf_write+0x48/0x6c\n[   39.033808]  kernfs_fop_write_iter+0x118/0x1a8\n[   39.033817]  vfs_write+0x27c/0x378\n[   39.033825]  ksys_write+0x64/0xf4\n[   39.033833]  __arm64_sys_write+0x18/0x20\n[   39.033841]  invoke_syscall+0x44/0x104\n[   39.033852]  el0_svc_common.constprop.0+0xb4/0xd4\n[   39.033862]  do_el0_svc+0x18/0x20\n[   39.033870]  el0_svc+0x3c/0xf0\n[   39.033880]  el0t_64_sync_handler+0xc0/0xc4\n[   39.033888]  el0t_64_sync+0x154/0x158\n[   39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspufs: fix a leak on spufs_new_file() failure\n\nIt's called from spufs_fill_dir(), and caller of that will do\nspufs_rmdir() in case of failure.  That does remove everything\nwe'd managed to create, but... the problem dentry is still\nnegative.  IOW, it needs to be explicitly dropped.(CVE-2025-22073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called "buff", which is initialised\nwith control_read(). However "buff" is conditionally\ninitialised inside control_read():\n\n        if (err == size) {\n                memcpy(data, buf, size);\n        }\n\nIf the condition of "err == size" is not met, then\n"buff" remains uninitialised. Once this happens the\nuninitialised "buff" is accessed and returned during\nch9200_mdio_read():\n\n        return (buff[0] | buff[1] << 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of "buff".\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: fix double-free on mc_dev\n\nThe blamed commit tried to simplify how the deallocations are done but,\nin the process, introduced a double-free on the mc_dev variable.\n\nIn case the MC device is a DPRC, a new mc_bus is allocated and the\nmc_dev variable is just a reference to one of its fields. In this\ncircumstance, on the error path only the mc_bus should be freed.\n\nThis commit introduces back the following checkpatch warning which is a\nfalse-positive.\n\nWARNING: kfree(NULL) is safe and this check is probably not required\n+       if (mc_bus)\n+               kfree(mc_bus);(CVE-2025-38313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: cancle set bad inode after removing name fails\n\nThe reproducer uses a file0 on a ntfs3 file system with a corrupted i_link.\nWhen renaming, the file0's inode is marked as a bad inode because the file\nname cannot be deleted.\n\nThe underlying bug is that make_bad_inode() is called on a live inode.\nIn some cases it's "icache lookup finds a normal inode, d_splice_alias()\nis called to attach it to dentry, while another thread decides to call\nmake_bad_inode() on it - that would evict it from icache, but we'd already\nfound it there earlier".\nIn some it's outright "we have an inode attached to dentry - that's how we\ngot it in the first place; let's call make_bad_inode() on it just for shits\nand giggles".(CVE-2025-38615)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn't expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[    0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[    0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntee: fix NULL pointer dereference in tee_shm_put\n\ntee_shm_put have NULL pointer dereference:\n\n__optee_disable_shm_cache -->\n\tshm = reg_pair_to_ptr(...);//shm maybe return NULL\n        tee_shm_free(shm); -->\n\t\ttee_shm_put(shm);//crash\n\nAdd check in tee_shm_put to fix it.\n\npanic log:\nUnable to handle kernel paging request at virtual address 0000000000100cca\nMem abort info:\nESR = 0x0000000096000004\nEC = 0x25: DABT (current EL), IL = 32 bits\nSET = 0, FnV = 0\nEA = 0, S1PTW = 0\nFSC = 0x04: level 0 translation fault\nData abort info:\nISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\nCM = 0, WnR = 0, TnD = 0, TagAccess = 0\nGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000\n[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] SMP\nCPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----\n6.6.0-39-generic #38\nSource Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07\nHardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0\n10/26/2022\npstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : tee_shm_put+0x24/0x188\nlr : tee_shm_free+0x14/0x28\nsp : ffff001f98f9faf0\nx29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000\nx26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048\nx23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88\nx20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff\nx17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003\nx14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101\nx11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c\nx8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca\nCall trace:\ntee_shm_put+0x24/0x188\ntee_shm_free+0x14/0x28\n__optee_disable_shm_cache+0xa8/0x108\noptee_shutdown+0x28/0x38\nplatform_shutdown+0x28/0x40\ndevice_shutdown+0x144/0x2b0\nkernel_power_off+0x3c/0x80\nhibernate+0x35c/0x388\nstate_store+0x64/0x80\nkobj_attr_store+0x14/0x28\nsysfs_kf_write+0x48/0x60\nkernfs_fop_write_iter+0x128/0x1c0\nvfs_write+0x270/0x370\nksys_write+0x6c/0x100\n__arm64_sys_write+0x20/0x30\ninvoke_syscall+0x4c/0x120\nel0_svc_common.constprop.0+0x44/0xf0\ndo_el0_svc+0x24/0x38\nel0_svc+0x24/0x88\nel0t_64_sync_handler+0x134/0x150\nel0t_64_sync+0x14c/0x15(CVE-2025-39865)\n\nIn the Linux kernel, a use-after-free vulnerability exists in the __mark_inode_dirty() function. The issue occurs when __mark_inode_dirty() obtains a bdi_writeback that is in the process of switching. This is a race condition vulnerability between inode_switch_wbs_work_fn() and ___mark_inode_dirty(), causing the old writeback structure to be accessed after it has been released, triggering a use-after-free vulnerability.(CVE-2025-39866)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory\n\nWhen I did memory failure tests, below panic occurs:\n\npage dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))\nkernel BUG at include/linux/page-flags.h:616!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nCall Trace:\n <TASK>\n unpoison_memory+0x2f3/0x590\n simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110\n debugfs_attr_write+0x42/0x60\n full_proxy_write+0x5b/0x80\n vfs_write+0xd5/0x540\n ksys_write+0x64/0xe0\n do_syscall_64+0xb9/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f08f0314887\nRSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887\nRDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001\nRBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009\nR13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00\n </TASK>\nModules linked in: hwpoison_inject\n---[ end trace 0000000000000000 ]---\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\n\nThe root cause is that unpoison_memory() tries to check the PG_HWPoison\nflags of an uninitialized page.  So VM_BUG_ON_PAGE(PagePoisoned(page)) is\ntriggered.  This can be reproduced by below steps:\n\n1.Offline memory block:\n\n echo offline > /sys/devices/system/memory/memory12/state\n\n2.Get offlined memory pfn:\n\n page-types -b n -rlN\n\n3.Write pfn to unpoison-pfn\n\n echo <pfn> > /sys/kernel/debug/hwpoison/unpoison-pfn\n\nThis scenario can be identified by pfn_to_online_page() returning NULL. \nAnd ZONE_DEVICE pages are never expected, so we can simply fail if\npfn_to_online_page() == NULL to fix the bug.(CVE-2025-39883)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-284.0.0.187.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","kernel-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","perf-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-284.0.0.187.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","kernel-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","perf-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2408"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49234"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50350"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50404"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53241"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53259"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53438"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21801"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22073"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38086"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38313"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38615"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39752"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39865"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39866"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39883"}],"database_specific":{"severity":"High"}}