{"schema_version":"1.7.2","id":"OESA-2026-1075","modified":"2026-01-16T11:57:48Z","published":"2026-01-16T11:57:48Z","upstream":["CVE-2022-50635","CVE-2022-50746","CVE-2023-53781","CVE-2023-53821","CVE-2023-53846","CVE-2023-53861","CVE-2025-39949","CVE-2025-39969","CVE-2025-39970","CVE-2025-40200","CVE-2025-68171","CVE-2025-68734","CVE-2025-68745"],"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\npowerpc/kprobes: Fix null pointer reference in arch_prepare_kprobe()\n\nI found a null pointer reference in arch_prepare_kprobe():\n\n  # echo &apos;p cmdline_proc_show&apos; &gt; kprobe_events\n  # echo &apos;p cmdline_proc_show+16&apos; &gt;&gt; kprobe_events\n  Kernel attempted to read user page (0) - exploit attempt? (uid: 0)\n  BUG: Kernel NULL pointer dereference on read at 0x00000000\n  Faulting instruction address: 0xc000000000050bfc\n  Oops: Kernel access of bad area, sig: 11 [#1]\n  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV\n  Modules linked in:\n  CPU: 0 PID: 122 Comm: sh Not tainted 6.0.0-rc3-00007-gdcf8e5633e2e #10\n  NIP:  c000000000050bfc LR: c000000000050bec CTR: 0000000000005bdc\n  REGS: c0000000348475b0 TRAP: 0300   Not tainted  (6.0.0-rc3-00007-gdcf8e5633e2e)\n  MSR:  9000000000009033 &lt;SF,HV,EE,ME,IR,DR,RI,LE&gt;  CR: 88002444  XER: 20040006\n  CFAR: c00000000022d100 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0\n  ...\n  NIP arch_prepare_kprobe+0x10c/0x2d0\n  LR  arch_prepare_kprobe+0xfc/0x2d0\n  Call Trace:\n    0xc0000000012f77a0 (unreliable)\n    register_kprobe+0x3c0/0x7a0\n    __register_trace_kprobe+0x140/0x1a0\n    __trace_kprobe_create+0x794/0x1040\n    trace_probe_create+0xc4/0xe0\n    create_or_delete_trace_kprobe+0x2c/0x80\n    trace_parse_run_command+0xf0/0x210\n    probes_write+0x20/0x40\n    vfs_write+0xfc/0x450\n    ksys_write+0x84/0x140\n    system_call_exception+0x17c/0x3a0\n    system_call_vectored_common+0xe8/0x278\n  --- interrupt: 3000 at 0x7fffa5682de0\n  NIP:  00007fffa5682de0 LR: 0000000000000000 CTR: 0000000000000000\n  REGS: c000000034847e80 TRAP: 3000   Not tainted  (6.0.0-rc3-00007-gdcf8e5633e2e)\n  MSR:  900000000280f033 &lt;SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE&gt;  CR: 44002408  XER: 00000000\n\nThe address being probed has some special:\n\n  cmdline_proc_show: Probe based on ftrace\n  cmdline_proc_show+16: Probe for the next instruction at the ftrace location\n\nThe ftrace-based kprobe does not generate kprobe::ainsn::insn, it gets\nset to NULL. In arch_prepare_kprobe() it will check for:\n\n  ...\n  prev = get_kprobe(p-&gt;addr - 1);\n  preempt_enable_no_resched();\n  if (prev &amp;&amp; ppc_inst_prefixed(ppc_inst_read(prev-&gt;ainsn.insn))) {\n  ...\n\nIf prev is based on ftrace, &apos;ppc_inst_read(prev-&gt;ainsn.insn)&apos; will occur\nwith a null pointer reference. At this point prev-&gt;addr will not be a\nprefixed instruction, so the check can be skipped.\n\nCheck if prev is ftrace-based kprobe before reading &apos;prev-&gt;ainsn.insn&apos;\nto fix this problem.\n\n[mpe: Trim oops](CVE-2022-50635)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: validate the extent length for uncompressed pclusters\n\nsyzkaller reported a KASAN use-after-free:\nhttps://syzkaller.appspot.com/bug?extid=2ae90e873e97f1faf6f2\n\nThe referenced fuzzed image actually has two issues:\n - m_pa == 0 as a non-inlined pcluster;\n - The logical length is longer than its physical length.\n\nThe first issue has already been addressed.  This patch addresses\nthe second issue by checking the extent length validity.(CVE-2022-50746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc: Fix use-after-free in tcp_write_timer_handler().\n\nWith Eric&apos;s ref tracker, syzbot finally found a repro for\nuse-after-free in tcp_write_timer_handler() by kernel TCP\nsockets. [0]\n\nIf SMC creates a kernel socket in __smc_create(), the kernel\nsocket is supposed to be freed in smc_clcsock_release() by\ncalling sock_release() when we close() the parent SMC socket.\n\nHowever, at the end of smc_clcsock_release(), the kernel\nsocket&apos;s sk_state might not be TCP_CLOSE.  This means that\nwe have not called inet_csk_destroy_sock() in __tcp_close()\nand have not stopped the TCP timers.\n\nThe kernel socket&apos;s TCP timers can be fired later, so we\nneed to hold a refcnt for net as we do for MPTCP subflows\nin mptcp_subflow_create_socket().\n\n[0]:\nleaked reference.\n sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108)\n inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244)\n __sock_create (net/socket.c:1546)\n smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284)\n __sock_create (net/socket.c:1546)\n __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661)\n __x64_sys_socket (net/socket.c:1672)\n do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)\n==================================================================\nBUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)\nRead of size 1 at addr ffff888052b65e0d by task syzrepro/18091\n\nCPU: 0 PID: 18091 Comm: syzrepro Tainted: G        W          6.3.0-rc4-01174-gb5d54eb5899a #7\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014\nCall Trace:\n &lt;IRQ&gt;\n dump_stack_lvl (lib/dump_stack.c:107)\n print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)\n kasan_report (mm/kasan/report.c:538)\n tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)\n tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643)\n call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)\n __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022)\n run_timer_softirq (kernel/time/timer.c:2037)\n __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572)\n __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650)\n irq_exit_rcu (kernel/softirq.c:664)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14))\n &lt;/IRQ&gt;(CVE-2023-53781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6_vti: fix slab-use-after-free in decode_session6\n\nWhen ipv6_vti device is set to the qdisc of the sfb type, the cb field\nof the sent skb may be modified during enqueuing. Then,\nslab-use-after-free may occur when ipv6_vti device sends IPv6 packets.\n\nThe stack information is as follows:\nBUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890\nRead of size 1 at addr ffff88802e08edc2 by task swapper/0/0\nCPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-next-20230707-00001-g84e2cad7f979 #410\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014\nCall Trace:\n&lt;IRQ&gt;\ndump_stack_lvl+0xd9/0x150\nprint_address_description.constprop.0+0x2c/0x3c0\nkasan_report+0x11d/0x130\ndecode_session6+0x103f/0x1890\n__xfrm_decode_session+0x54/0xb0\nvti6_tnl_xmit+0x3e6/0x1ee0\ndev_hard_start_xmit+0x187/0x700\nsch_direct_xmit+0x1a3/0xc30\n__qdisc_run+0x510/0x17a0\n__dev_queue_xmit+0x2215/0x3b10\nneigh_connected_output+0x3c2/0x550\nip6_finish_output2+0x55a/0x1550\nip6_finish_output+0x6b9/0x1270\nip6_output+0x1f1/0x540\nndisc_send_skb+0xa63/0x1890\nndisc_send_rs+0x132/0x6f0\naddrconf_rs_timer+0x3f1/0x870\ncall_timer_fn+0x1a0/0x580\nexpire_timers+0x29b/0x4b0\nrun_timer_softirq+0x326/0x910\n__do_softirq+0x1d4/0x905\nirq_exit_rcu+0xb7/0x120\nsysvec_apic_timer_interrupt+0x97/0xc0\n&lt;/IRQ&gt;\nAllocated by task 9176:\nkasan_save_stack+0x22/0x40\nkasan_set_track+0x25/0x30\n__kasan_slab_alloc+0x7f/0x90\nkmem_cache_alloc_node+0x1cd/0x410\nkmalloc_reserve+0x165/0x270\n__alloc_skb+0x129/0x330\nnetlink_sendmsg+0x9b1/0xe30\nsock_sendmsg+0xde/0x190\n____sys_sendmsg+0x739/0x920\n___sys_sendmsg+0x110/0x1b0\n__sys_sendmsg+0xf7/0x1c0\ndo_syscall_64+0x39/0xb0\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nFreed by task 9176:\nkasan_save_stack+0x22/0x40\nkasan_set_track+0x25/0x30\nkasan_save_free_info+0x2b/0x40\n____kasan_slab_free+0x160/0x1c0\nslab_free_freelist_hook+0x11b/0x220\nkmem_cache_free+0xf0/0x490\nskb_free_head+0x17f/0x1b0\nskb_release_data+0x59c/0x850\nconsume_skb+0xd2/0x170\nnetlink_unicast+0x54f/0x7f0\nnetlink_sendmsg+0x926/0xe30\nsock_sendmsg+0xde/0x190\n____sys_sendmsg+0x739/0x920\n___sys_sendmsg+0x110/0x1b0\n__sys_sendmsg+0xf7/0x1c0\ndo_syscall_64+0x39/0xb0\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nThe buggy address belongs to the object at ffff88802e08ed00\nwhich belongs to the cache skbuff_small_head of size 640\nThe buggy address is located 194 bytes inside of\nfreed 640-byte region [ffff88802e08ed00, ffff88802e08ef80)\n\nAs commit f855691975bb (&quot;xfrm6: Fix the nexthdr offset in\n_decode_session6.&quot;) showed, xfrm_decode_session was originally intended\nonly for the receive path. IP6CB(skb)-&gt;nhoff is not set during\ntransmission. Therefore, set the cb field in the skb to 0 before\nsending packets.(CVE-2023-53821)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to do sanity check on direct node in truncate_dnode()\n\nsyzbot reports below bug:\n\nBUG: KASAN: slab-use-after-free in f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574\nRead of size 4 at addr ffff88802a25c000 by task syz-executor148/5000\n\nCPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023\nCall Trace:\n &lt;TASK&gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106\n print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351\n print_report mm/kasan/report.c:462 [inline]\n kasan_report+0x11c/0x130 mm/kasan/report.c:572\n f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574\n truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944\n f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/node.c:1154\n f2fs_do_truncate_blocks+0x4ac/0xf30 fs/f2fs/file.c:721\n f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749\n f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799\n f2fs_truncate include/linux/fs.h:825 [inline]\n f2fs_setattr+0x1738/0x2090 fs/f2fs/file.c:1006\n notify_change+0xb2c/0x1180 fs/attr.c:483\n do_truncate+0x143/0x200 fs/open.c:66\n handle_truncate fs/namei.c:3295 [inline]\n do_open fs/namei.c:3640 [inline]\n path_openat+0x2083/0x2750 fs/namei.c:3791\n do_filp_open+0x1ba/0x410 fs/namei.c:3818\n do_sys_openat2+0x16d/0x4c0 fs/open.c:1356\n do_sys_open fs/open.c:1372 [inline]\n __do_sys_creat fs/open.c:1448 [inline]\n __se_sys_creat fs/open.c:1442 [inline]\n __x64_sys_creat+0xcd/0x120 fs/open.c:1442\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe root cause is, inodeA references inodeB via inodeB&apos;s ino, once inodeA\nis truncated, it calls truncate_dnode() to truncate data blocks in inodeB&apos;s\nnode page, it traverse mapping data from node-&gt;i.i_addr[0] to\nnode-&gt;i.i_addr[ADDRS_PER_BLOCK() - 1], result in out-of-boundary access.\n\nThis patch fixes to add sanity check on dnode page in truncate_dnode(),\nso that, it can help to avoid triggering such issue, and once it encounters\nsuch issue, it will record newly introduced ERROR_INVALID_NODE_REFERENCE\nerror into superblock, later fsck can detect such issue and try repairing.\n\nAlso, it removes f2fs_truncate_data_blocks() for cleanup due to the\nfunction has only one caller, and uses f2fs_truncate_data_blocks_range()\ninstead.(CVE-2023-53846)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: correct grp validation in ext4_mb_good_group\n\nGroup corruption check will access memory of grp and will trigger kernel\ncrash if grp is NULL. So do NULL check before corruption check.(CVE-2023-53861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: Don&apos;t collect too many protection override GRC elements\n\nIn the protection override dump path, the firmware can return far too\nmany GRC elements, resulting in attempting to write past the end of the\npreviously-kmalloc&apos;ed dump buffer.\n\nThis will result in a kernel panic with reason:\n\n BUG: unable to handle kernel paging request at ADDRESS\n\nwhere &quot;ADDRESS&quot; is just past the end of the protection override dump\nbuffer. The start address of the buffer is:\n p_hwfn-&gt;cdev-&gt;dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf\nand the size of the buffer is buf_size in the same data structure.\n\nThe panic can be arrived at from either the qede Ethernet driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc02662ed [qed]\n qed_dbg_protection_override_dump at ffffffffc0267792 [qed]\n qed_dbg_feature at ffffffffc026aa8f [qed]\n qed_dbg_all_data at ffffffffc026b211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc027298a [qed]\n devlink_health_do_dump at ffffffff82497f61\n devlink_health_report at ffffffff8249cf29\n qed_report_fatal_error at ffffffffc0272baf [qed]\n qede_sp_task at ffffffffc045ed32 [qede]\n process_one_work at ffffffff81d19783\n\nor the qedf storage driver path:\n\n    [exception RIP: qed_grc_dump_addr_range+0x108]\n qed_protection_override_dump at ffffffffc068b2ed [qed]\n qed_dbg_protection_override_dump at ffffffffc068c792 [qed]\n qed_dbg_feature at ffffffffc068fa8f [qed]\n qed_dbg_all_data at ffffffffc0690211 [qed]\n qed_fw_fatal_reporter_dump at ffffffffc069798a [qed]\n devlink_health_do_dump at ffffffff8aa95e51\n devlink_health_report at ffffffff8aa9ae19\n qed_report_fatal_error at ffffffffc0697baf [qed]\n qed_hw_err_notify at ffffffffc06d32d7 [qed]\n qed_spq_post at ffffffffc06b1011 [qed]\n qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed]\n qedf_cleanup_fcport at ffffffffc05e7597 [qedf]\n qedf_rport_event_handler at ffffffffc05e7bf7 [qedf]\n fc_rport_work at ffffffffc02da715 [libfc]\n process_one_work at ffffffff8a319663\n\nResolve this by clamping the firmware&apos;s return value to the maximum\nnumber of legal elements the firmware should return.(CVE-2025-39949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix validation of VF state in get resources\n\nVF state I40E_VF_STATE_ACTIVE is not the only state in which\nVF is actually active so it should not be used to determine\nif a VF is allowed to obtain resources.\n\nUse I40E_VF_STATE_RESOURCES_LOADED that is set only in\ni40e_vc_get_vf_resources_msg() and cleared during reset.(CVE-2025-39969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix input validation logic for action_meta\n\nFix condition to check &apos;greater or equal&apos; to prevent OOB dereference.(CVE-2025-39970)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSquashfs: reject negative file sizes in squashfs_read_inode()\n\nSyskaller reports a &quot;WARNING in ovl_copy_up_file&quot; in overlayfs.\n\nThis warning is ultimately caused because the underlying Squashfs file\nsystem returns a file with a negative file size.\n\nThis commit checks for a negative file size and returns EINVAL.\n\n[(CVE-2025-40200)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Ensure XFD state on signal delivery\n\nSean reported [1] the following splat when running KVM tests:\n\n   WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70\n   Call Trace:\n    &lt;TASK&gt;\n    fpu__clear_user_states+0x9c/0x100\n    arch_do_signal_or_restart+0x142/0x210\n    exit_to_user_mode_loop+0x55/0x100\n    do_syscall_64+0x205/0x2c0\n    entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nChao further identified [2] a reproducible scenario involving signal\ndelivery: a non-AMX task is preempted by an AMX-enabled task which\nmodifies the XFD MSR.\n\nWhen the non-AMX task resumes and reloads XSTATE with init values,\na warning is triggered due to a mismatch between fpstate::xfd and the\nCPU&apos;s current XFD state. fpu__clear_user_states() does not currently\nre-synchronize the XFD state after such preemption.\n\nInvoke xfd_update_state() which detects and corrects the mismatch if\nthere is a dynamic feature.\n\nThis also benefits the sigreturn path, as fpu__restore_sig() may call\nfpu__clear_user_states() when the sigframe is inaccessible.\n\n[ dhansen: minor changelog munging ](CVE-2025-68171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()\n\nIn hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked when\nsetup_instance() fails with an error code. Fix that by freeing the urb\nbefore freeing the hw structure. Also change the error paths to use the\ngoto ladder style.\n\nCompile tested only. Issue found using a prototype static analysis tool.(CVE-2025-68734)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Clear cmds after chip reset\n\nCommit aefed3e5548f (&quot;scsi: qla2xxx: target: Fix offline port handling\nand host reset handling&quot;) caused two problems:\n\n1. Commands sent to FW, after chip reset got stuck and never freed as FW\n   is not going to respond to them anymore.\n\n2. BUG_ON(cmd-&gt;sg_mapped) in qlt_free_cmd().  Commit 26f9ce53817a\n   (&quot;scsi: qla2xxx: Fix missed DMA unmap for aborted commands&quot;)\n   attempted to fix this, but introduced another bug under different\n   circumstances when two different CPUs were racing to call\n   qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in\n   dma_unmap_sg_attrs().\n\nSo revert &quot;scsi: qla2xxx: Fix missed DMA unmap for aborted commands&quot; and\npartially revert &quot;scsi: qla2xxx: target: Fix offline port handling and\nhost reset handling&quot; at __qla2x00_abort_all_cmds.(CVE-2025-68745)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP3","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-298.0.0.200.oe2203sp3"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","kernel-debuginfo-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","kernel-debugsource-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","kernel-devel-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","kernel-headers-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","kernel-source-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","kernel-tools-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","kernel-tools-debuginfo-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","kernel-tools-devel-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","perf-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","perf-debuginfo-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","python3-perf-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm","python3-perf-debuginfo-5.10.0-298.0.0.200.oe2203sp3.aarch64.rpm"],"src":["kernel-5.10.0-298.0.0.200.oe2203sp3.src.rpm"],"x86_64":["kernel-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","kernel-debuginfo-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","kernel-debugsource-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","kernel-devel-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","kernel-headers-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","kernel-source-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","kernel-tools-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","kernel-tools-debuginfo-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","kernel-tools-devel-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","perf-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","perf-debuginfo-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","python3-perf-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm","python3-perf-debuginfo-5.10.0-298.0.0.200.oe2203sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1075"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50635"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-50746"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53781"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53821"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53846"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53861"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39949"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39969"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39970"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40200"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68171"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68734"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68745"}],"database_specific":{"severity":"High"}}
