{"schema_version":"1.7.2","id":"OESA-2025-1410","modified":"2025-04-11T13:44:32Z","published":"2025-04-11T13:44:32Z","upstream":["CVE-2021-47660","CVE-2022-49443","CVE-2022-49513","CVE-2022-49553","CVE-2023-53001","CVE-2024-56642","CVE-2024-56664","CVE-2024-57951","CVE-2024-58055","CVE-2025-21715","CVE-2025-21718","CVE-2025-21722","CVE-2025-21726","CVE-2025-21727","CVE-2025-21785","CVE-2025-21791","CVE-2025-21804","CVE-2025-21816","CVE-2025-21823","CVE-2025-21863","CVE-2025-21881","CVE-2025-21887","CVE-2025-21943"],"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\nfs/ntfs3: Fix some memory leaks in an error handling path of \u0026apos;log_replay()\u0026apos;\n\nAll error handling paths lead to \u0026apos;out\u0026apos; where many resources are freed.\n\nDo it as well here instead of a direct return, otherwise \u0026apos;log\u0026apos;, \u0026apos;ra\u0026apos; and\n\u0026apos;log-\u0026gt;one_page_buf\u0026apos; (at least) will leak.(CVE-2021-47660)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlist: fix a data-race around ep-\u0026gt;rdllist\n\nep_poll() first calls ep_events_available() with no lock held and checks\nif ep-\u0026gt;rdllist is empty by list_empty_careful(), which reads\nrdllist-\u0026gt;prev.  Thus all accesses to it need some protection to avoid\nstore/load-tearing.\n\nNote INIT_LIST_HEAD_RCU() already has the annotation for both prev\nand next.\n\nCommit bf3b9f6372c4 (\u0026quot;epoll: Add busy poll support to epoll with socket\nfds.\u0026quot;) added the first lockless ep_events_available(), and commit\nc5a282e9635e (\u0026quot;fs/epoll: reduce the scope of wq lock in epoll_wait()\u0026quot;)\nmade some ep_events_available() calls lockless and added single call under\na lock, finally commit e59d3c64cba6 (\u0026quot;epoll: eliminate unnecessary lock\nfor zero timeout\u0026quot;) made the last ep_events_available() lockless.\n\nBUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait\n\nwrite to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:\n INIT_LIST_HEAD include/linux/list.h:38 [inline]\n list_splice_init include/linux/list.h:492 [inline]\n ep_start_scan fs/eventpoll.c:622 [inline]\n ep_send_events fs/eventpoll.c:1656 [inline]\n ep_poll fs/eventpoll.c:1806 [inline]\n do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nread to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1:\n list_empty_careful include/linux/list.h:329 [inline]\n ep_events_available fs/eventpoll.c:381 [inline]\n ep_poll fs/eventpoll.c:1797 [inline]\n do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234\n do_epoll_pwait fs/eventpoll.c:2268 [inline]\n __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]\n __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275\n __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nvalue changed: 0xffff88810480c7d0 -\u0026gt; 0xffff888103c15098\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G        W         5.17.0-rc7-syzkaller-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-49443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: governor: Use kobject release() method to free dbs_data\n\nThe struct dbs_data embeds a struct gov_attr_set and\nthe struct gov_attr_set embeds a kobject. Since every kobject must have\na release() method and we can\u0026apos;t use kfree() to free it directly,\nso introduce cpufreq_dbs_data_release() to release the dbs_data via\nthe kobject::release() method. This fixes the calltrace like below:\n\n  ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34\n  WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\n  Modules linked in:\n  CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536\n  Hardware name: Marvell OcteonTX CN96XX board (DT)\n  pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : debug_print_object+0xb8/0x100\n  lr : debug_print_object+0xb8/0x100\n  sp : ffff80001dfcf9a0\n  x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000\n  x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210\n  x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118\n  x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000\n  x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8\n  x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14\n  x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0\n  x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001\n  x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000\n  x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040\n  Call trace:\n   debug_print_object+0xb8/0x100\n   __debug_check_no_obj_freed+0x1d0/0x25c\n   debug_check_no_obj_freed+0x24/0xa0\n   kfree+0x11c/0x440\n   cpufreq_dbs_governor_exit+0xa8/0xac\n   cpufreq_exit_governor+0x44/0x90\n   cpufreq_set_policy+0x29c/0x570\n   store_scaling_governor+0x110/0x154\n   store+0xb0/0xe0\n   sysfs_kf_write+0x58/0x84\n   kernfs_fop_write_iter+0x12c/0x1c0\n   new_sync_write+0xf0/0x18c\n   vfs_write+0x1cc/0x220\n   ksys_write+0x74/0x100\n   __arm64_sys_write+0x28/0x3c\n   invoke_syscall.constprop.0+0x58/0xf0\n   do_el0_svc+0x70/0x170\n   el0_svc+0x54/0x190\n   el0t_64_sync_handler+0xa4/0x130\n   el0t_64_sync+0x1a0/0x1a4\n  irq event stamp: 189006\n  hardirqs last  enabled at (189005): [\u0026lt;ffff8000080849d0\u0026gt;] finish_task_switch.isra.0+0xe0/0x2c0\n  hardirqs last disabled at (189006): [\u0026lt;ffff8000090667a4\u0026gt;] el1_dbg+0x24/0xa0\n  softirqs last  enabled at (188966): [\u0026lt;ffff8000080106d0\u0026gt;] __do_softirq+0x4b0/0x6a0\n  softirqs last disabled at (188957): [\u0026lt;ffff80000804a618\u0026gt;] __irq_exit_rcu+0x108/0x1a4\n\n[ rjw: Because can be freed by the gov_attr_set_put() in\n  cpufreq_dbs_governor_exit() now, it is also necessary to put the\n  invocation of the governor -\u0026gt;exit() callback into the new\n  cpufreq_dbs_data_release() function. ](CVE-2022-49513)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: validate BOOT sectors_per_clusters\n\nWhen the NTFS BOOT sectors_per_clusters field is \u0026gt; 0x80, it represents a\nshift value.  Make sure that the shift value is not too large before using\nit (NTFS max cluster size is 2MB).  Return -EVINVAL if it too large.\n\nThis prevents negative shift values and shift values that are larger than\nthe field size.\n\nPrevents this UBSAN error:\n\n UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16\n shift exponent -192 is negative(CVE-2022-49553)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drm_vma_manager: Add drm_vma_node_allow_once()\n\nCurrently there is no easy way for a drm driver to safely check and allow\ndrm_vma_offset_node for a drm file just once. Allow drm drivers to call\nnon-refcounted version of drm_vma_node_allow() so that a driver doesn\u0026apos;t\nneed to keep track of each drm_vma_node_allow() to call subsequent\ndrm_vma_node_revoke() to prevent memory leak.(CVE-2023-53001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free of kernel socket in cleanup_bearer().\n\nsyzkaller reported a use-after-free of UDP kernel socket\nin cleanup_bearer() without repro. [0][1]\n\nWhen bearer_disable() calls tipc_udp_disable(), cleanup\nof the UDP kernel socket is deferred by work calling\ncleanup_bearer().\n\ntipc_exit_net() waits for such works to finish by checking\ntipc_net(net)-\u0026gt;wq_count.  However, the work decrements the\ncount too early before releasing the kernel socket,\nunblocking cleanup_net() and resulting in use-after-free.\n\nLet\u0026apos;s move the decrement after releasing the socket in\ncleanup_bearer().\n\n[0]:\nref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at\n     sk_alloc+0x438/0x608\n     inet_create+0x4c8/0xcb0\n     __sock_create+0x350/0x6b8\n     sock_create_kern+0x58/0x78\n     udp_sock_create4+0x68/0x398\n     udp_sock_create+0x88/0xc8\n     tipc_udp_enable+0x5e8/0x848\n     __tipc_nl_bearer_enable+0x84c/0xed8\n     tipc_nl_bearer_enable+0x38/0x60\n     genl_family_rcv_msg_doit+0x170/0x248\n     genl_rcv_msg+0x400/0x5b0\n     netlink_rcv_skb+0x1dc/0x398\n     genl_rcv+0x44/0x68\n     netlink_unicast+0x678/0x8b0\n     netlink_sendmsg+0x5e4/0x898\n     ____sys_sendmsg+0x500/0x830\n\n[1]:\nBUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]\nBUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n udp_hashslot include/net/udp.h:85 [inline]\n udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979\n sk_common_release+0xaf/0x3f0 net/core/sock.c:3820\n inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437\n inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489\n __sock_release net/socket.c:658 [inline]\n sock_release+0xa0/0x210 net/socket.c:686\n cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nUninit was created at:\n slab_free_hook mm/slub.c:2269 [inline]\n slab_free mm/slub.c:4580 [inline]\n kmem_cache_free+0x207/0xc40 mm/slub.c:4682\n net_free net/core/net_namespace.c:454 [inline]\n cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310\n worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391\n kthread+0x531/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244\n\nCPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: events cleanup_bearer(CVE-2024-56642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix race between element replace and close()\n\nElement replace (with a socket different from the one stored) may race\nwith socket\u0026apos;s close() link popping \u0026amp; unlinking. __sock_map_delete()\nunconditionally unrefs the (wrong) element:\n\n// set map[0] = s0\nmap_update_elem(map, 0, s0)\n\n// drop fd of s0\nclose(s0)\n  sock_map_close()\n    lock_sock(sk)               (s0!)\n    sock_map_remove_links(sk)\n      link = sk_psock_link_pop()\n      sock_map_unlink(sk, link)\n        sock_map_delete_from_link\n                                        // replace map[0] with s1\n                                        map_update_elem(map, 0, s1)\n                                          sock_map_update_elem\n                                (s1!)       lock_sock(sk)\n                                            sock_map_update_common\n                                              psock = sk_psock(sk)\n                                              spin_lock(\u0026amp;stab-\u0026gt;lock)\n                                              osk = stab-\u0026gt;sks[idx]\n                                              sock_map_add_link(..., \u0026amp;stab-\u0026gt;sks[idx])\n                                              sock_map_unref(osk, \u0026amp;stab-\u0026gt;sks[idx])\n                                                psock = sk_psock(osk)\n                                                sk_psock_put(sk, psock)\n                                                  if (refcount_dec_and_test(\u0026amp;psock))\n                                                    sk_psock_drop(sk, psock)\n                                              spin_unlock(\u0026amp;stab-\u0026gt;lock)\n                                            unlock_sock(sk)\n          __sock_map_delete\n            spin_lock(\u0026amp;stab-\u0026gt;lock)\n            sk = *psk                        // s1 replaced s0; sk == s1\n            if (!sk_test || sk_test == sk)   // sk_test (s0) != sk (s1); no branch\n              sk = xchg(psk, NULL)\n            if (sk)\n              sock_map_unref(sk, psk)        // unref s1; sks[idx] will dangle\n                psock = sk_psock(sk)\n                sk_psock_put(sk, psock)\n                  if (refcount_dec_and_test())\n                    sk_psock_drop(sk, psock)\n            spin_unlock(\u0026amp;stab-\u0026gt;lock)\n    release_sock(sk)\n\nThen close(map) enqueues bpf_map_free_deferred, which finally calls\nsock_map_free(). This results in some refcount_t warnings along with\na KASAN splat [1].\n\nFix __sock_map_delete(), do not allow sock_map_unref() on elements that\nmay have been replaced.\n\n[1]:\nBUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330\nWrite of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063\n\nCPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\nWorkqueue: events_unbound bpf_map_free_deferred\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x68/0x90\n print_report+0x174/0x4f6\n kasan_report+0xb9/0x190\n kasan_check_range+0x10f/0x1e0\n sock_map_free+0x10e/0x330\n bpf_map_free_deferred+0x173/0x320\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 1202:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n __kasan_slab_alloc+0x85/0x90\n kmem_cache_alloc_noprof+0x131/0x450\n sk_prot_alloc+0x5b/0x220\n sk_alloc+0x2c/0x870\n unix_create1+0x88/0x8a0\n unix_create+0xc5/0x180\n __sock_create+0x241/0x650\n __sys_socketpair+0x1ce/0x420\n __x64_sys_socketpair+0x92/0x100\n do_syscall_64+0x93/0x180\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 46:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x37/0x60\n __kasan_slab_free+0x4b/0x70\n kmem_cache_free+0x1a1/0x590\n __sk_destruct+0x388/0x5a0\n sk_psock_destroy+0x73e/0xa50\n process_one_work+0x846/0x1420\n worker_thread+0x5b3/0xf80\n kthread+0x29e/0x360\n ret_from_fork+0x2d/0x70\n ret_from_fork_asm+0x1a/0x30\n\nThe bu\n---truncated---(CVE-2024-56664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhrtimers: Handle CPU state correctly on hotplug\n\nConsider a scenario where a CPU transitions from CPUHP_ONLINE to halfway\nthrough a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to\nCPUHP_ONLINE:\n\nSince hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set\nto 1 throughout. However, during a CPU unplug operation, the tick and the\nclockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online\nstate, for instance CFS incorrectly assumes that the hrtick is already\nactive, and the chance of the clockevent device to transition to oneshot\nmode is also lost forever for the CPU, unless it goes back to a lower state\nthan CPUHP_HRTIMERS_PREPARE once.\n\nThis round-trip reveals another issue; cpu_base.online is not set to 1\nafter the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().\n\nAside of that, the bulk of the per CPU state is not reset either, which\nmeans there are dangling pointers in the worst case.\n\nAddress this by adding a corresponding startup() callback, which resets the\nstale per CPU state and sets the online flag.\n\n[ tglx: Make the new callback unconditionally available, remove the online\n  \tmodification in the prepare() callback and clear the remaining\n  \tstate in the starting callback instead of the prepare callback ](CVE-2024-57951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_tcm: Don\u0026apos;t free command immediately\n\nDon\u0026apos;t prematurely free the command. Wait for the status completion of\nthe sense status. It can be freed then. Otherwise we will double-free\nthe command.(CVE-2024-58055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: davicom: fix UAF in dm9000_drv_remove\n\ndm is netdev private data and it cannot be\nused after free_netdev() call. Using dm after free_netdev()\ncan cause UAF bug. Fix it by moving free_netdev() at the end of the\nfunction.\n\nThis is similar to the issue fixed in commit\nad297cd2db89 (\u0026quot;net: qcom/emac: fix UAF in emac_remove\u0026quot;).\n\nThis bug is detected by our static analysis tool.(CVE-2025-21715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: rose: fix timer races against user threads\n\nRose timers only acquire the socket spinlock, without\nchecking if the socket is owned by one user thread.\n\nAdd a check and rearm the timers if needed.\n\nBUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\nRead of size 2 at addr ffff88802f09b82a by task swapper/0/0\n\nCPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n  __dump_stack lib/dump_stack.c:94 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n  print_address_description mm/kasan/report.c:378 [inline]\n  print_report+0x169/0x550 mm/kasan/report.c:489\n  kasan_report+0x143/0x180 mm/kasan/report.c:602\n  rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\n  call_timer_fn+0x187/0x650 kernel/time/timer.c:1793\n  expire_timers kernel/time/timer.c:1844 [inline]\n  __run_timers kernel/time/timer.c:2418 [inline]\n  __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430\n  run_timer_base kernel/time/timer.c:2439 [inline]\n  run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449\n  handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561\n  __do_softirq kernel/softirq.c:595 [inline]\n  invoke_softirq kernel/softirq.c:435 [inline]\n  __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662\n  irq_exit_rcu+0x9/0x30 kernel/softirq.c:678\n  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]\n  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049\n \u0026lt;/IRQ\u0026gt;(CVE-2025-21718)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: do not force clear folio if buffer is referenced\n\nPatch series \u0026quot;nilfs2: protect busy buffer heads from being force-cleared\u0026quot;.\n\nThis series fixes the buffer head state inconsistency issues reported by\nsyzbot that occurs when the filesystem is corrupted and falls back to\nread-only, and the associated buffer head use-after-free issue.\n\n\nThis patch (of 2):\n\nSyzbot has reported that after nilfs2 detects filesystem corruption and\nfalls back to read-only, inconsistencies in the buffer state may occur.\n\nOne of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()\nto set a data or metadata buffer as dirty, but it detects that the buffer\nis not in the uptodate state:\n\n WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520\n  fs/buffer.c:1177\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598\n  nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73\n  nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344\n  nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218\n  vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n  do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n  __do_sys_mkdirat fs/namei.c:4295 [inline]\n  __se_sys_mkdirat fs/namei.c:4293 [inline]\n  __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\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\n\nThe other is when nilfs_btree_propagate(), which propagates the dirty\nstate to the ancestor nodes of a b-tree that point to a dirty buffer,\ndetects that the origin buffer is not dirty, even though it should be:\n\n WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089\n  nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345\n  nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587\n  nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006\n  nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045\n  nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline]\n  nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline]\n  nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115\n  nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479\n  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline]\n  nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701\n  kthread+0x2f0/0x390 kernel/kthread.c:389\n  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n  \u0026lt;/TASK\u0026gt;\n\nBoth of these issues are caused by the callbacks that handle the\npage/folio write requests, forcibly clear various states, including the\nworking state of the buffers they hold, at unexpected times when they\ndetect read-only fallback.\n\nFix these issues by checking if the buffer is referenced before clearing\nthe page/folio state, and skipping the clear if it is.(CVE-2025-21722)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: avoid UAF for reorder_work\n\nAlthough the previous patch can avoid ps and ps UAF for _do_serial, it\ncan not avoid potential UAF issue for reorder_work. This issue can\nhappen just as below:\n\ncrypto_request\t\t\tcrypto_request\t\tcrypto_del_alg\npadata_do_serial\n  ...\n  padata_reorder\n    // processes all remaining\n    // requests then breaks\n    while (1) {\n      if (!padata)\n        break;\n      ...\n    }\n\n\t\t\t\tpadata_do_serial\n\t\t\t\t  // new request added\n\t\t\t\t  list_add\n    // sees the new request\n    queue_work(reorder_work)\n\t\t\t\t  padata_reorder\n\t\t\t\t    queue_work_on(squeue-\u0026gt;work)\n...\n\n\t\t\t\t\u0026lt;kworker context\u0026gt;\n\t\t\t\tpadata_serial_worker\n\t\t\t\t// completes new request,\n\t\t\t\t// no more outstanding\n\t\t\t\t// requests\n\n\t\t\t\t\t\t\tcrypto_del_alg\n\t\t\t\t\t\t\t  // free pd\n\n\u0026lt;kworker context\u0026gt;\ninvoke_padata_reorder\n  // UAF of pd\n\nTo avoid UAF for \u0026apos;reorder_work\u0026apos;, get \u0026apos;pd\u0026apos; ref before put \u0026apos;reorder_work\u0026apos;\ninto the \u0026apos;serial_wq\u0026apos; and put \u0026apos;pd\u0026apos; ref until the \u0026apos;serial_wq\u0026apos; finish.(CVE-2025-21726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf \u0026apos;mdelay(10)\u0026apos; is added before calling \u0026apos;padata_find_next\u0026apos; in the\n\u0026apos;padata_reorder\u0026apos; function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(\u0026amp;pd-\u0026gt;refcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps-\u0026gt;pd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in \u0026apos;while\u0026apos;, if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n\u0026apos;padata_find_next\u0026apos;, which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in \u0026apos;padata_free_shell\u0026apos; wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array\n\nThe loop that detects/populates cache information already has a bounds\ncheck on the array size but does not account for cache levels with\nseparate data/instructions cache. Fix this by incrementing the index\nfor any populated leaf (instead of any populated level).(CVE-2025-21785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvrf: use RCU protection in l3mdev_l3_out()\n\nl3mdev_l3_out() can be called without RCU being held:\n\nraw_sendmsg()\n ip_push_pending_frames()\n  ip_send_skb()\n   ip_local_out()\n    __ip_local_out()\n     l3mdev_ip_out()\n\nAdd rcu_read_lock() / rcu_read_unlock() pair to avoid\na potential UAF.(CVE-2025-21791)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()\n\nThe rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()\nmacro to request a needed resource. A string variable that lives on the\nstack is then used to store a dynamically computed resource name, which\nis then passed on as one of the macro arguments. This can lead to\nundefined behavior.\n\nDepending on the current contents of the memory, the manifestations of\nerrors may vary. One possible output may be as follows:\n\n  $ cat /proc/iomem\n  30000000-37ffffff :\n  38000000-3fffffff :\n\nSometimes, garbage may appear after the colon.\n\nIn very rare cases, if no NULL-terminator is found in memory, the system\nmight crash because the string iterator will overrun which can lead to\naccess of unmapped memory above the stack.\n\nThus, fix this by replacing outbound_name with the name of the previously\nrequested resource. With the changes applied, the output will be as\nfollows:\n\n  $ cat /proc/iomem\n  30000000-37ffffff : memory2\n  38000000-3fffffff : memory3\n\n[kwilczynski: commit log](CVE-2025-21804)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING\n\nhrtimers are migrated away from the dying CPU to any online target at\nthe CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers\nhandling tasks involved in the CPU hotplug forward progress.\n\nHowever wakeups can still be performed by the outgoing CPU after\nCPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being\narmed. Depending on several considerations (crystal ball power management\nbased election, earliest timer already enqueued, timer migration enabled or\nnot), the target may eventually be the current CPU even if offline. If that\nhappens, the timer is eventually ignored.\n\nThe most notable example is RCU which had to deal with each and every of\nthose wake-ups by deferring them to an online CPU, along with related\nworkarounds:\n\n_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)\n_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)\n_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)\n\nThe problem isn\u0026apos;t confined to RCU though as the stop machine kthread\n(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end\nof its work through cpu_stop_signal_done() and performs a wake up that\neventually arms the deadline server timer:\n\n   WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0\n   CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted\n   Stopper: multi_cpu_stop+0x0/0x120 \u0026lt;- stop_machine_cpuslocked+0x66/0xc0\n   RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0\n   Call Trace:\n   \u0026lt;TASK\u0026gt;\n     start_dl_timer\n     enqueue_dl_entity\n     dl_server_start\n     enqueue_task_fair\n     enqueue_task\n     ttwu_do_activate\n     try_to_wake_up\n     complete\n     cpu_stopper_thread\n\nInstead of providing yet another bandaid to work around the situation, fix\nit in the hrtimers infrastructure instead: always migrate away a timer to\nan online target whenever it is enqueued from an offline CPU.\n\nThis will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: Drop unmanaged ELP metric worker\n\nThe ELP worker needs to calculate new metric values for all neighbors\n\u0026quot;reachable\u0026quot; over an interface. Some of the used metric sources require\nlocks which might need to sleep. This sleep is incompatible with the RCU\nlist iterator used for the recorded neighbors. The initial approach to work\naround of this problem was to queue another work item per neighbor and then\nrun this in a new context.\n\nEven when this solved the RCU vs might_sleep() conflict, it has a major\nproblems: Nothing was stopping the work item in case it is not needed\nanymore - for example because one of the related interfaces was removed or\nthe batman-adv module was unloaded - resulting in potential invalid memory\naccesses.\n\nDirectly canceling the metric worker also has various problems:\n\n* cancel_work_sync for a to-be-deactivated interface is called with\n  rtnl_lock held. But the code in the ELP metric worker also tries to use\n  rtnl_lock() - which will never return in this case. This also means that\n  cancel_work_sync would never return because it is waiting for the worker\n  to finish.\n* iterating over the neighbor list for the to-be-deactivated interface is\n  currently done using the RCU specific methods. Which means that it is\n  possible to miss items when iterating over it without the associated\n  spinlock - a behaviour which is acceptable for a periodic metric check\n  but not for a cleanup routine (which must \u0026quot;stop\u0026quot; all still running\n  workers)\n\nThe better approch is to get rid of the per interface neighbor metric\nworker and handle everything in the interface worker. The original problems\nare solved by:\n\n* creating a list of neighbors which require new metric information inside\n  the RCU protected context, gathering the metric according to the new list\n  outside the RCU protected context\n* only use rcu_trylock inside metric gathering code to avoid a deadlock\n  when the cancel_delayed_work_sync is called in the interface removal code\n  (which is called with the rtnl_lock held)(CVE-2025-21823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: prevent opcode speculation\n\nsqe-\u0026gt;opcode is used for different tables, make sure we santitise it\nagainst speculations.(CVE-2025-21863)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuprobes: Reject the shared zeropage in uprobe_write_opcode()\n\nWe triggered the following crash in syzkaller tests:\n\n  BUG: Bad page state in process syz.7.38  pfn:1eff3\n  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3\n  flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)\n  raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000\n  raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000\n  page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x32/0x50\n   bad_page+0x69/0xf0\n   free_unref_page_prepare+0x401/0x500\n   free_unref_page+0x6d/0x1b0\n   uprobe_write_opcode+0x460/0x8e0\n   install_breakpoint.part.0+0x51/0x80\n   register_for_each_vma+0x1d9/0x2b0\n   __uprobe_register+0x245/0x300\n   bpf_uprobe_multi_link_attach+0x29b/0x4f0\n   link_create+0x1e2/0x280\n   __sys_bpf+0x75f/0xac0\n   __x64_sys_bpf+0x1a/0x30\n   do_syscall_64+0x56/0x100\n   entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\n   BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1\n\nThe following syzkaller test case can be used to reproduce:\n\n  r2 = creat(\u0026amp;(0x7f0000000000)=\u0026apos;./file0\\x00\u0026apos;, 0x8)\n  write$nbd(r2, \u0026amp;(0x7f0000000580)=ANY=[], 0x10)\n  r4 = openat(0xffffffffffffff9c, \u0026amp;(0x7f0000000040)=\u0026apos;./file0\\x00\u0026apos;, 0x42, 0x0)\n  mmap$IORING_OFF_SQ_RING(\u0026amp;(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)\n  r5 = userfaultfd(0x80801)\n  ioctl$UFFDIO_API(r5, 0xc018aa3f, \u0026amp;(0x7f0000000040)={0xaa, 0x20})\n  r6 = userfaultfd(0x80801)\n  ioctl$UFFDIO_API(r6, 0xc018aa3f, \u0026amp;(0x7f0000000140))\n  ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, \u0026amp;(0x7f0000000100)={{\u0026amp;(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})\n  ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, \u0026amp;(0x7f0000000000)={{\u0026amp;(0x7f0000ffd000/0x1000)=nil, 0x1000}})\n  r7 = bpf$PROG_LOAD(0x5, \u0026amp;(0x7f0000000140)={0x2, 0x3, \u0026amp;(0x7f0000000200)=ANY=[@ANYBLOB=\u0026quot;1800000000120000000000000000000095\u0026quot;], \u0026amp;(0x7f0000000000)=\u0026apos;GPL\\x00\u0026apos;, 0x7, 0x0, 0x0, 0x0, 0x0, \u0026apos;\\x00\u0026apos;, 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)\n  bpf$BPF_LINK_CREATE_XDP(0x1c, \u0026amp;(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={\u0026amp;(0x7f0000000080)=\u0026apos;./file0\\x00\u0026apos;, \u0026amp;(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)\n\nThe cause is that zero pfn is set to the PTE without increasing the RSS\ncount in mfill_atomic_pte_zeropage() and the refcount of zero folio does\nnot increase accordingly. Then, the operation on the same pfn is performed\nin uprobe_write_opcode()-\u0026gt;__replace_page() to unconditional decrease the\nRSS count and old_folio\u0026apos;s refcount.\n\nTherefore, two bugs are introduced:\n\n 1. The RSS count is incorrect, when process exit, the check_mm() report\n    error \u0026quot;Bad rss-count\u0026quot;.\n\n 2. The reserved folio (zero folio) is freed when folio-\u0026gt;refcount is zero,\n    then free_pages_prepare-\u0026gt;free_page_is_bad() report error\n    \u0026quot;Bad page state\u0026quot;.\n\nThere is more, the following warning could also theoretically be triggered:\n\n  __replace_page()\n    -\u0026gt; ...\n      -\u0026gt; folio_remove_rmap_pte()\n        -\u0026gt; VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)\n\nConsidering that uprobe hit on the zero folio is a very rare case, just\nreject zero old folio immediately after get_user_page_vma_remote().\n\n[ mingo: Cleaned up the changelog ](CVE-2025-21881)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\novl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up\n\nThe issue was caused by dput(upper) being called before\novl_dentry_update_reval(), while upper-\u0026gt;d_flags was still\naccessed in ovl_dentry_remote().\n\nMove dput(upper) after its last use to prevent use-after-free.\n\nBUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\nBUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0xc3/0x620 mm/kasan/report.c:488\n kasan_report+0xd9/0x110 mm/kasan/report.c:601\n ovl_dentry_remote fs/overlayfs/util.c:162 [inline]\n ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167\n ovl_link_up fs/overlayfs/copy_up.c:610 [inline]\n ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170\n ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223\n ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136\n vfs_rename+0xf84/0x20a0 fs/namei.c:4893\n...\n \u0026lt;/TASK\u0026gt;(CVE-2025-21887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpio: aggregator: protect driver attr handlers against module unload\n\nBoth new_device_store and delete_device_store touch module global\nresources (e.g. gpio_aggregator_lock). To prevent race conditions with\nmodule unload, a reference needs to be held.\n\nAdd try_module_get() in these handlers.\n\nFor new_device_store, this eliminates what appears to be the most dangerous\nscenario: if an id is allocated from gpio_aggregator_idr but\nplatform_device_register has not yet been called or completed, a concurrent\nmodule unload could fail to unregister/delete the device, leaving behind a\ndangling platform device/GPIO forwarder. This can result in various issues.\nThe following simple reproducer demonstrates these problems:\n\n  #!/bin/bash\n  while :; do\n    # note: whether \u0026apos;gpiochip0 0\u0026apos; exists or not does not matter.\n    echo \u0026apos;gpiochip0 0\u0026apos; \u0026gt; /sys/bus/platform/drivers/gpio-aggregator/new_device\n  done \u0026amp;\n  while :; do\n    modprobe gpio-aggregator\n    modprobe -r gpio-aggregator\n  done \u0026amp;\n  wait\n\n  Starting with the following warning, several kinds of warnings will appear\n  and the system may become unstable:\n\n  ------------[ cut here ]------------\n  list_del corruption, ffff888103e2e980-\u0026gt;next is LIST_POISON1 (dead000000000100)\n  WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120\n  [...]\n  RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120\n  [...]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __list_del_entry_valid_or_report+0xa3/0x120\n   ? __warn.cold+0x93/0xf2\n   ? __list_del_entry_valid_or_report+0xa3/0x120\n   ? report_bug+0xe6/0x170\n   ? __irq_work_queue_local+0x39/0xe0\n   ? handle_bug+0x58/0x90\n   ? exc_invalid_op+0x13/0x60\n   ? asm_exc_invalid_op+0x16/0x20\n   ? __list_del_entry_valid_or_report+0xa3/0x120\n   gpiod_remove_lookup_table+0x22/0x60\n   new_device_store+0x315/0x350 [gpio_aggregator]\n   kernfs_fop_write_iter+0x137/0x1f0\n   vfs_write+0x262/0x430\n   ksys_write+0x60/0xd0\n   do_syscall_64+0x6c/0x180\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   [...]\n   \u0026lt;/TASK\u0026gt;\n  ---[ end trace 0000000000000000 ]---(CVE-2025-21943)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-259.0.0.162.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","kernel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","perf-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-259.0.0.162.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","kernel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","perf-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1410"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47660"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49443"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49513"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49553"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53001"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56642"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56664"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57951"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58055"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21715"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21718"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21722"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21726"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21727"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21785"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21791"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21804"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21816"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21823"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21863"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21881"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21887"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21943"}],"database_specific":{"severity":"High"}}