{"schema_version":"1.7.2","id":"OESA-2025-2883","modified":"2025-12-30T12:16:59Z","published":"2025-12-30T12:16:59Z","upstream":["CVE-2024-50269","CVE-2024-50279","CVE-2024-53076","CVE-2024-56599","CVE-2025-21905","CVE-2025-21922","CVE-2025-23158","CVE-2025-23160","CVE-2025-37756","CVE-2025-37775","CVE-2025-37776","CVE-2025-37850","CVE-2025-37927","CVE-2025-38560","CVE-2025-39901","CVE-2025-39942","CVE-2025-40040","CVE-2025-40170"],"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:usb: musb: sunxi: Fix accessing an released usb phyCommit 6ed05c68cbca ( usb: musb: sunxi: Explicitly release USB PHY onexit ) will cause that usb phy @glue->xceiv is accessed after released.1) register platform driver @sunxi_musb_driver// get the usb phy @glue->xceivsunxi_musb_probe() -> devm_usb_get_phy().2) register and unregister platform driver @musb_drivermusb_probe() -> sunxi_musb_init()use the phy here//the phy is released heremusb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy()3) register @musb_driver againmusb_probe() -> sunxi_musb_init()use the phy here but the phy has been released at 2)....Fixed by reverting the commit, namely, removing devm_usb_put_phy()from sunxi_musb_exit().(CVE-2024-50269)\n\nIn the Linux kernel, the following vulnerability has been resolved:dm cache: fix out-of-bounds access to the dirty bitset when resizingdm-cache checks the dirty bits of the cache blocks to be dropped whenshrinking the fast device, but an index bug in bitset iteration causesout-of-bounds access.Reproduce steps:1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)dmsetup create cmeta --table  0 8192 linear /dev/sdc 0 dmsetup create cdata --table  0 131072 linear /dev/sdc 8192 dmsetup create corig --table  0 524288 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table  0 524288 cache /dev/mapper/cmeta  /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds   access to the dirty bitset (offset 0x80)dmsetup suspend cachedmsetup reload cdata --table  0 65536 linear /dev/sdc 8192 dmsetup resume cdatadmsetup resume cacheKASAN reports:  BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0  Read of size 8 at addr ffffc900000f3080 by task dmsetup/131  (...snip...)  The buggy address belongs to the virtual mapping at   [ffffc900000f3000, ffffc900000f5000) created by:   cache_ctr+0x176a/0x35f0  (...snip...)  Memory state around the buggy address:   ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8   ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8                     ^   ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8   ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by making the index post-incremented.(CVE-2024-50279)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loopof iio_gts_build_avail_scale_table(), the err_free_out will fail to callkfree() each time when i is reduced to 0, so all the per_time_scales[0]and per_time_gains[0] will not be freed, which will cause memory leaks.Fix it by checking if i >= 0.(CVE-2024-53076)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running 'rmmod ath10k', ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during 'rmmod ath10k', ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n  ->ath10k_core_unregister\n    ……\n    ->ath10k_core_stop\n      ->ath10k_hif_stop\n        ->ath10k_sdio_irq_disable\n    ->ath10k_hif_power_down\n      ->del_timer_sync(&ar_sdio->sleep_timer)\n  ->ath10k_core_destroy\n    ->ath10k_mac_destroy\n      ->ieee80211_free_hw\n        ->wiphy_free\n    ……\n          ->wiphy_dev_release\n  ->destroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won't be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere's no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that's the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: Fix KMSAN uninit-value warning with bpf\n\nSyzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the\nppp driver not initializing a 2-byte header when using socket filter.\n\nThe following code can generate a PPP filter BPF program:\n'''\nstruct bpf_program fp;\npcap_t *handle;\nhandle = pcap_open_dead(DLT_PPP_PPPD, 65535);\npcap_compile(handle, &fp, "ip and outbound", 0, 0);\nbpf_dump(&fp, 1);\n'''\nIts output is:\n'''\n(000) ldh [2]\n(001) jeq #0x21 jt 2 jf 5\n(002) ldb [0]\n(003) jeq #0x1 jt 4 jf 5\n(004) ret #65535\n(005) ret #0\n'''\nWen can find similar code at the following link:\nhttps://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680\nThe maintainer of this code repository is also the original maintainer\nof the ppp driver.\n\nAs you can see the BPF program skips 2 bytes of data and then reads the\n'Protocol' field to determine if it's an IP packet. Then it read the first\nbyte of the first 2 bytes to determine the direction.\n\nThe issue is that only the first byte indicating direction is initialized\nin current ppp driver code while the second byte is not initialized.\n\nFor normal BPF programs generated by libpcap, uninitialized data won't be\nused, so it's not a problem. However, for carefully crafted BPF programs,\nsuch as those generated by syzkaller [2], which start reading from offset\n0, the uninitialized data will be used and caught by KMSAN.\n\n[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791\n[2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000(CVE-2025-21922)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr->q_size\n\nif (wr_idx >= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx < qsize) {\n memcpy(wr_ptr, packet, dwords << 2) --> OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization\n\nOn Mediatek devices with a system companion processor (SCP) the mtk_scp\nstructure has to be removed explicitly to avoid a resource leak.\nFree the structure in case the allocation of the firmware structure fails\nduring the firmware initialization.(CVE-2025-23160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: explicitly disallow disconnect\n\nsyzbot discovered that it can disconnect a TLS socket and then\nrun into all sort of unexpected corner cases. I have a vague\nrecollection of Eric pointing this out to us a long time ago.\nSupporting disconnect is really hard, for one thing if offload\nis enabled we'd need to wait for all packets to be _acked_.\nDisconnect is not commonly used, disallow it.\n\nThe immediate problem syzbot run into is the warning in the strp,\nbut that's just the easiest bug to trigger:\n\n  WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n  RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n  Call Trace:\n   <TASK>\n   tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363\n   tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043\n   inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678\n   sock_recvmsg_nosec net/socket.c:1023 [inline]\n   sock_recvmsg+0x109/0x280 net/socket.c:1045\n   __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix the warning from __kernel_write_iter\n\n[ 2110.972290] ------------[ cut here ]------------\n[ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280\n\nThis patch doesn't allow writing to directory.(CVE-2025-37775)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb_break_all_levII_oplock()\n\nThere is a room in smb_break_all_levII_oplock that can cause racy issues\nwhen unlocking in the middle of the loop. This patch use read lock\nto protect whole loop.(CVE-2025-37776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()\n\nWith CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a\ndivide-by-zero in the following line:\n\n\tdo_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));\n\ndue to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()\nreturns zero.\n\nThis is presumably just a theoretical problem: COMPILE_TEST overrides\nthe dependency on RALINK which would select COMMON_CLK.  Regardless it's\na good idea to check for the error explicitly to avoid divide-by-zero.\n\nFixes the following warning:\n\n  drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section\n\n[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/](CVE-2025-37850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn't\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Evict cache lines during SNP memory validation\n\nAn SNP cache coherency vulnerability requires a cache line eviction\nmitigation when validating memory after a page state change to private.\nThe specific mitigation is to touch the first and last byte of each 4K\npage that is being validated. There is no need to perform the mitigation\nwhen performing a page state change to shared and rescinding validation.\n\nCPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit\nthat, when set, indicates that the software mitigation for this\nvulnerability is not needed.\n\nImplement the mitigation and invoke it when validating memory (making it\nprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNP\nguest is vulnerable.(CVE-2025-38560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe 'command' and 'netdev_ops' debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c ("i40e: debugfs interface").\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe 'command' file this buffer is literally never used and simply wastes\nspace. In the case of the 'netdev_ops' file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For 'command' this will always be "<device>: ". For 'netdev_ops',\nthis will be "<device>: <last command written>". But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn't appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the 'command' file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the 'netdev_ops' file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don't believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the 'netdev_ops' interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size\n\nThis is inspired by the check for data_offset + data_length.(CVE-2025-39942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/ksm: fix flag-dropping behavior in ksm_madvise\n\nsyzkaller discovered the following crash: (kernel BUG)\n\n[   44.607039] ------------[ cut here ]------------\n[   44.607422] kernel BUG at mm/userfaultfd.c:2067!\n[   44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[   44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)\n[   44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[   44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460\n\n<snip other registers, drop unreliable trace>\n\n[   44.617726] Call Trace:\n[   44.617926]  <TASK>\n[   44.619284]  userfaultfd_release+0xef/0x1b0\n[   44.620976]  __fput+0x3f9/0xb60\n[   44.621240]  fput_close_sync+0x110/0x210\n[   44.622222]  __x64_sys_close+0x8f/0x120\n[   44.622530]  do_syscall_64+0x5b/0x2f0\n[   44.622840]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[   44.623244] RIP: 0033:0x7f365bb3f227\n\nKernel panics because it detects UFFD inconsistency during\nuserfaultfd_release_all().  Specifically, a VMA which has a valid pointer\nto vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.\n\nThe inconsistency is caused in ksm_madvise(): when user calls madvise()\nwith MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,\nit accidentally clears all flags stored in the upper 32 bits of\nvma->vm_flags.\n\nAssuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and\nint are 32-bit wide.  This setup causes the following mishap during the &=\n~VM_MERGEABLE assignment.\n\nVM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. \nAfter ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then\npromoted to unsigned long before the & operation.  This promotion fills\nupper 32 bits with leading 0s, as we're doing unsigned conversion (and\neven for a signed conversion, this wouldn't help as the leading bit is 0).\n& operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff\ninstead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears\nthe upper 32-bits of its value.\n\nFix it by changing `VM_MERGEABLE` constant to unsigned long, using the\nBIT() macro.\n\nNote: other VM_* flags are not affected: This only happens to the\nVM_MERGEABLE flag, as the other VM_* flags are all constants of type int\nand after ~ operation, they end up with leading 1 and are thus converted\nto unsigned long with leading 1s.\n\nNote 2:\nAfter commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is\nno longer a kernel BUG, but a WARNING at the same place:\n\n[   45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067\n\nbut the root-cause (flag-drop) remains the same.\n\n[(CVE-2025-40040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst->dev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-129.0.0.127.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","kernel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","perf-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-129.0.0.127.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","kernel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","perf-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2883"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50269"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50279"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53076"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56599"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21905"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21922"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23158"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23160"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37756"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37775"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37776"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37850"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37927"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38560"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39901"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39942"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40040"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40170"}],"database_specific":{"severity":"High"}}