{"schema_version":"1.7.2","id":"OESA-2025-1204","modified":"2025-02-28T15:33:31Z","published":"2025-02-28T15:33:31Z","upstream":["CVE-2024-47794","CVE-2024-53079","CVE-2024-53164","CVE-2024-53240","CVE-2024-54680","CVE-2024-56372","CVE-2024-56607","CVE-2024-56655","CVE-2024-56658","CVE-2024-56659","CVE-2024-56717","CVE-2024-56767","CVE-2024-57792","CVE-2024-57804","CVE-2024-57807","CVE-2024-57930","CVE-2024-57946","CVE-2025-21631","CVE-2025-21656","CVE-2025-21689","CVE-2025-21699","CVE-2025-21704"],"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\nbpf: Prevent tailcall infinite loop caused by freplace\n\nThere is a potential infinite loop issue that can occur when using a\ncombination of tail calls and freplace.\n\nIn an upcoming selftest, the attach target for entry_freplace of\ntailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in\nentry_freplace leads to entry_tc. This results in an infinite loop:\n\nentry_tc -\u0026gt; subprog_tc -\u0026gt; entry_freplace --tailcall-\u0026gt; entry_tc.\n\nThe problem arises because the tail_call_cnt in entry_freplace resets to\nzero each time entry_freplace is executed, causing the tail call mechanism\nto never terminate, eventually leading to a kernel panic.\n\nTo fix this issue, the solution is twofold:\n\n1. Prevent updating a program extended by an freplace program to a\n   prog_array map.\n2. Prevent extending a program that is already part of a prog_array map\n   with an freplace program.\n\nThis ensures that:\n\n* If a program or its subprogram has been extended by an freplace program,\n  it can no longer be updated to a prog_array map.\n* If a program has been added to a prog_array map, neither it nor its\n  subprograms can be extended by an freplace program.\n\nMoreover, an extension program should not be tailcalled. As such, return\n-EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to a\nprog_array map.\n\nAdditionally, fix a minor code style issue by replacing eight spaces with a\ntab for proper formatting.(CVE-2024-47794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/thp: fix deferred split unqueue naming and locking\n\nRecent changes are putting more pressure on THP deferred split queues:\nunder load revealing long-standing races, causing list_del corruptions,\n\u0026quot;Bad page state\u0026quot;s and worse (I keep BUGs in both of those, so usually\ndon\u0026apos;t get to see how badly they end up without).  The relevant recent\nchanges being 6.8\u0026apos;s mTHP, 6.10\u0026apos;s mTHP swapout, and 6.12\u0026apos;s mTHP swapin,\nimproved swap allocation, and underused THP splitting.\n\nBefore fixing locking: rename misleading folio_undo_large_rmappable(),\nwhich does not undo large_rmappable, to folio_unqueue_deferred_split(),\nwhich is what it does.  But that and its out-of-line __callee are mm\ninternals of very limited usability: add comment and WARN_ON_ONCEs to\ncheck usage; and return a bool to say if a deferred split was unqueued,\nwhich can then be used in WARN_ON_ONCEs around safety checks (sparing\ncallers the arcane conditionals in __folio_unqueue_deferred_split()).\n\nJust omit the folio_unqueue_deferred_split() from free_unref_folios(), all\nof whose callers now call it beforehand (and if any forget then bad_page()\nwill tell) - except for its caller put_pages_list(), which itself no\nlonger has any callers (and will be deleted separately).\n\nSwapout: mem_cgroup_swapout() has been resetting folio-\u0026gt;memcg_data 0\nwithout checking and unqueueing a THP folio from deferred split list;\nwhich is unfortunate, since the split_queue_lock depends on the memcg\n(when memcg is enabled); so swapout has been unqueueing such THPs later,\nwhen freeing the folio, using the pgdat\u0026apos;s lock instead: potentially\ncorrupting the memcg\u0026apos;s list.  __remove_mapping() has frozen refcount to 0\nhere, so no problem with calling folio_unqueue_deferred_split() before\nresetting memcg_data.\n\nThat goes back to 5.4 commit 87eaceb3faa5 (\u0026quot;mm: thp: make deferred split\nshrinker memcg aware\u0026quot;): which included a check on swapcache before adding\nto deferred queue, but no check on deferred queue before adding THP to\nswapcache.  That worked fine with the usual sequence of events in reclaim\n(though there were a couple of rare ways in which a THP on deferred queue\ncould have been swapped out), but 6.12 commit dafff3f4c850 (\u0026quot;mm: split\nunderused THPs\u0026quot;) avoids splitting underused THPs in reclaim, which makes\nswapcache THPs on deferred queue commonplace.\n\nKeep the check on swapcache before adding to deferred queue?  Yes: it is\nno longer essential, but preserves the existing behaviour, and is likely\nto be a worthwhile optimization (vmstat showed much more traffic on the\nqueue under swapping load if the check was removed); update its comment.\n\nMemcg-v1 move (deprecated): mem_cgroup_move_account() has been changing\nfolio-\u0026gt;memcg_data without checking and unqueueing a THP folio from the\ndeferred list, sometimes corrupting \u0026quot;from\u0026quot; memcg\u0026apos;s list, like swapout. \nRefcount is non-zero here, so folio_unqueue_deferred_split() can only be\nused in a WARN_ON_ONCE to validate the fix, which must be done earlier:\nmem_cgroup_move_charge_pte_range() first try to split the THP (splitting\nof course unqueues), or skip it if that fails.  Not ideal, but moving\ncharge has been requested, and khugepaged should repair the THP later:\nnobody wants new custom unqueueing code just for this deprecated case.\n\nThe 87eaceb3faa5 commit did have the code to move from one deferred list\nto another (but was not conscious of its unsafety while refcount non-0);\nbut that was removed by 5.6 commit fac0516b5534 (\u0026quot;mm: thp: don\u0026apos;t need care\ndeferred split queue in memcg charge move path\u0026quot;), which argued that the\nexistence of a PMD mapping guarantees that the THP cannot be on a deferred\nlist.  As above, false in rare cases, and now commonly false.\n\nBackport to 6.11 should be straightforward.  Earlier backports must take\ncare that other _deferred_list fixes and dependencies are included.  There\nis not a strong case for backports, but they can fix cornercases.(CVE-2024-53079)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: fix ordering of qlen adjustment\n\nChanges to sch-\u0026gt;q.qlen around qdisc_tree_reduce_backlog() need to happen\n_before_ a call to said function because otherwise it may fail to notify\nparent qdiscs when the child is about to become empty.(CVE-2024-53164)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen/netfront: fix crash when removing device\n\nWhen removing a netfront device directly after a suspend/resume cycle\nit might happen that the queues have not been setup again, causing a\ncrash during the attempt to stop the queues another time.\n\nFix that by checking the queues are existing before trying to stop\nthem.\n\nThis is XSA-465 / CVE-2024-53240.(CVE-2024-53240)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix TCP timers deadlock after rmmod\n\nCommit ef7134c7fc48 (\u0026quot;smb: client: Fix use-after-free of network namespace.\u0026quot;)\nfixed a netns UAF by manually enabled socket refcounting\n(sk-\u0026gt;sk_net_refcnt=1 and sock_inuse_add(net, 1)).\n\nThe reason the patch worked for that bug was because we now hold\nreferences to the netns (get_net_track() gets a ref internally)\nand they\u0026apos;re properly released (internally, on __sk_destruct()),\nbut only because sk-\u0026gt;sk_net_refcnt was set.\n\nProblem:\n(this happens regardless of CONFIG_NET_NS_REFCNT_TRACKER and regardless\nif init_net or other)\n\nSetting sk-\u0026gt;sk_net_refcnt=1 *manually* and *after* socket creation is not\nonly out of cifs scope, but also technically wrong -- it\u0026apos;s set conditionally\nbased on user (=1) vs kernel (=0) sockets.  And net/ implementations\nseem to base their user vs kernel space operations on it.\n\ne.g. upon TCP socket close, the TCP timers are not cleared because\nsk-\u0026gt;sk_net_refcnt=1:\n(cf. commit 151c9c724d05 (\u0026quot;tcp: properly terminate timers for kernel sockets\u0026quot;))\n\nnet/ipv4/tcp.c:\n    void tcp_close(struct sock *sk, long timeout)\n    {\n    \tlock_sock(sk);\n    \t__tcp_close(sk, timeout);\n    \trelease_sock(sk);\n    \tif (!sk-\u0026gt;sk_net_refcnt)\n    \t\tinet_csk_clear_xmit_timers_sync(sk);\n    \tsock_put(sk);\n    }\n\nWhich will throw a lockdep warning and then, as expected, deadlock on\ntcp_write_timer().\n\nA way to reproduce this is by running the reproducer from ef7134c7fc48\nand then \u0026apos;rmmod cifs\u0026apos;.  A few seconds later, the deadlock/lockdep\nwarning shows up.\n\nFix:\nWe shouldn\u0026apos;t mess with socket internals ourselves, so do not set\nsk_net_refcnt manually.\n\nAlso change __sock_create() to sock_create_kern() for explicitness.\n\nAs for non-init_net network namespaces, we deal with it the best way\nwe can -- hold an extra netns reference for server-\u0026gt;ssocket and drop it\nwhen it\u0026apos;s released.  This ensures that the netns still exists whenever\nwe need to create/destroy server-\u0026gt;ssocket, but is not directly tied to\nit.(CVE-2024-54680)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tun: fix tun_napi_alloc_frags()\n\nsyzbot reported the following crash [1]\n\nIssue came with the blamed commit. Instead of going through\nall the iov components, we keep using the first one\nand end up with a malformed skb.\n\n[1]\n\nkernel BUG at net/core/skbuff.c:2849 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 UID: 0 PID: 6230 Comm: syz-executor132 Not tainted 6.13.0-rc1-syzkaller-00407-g96b6fcc0ee41 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024\n RIP: 0010:__pskb_pull_tail+0x1568/0x1570 net/core/skbuff.c:2848\nCode: 38 c1 0f 8c 32 f1 ff ff 4c 89 f7 e8 92 96 74 f8 e9 25 f1 ff ff e8 e8 ae 09 f8 48 8b 5c 24 08 e9 eb fb ff ff e8 d9 ae 09 f8 90 \u0026lt;0f\u0026gt; 0b 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90\nRSP: 0018:ffffc90004cbef30 EFLAGS: 00010293\nRAX: ffffffff8995c347 RBX: 00000000fffffff2 RCX: ffff88802cf45a00\nRDX: 0000000000000000 RSI: 00000000fffffff2 RDI: 0000000000000000\nRBP: ffff88807df0c06a R08: ffffffff8995b084 R09: 1ffff1100fbe185c\nR10: dffffc0000000000 R11: ffffed100fbe185d R12: ffff888076e85d50\nR13: ffff888076e85c80 R14: ffff888076e85cf4 R15: ffff888076e85c80\nFS:  00007f0dca6ea6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f0dca6ead58 CR3: 00000000119da000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  skb_cow_data+0x2da/0xcb0 net/core/skbuff.c:5284\n  tipc_aead_decrypt net/tipc/crypto.c:894 [inline]\n  tipc_crypto_rcv+0x402/0x24e0 net/tipc/crypto.c:1844\n  tipc_rcv+0x57e/0x12a0 net/tipc/node.c:2109\n  tipc_l2_rcv_msg+0x2bd/0x450 net/tipc/bearer.c:668\n  __netif_receive_skb_list_ptype net/core/dev.c:5720 [inline]\n  __netif_receive_skb_list_core+0x8b7/0x980 net/core/dev.c:5762\n  __netif_receive_skb_list net/core/dev.c:5814 [inline]\n  netif_receive_skb_list_internal+0xa51/0xe30 net/core/dev.c:5905\n  gro_normal_list include/net/gro.h:515 [inline]\n  napi_complete_done+0x2b5/0x870 net/core/dev.c:6256\n  napi_complete include/linux/netdevice.h:567 [inline]\n  tun_get_user+0x2ea0/0x4890 drivers/net/tun.c:1982\n  tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2057\n do_iter_readv_writev+0x600/0x880\n  vfs_writev+0x376/0xba0 fs/read_write.c:1050\n  do_writev+0x1b6/0x360 fs/read_write.c:1096\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(CVE-2024-56372)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix atomic calls in ath12k_mac_op_set_bitrate_mask()\n\nWhen I try to manually set bitrates:\n\niw wlan0 set bitrates legacy-2.4 1\n\nI get sleeping from invalid context error, see below. Fix that by switching to\nuse recently introduced ieee80211_iterate_stations_mtx().\n\nDo note that WCN6855 firmware is still crashing, I\u0026apos;m not sure if that firmware\neven supports bitrate WMI commands and should we consider disabling\nath12k_mac_op_set_bitrate_mask() for WCN6855? But that\u0026apos;s for another patch.\n\nBUG: sleeping function called from invalid context at drivers/net/wireless/ath/ath12k/wmi.c:420\nin_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 2236, name: iw\npreempt_count: 0, expected: 0\nRCU nest depth: 1, expected: 0\n3 locks held by iw/2236:\n #0: ffffffffabc6f1d8 (cb_lock){++++}-{3:3}, at: genl_rcv+0x14/0x40\n #1: ffff888138410810 (\u0026amp;rdev-\u0026gt;wiphy.mtx){+.+.}-{3:3}, at: nl80211_pre_doit+0x54d/0x800 [cfg80211]\n #2: ffffffffab2cfaa0 (rcu_read_lock){....}-{1:2}, at: ieee80211_iterate_stations_atomic+0x2f/0x200 [mac80211]\nCPU: 3 UID: 0 PID: 2236 Comm: iw Not tainted 6.11.0-rc7-wt-ath+ #1772\nHardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xa4/0xe0\n dump_stack+0x10/0x20\n __might_resched+0x363/0x5a0\n ? __alloc_skb+0x165/0x340\n __might_sleep+0xad/0x160\n ath12k_wmi_cmd_send+0xb1/0x3d0 [ath12k]\n ? ath12k_wmi_init_wcn7850+0xa40/0xa40 [ath12k]\n ? __netdev_alloc_skb+0x45/0x7b0\n ? __asan_memset+0x39/0x40\n ? ath12k_wmi_alloc_skb+0xf0/0x150 [ath12k]\n ? reacquire_held_locks+0x4d0/0x4d0\n ath12k_wmi_set_peer_param+0x340/0x5b0 [ath12k]\n ath12k_mac_disable_peer_fixed_rate+0xa3/0x110 [ath12k]\n ? ath12k_mac_vdev_stop+0x4f0/0x4f0 [ath12k]\n ieee80211_iterate_stations_atomic+0xd4/0x200 [mac80211]\n ath12k_mac_op_set_bitrate_mask+0x5d2/0x1080 [ath12k]\n ? ath12k_mac_vif_chan+0x320/0x320 [ath12k]\n drv_set_bitrate_mask+0x267/0x470 [mac80211]\n ieee80211_set_bitrate_mask+0x4cc/0x8a0 [mac80211]\n ? __this_cpu_preempt_check+0x13/0x20\n nl80211_set_tx_bitrate_mask+0x2bc/0x530 [cfg80211]\n ? nl80211_parse_tx_bitrate_mask+0x2320/0x2320 [cfg80211]\n ? trace_contention_end+0xef/0x140\n ? rtnl_unlock+0x9/0x10\n ? nl80211_pre_doit+0x557/0x800 [cfg80211]\n genl_family_rcv_msg_doit+0x1f0/0x2e0\n ? genl_family_rcv_msg_attrs_parse.isra.0+0x250/0x250\n ? ns_capable+0x57/0xd0\n genl_family_rcv_msg+0x34c/0x600\n ? genl_family_rcv_msg_dumpit+0x310/0x310\n ? __lock_acquire+0xc62/0x1de0\n ? he_set_mcs_mask.isra.0+0x8d0/0x8d0 [cfg80211]\n ? nl80211_parse_tx_bitrate_mask+0x2320/0x2320 [cfg80211]\n ? cfg80211_external_auth_request+0x690/0x690 [cfg80211]\n genl_rcv_msg+0xa0/0x130\n netlink_rcv_skb+0x14c/0x400\n ? genl_family_rcv_msg+0x600/0x600\n ? netlink_ack+0xd70/0xd70\n ? rwsem_optimistic_spin+0x4f0/0x4f0\n ? genl_rcv+0x14/0x40\n ? down_read_killable+0x580/0x580\n ? netlink_deliver_tap+0x13e/0x350\n ? __this_cpu_preempt_check+0x13/0x20\n genl_rcv+0x23/0x40\n netlink_unicast+0x45e/0x790\n ? netlink_attachskb+0x7f0/0x7f0\n netlink_sendmsg+0x7eb/0xdb0\n ? netlink_unicast+0x790/0x790\n ? __this_cpu_preempt_check+0x13/0x20\n ? selinux_socket_sendmsg+0x31/0x40\n ? netlink_unicast+0x790/0x790\n __sock_sendmsg+0xc9/0x160\n ____sys_sendmsg+0x620/0x990\n ? kernel_sendmsg+0x30/0x30\n ? __copy_msghdr+0x410/0x410\n ? __kasan_check_read+0x11/0x20\n ? mark_lock+0xe6/0x1470\n ___sys_sendmsg+0xe9/0x170\n ? copy_msghdr_from_user+0x120/0x120\n ? __lock_acquire+0xc62/0x1de0\n ? do_fault_around+0x2c6/0x4e0\n ? do_user_addr_fault+0x8c1/0xde0\n ? reacquire_held_locks+0x220/0x4d0\n ? do_user_addr_fault+0x8c1/0xde0\n ? __kasan_check_read+0x11/0x20\n ? __fdget+0x4e/0x1d0\n ? sockfd_lookup_light+0x1a/0x170\n __sys_sendmsg+0xd2/0x180\n ? __sys_sendmsg_sock+0x20/0x20\n ? reacquire_held_locks+0x4d0/0x4d0\n ? debug_smp_processor_id+0x17/0x20\n __x64_sys_sendmsg+0x72/0xb0\n ? lockdep_hardirqs_on+0x7d/0x100\n x64_sys_call+0x894/0x9f0\n do_syscall_64+0x64/0x130\n entry_SYSCALL_64_after_\n---truncated---(CVE-2024-56607)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: do not defer rule destruction via call_rcu\n\nnf_tables_chain_destroy can sleep, it can\u0026apos;t be used from call_rcu\ncallbacks.\n\nMoreover, nf_tables_rule_release() is only safe for error unwinding,\nwhile transaction mutex is held and the to-be-desroyed rule was not\nexposed to either dataplane or dumps, as it deactives+frees without\nthe required synchronize_rcu() in-between.\n\nnft_rule_expr_deactivate() callbacks will change -\u0026gt;use counters\nof other chains/sets, see e.g. nft_lookup .deactivate callback, these\nmust be serialized via transaction mutex.\n\nAlso add a few lockdep asserts to make this more explicit.\n\nCalling synchronize_rcu() isn\u0026apos;t ideal, but fixing this without is hard\nand way more intrusive.  As-is, we can get:\n\nWARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x..\nWorkqueue: events nf_tables_trans_destroy_work\nRIP: 0010:nft_set_destroy+0x3fe/0x5c0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n nf_tables_trans_destroy_work+0x6b7/0xad0\n process_one_work+0x64a/0xce0\n worker_thread+0x613/0x10d0\n\nIn case the synchronize_rcu becomes an issue, we can explore alternatives.\n\nOne way would be to allocate nft_trans_rule objects + one nft_trans_chain\nobject, deactivate the rules + the chain and then defer the freeing to the\nnft destroy workqueue.  We\u0026apos;d still need to keep the synchronize_rcu path as\na fallback to handle -ENOMEM corner cases though.(CVE-2024-56655)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: defer final \u0026apos;struct net\u0026apos; free in netns dismantle\n\nIlya reported a slab-use-after-free in dst_destroy [1]\n\nIssue is in xfrm6_net_init() and xfrm4_net_init() :\n\nThey copy xfrm[46]_dst_ops_template into net-\u0026gt;xfrm.xfrm[46]_dst_ops.\n\nBut net structure might be freed before all the dst callbacks are\ncalled. So when dst_destroy() calls later :\n\nif (dst-\u0026gt;ops-\u0026gt;destroy)\n    dst-\u0026gt;ops-\u0026gt;destroy(dst);\n\ndst-\u0026gt;ops points to the old net-\u0026gt;xfrm.xfrm[46]_dst_ops, which has been freed.\n\nSee a relevant issue fixed in :\n\nac888d58869b (\u0026quot;net: do not delay dst_entries_add() in dst_release()\u0026quot;)\n\nA fix is to queue the \u0026apos;struct net\u0026apos; to be freed after one\nanother cleanup_net() round (and existing rcu_barrier())\n\n[1]\n\nBUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112)\nRead of size 8 at addr ffff8882137ccab0 by task swapper/37/0\nDec 03 05:46:18 kernel:\nCPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67\nHardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\ndump_stack_lvl (lib/dump_stack.c:124)\nprint_address_description.constprop.0 (mm/kasan/report.c:378)\n? dst_destroy (net/core/dst.c:112)\nprint_report (mm/kasan/report.c:489)\n? dst_destroy (net/core/dst.c:112)\n? kasan_addr_to_slab (mm/kasan/common.c:37)\nkasan_report (mm/kasan/report.c:603)\n? dst_destroy (net/core/dst.c:112)\n? rcu_do_batch (kernel/rcu/tree.c:2567)\ndst_destroy (net/core/dst.c:112)\nrcu_do_batch (kernel/rcu/tree.c:2567)\n? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491)\n? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406)\nrcu_core (kernel/rcu/tree.c:2825)\nhandle_softirqs (kernel/softirq.c:554)\n__irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637)\nirq_exit_rcu (kernel/softirq.c:651)\nsysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\nasm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702)\nRIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743)\nCode: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90\nRSP: 0018:ffff888100d2fe00 EFLAGS: 00000246\nRAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123\nRBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d\nR10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000\nR13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000\n? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148)\n? cpuidle_idle_call (kernel/sched/idle.c:186)\ndefault_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118)\ncpuidle_idle_call (kernel/sched/idle.c:186)\n? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168)\n? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848)\n? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406)\n? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59)\ndo_idle (kernel/sched/idle.c:326)\ncpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1))\nstart_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282)\n? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232)\n? soft_restart_cpu (arch/x86/kernel/head_64.S:452)\ncommon_startup_64 (arch/x86/kernel/head_64.S:414)\n \u0026lt;/TASK\u0026gt;\nDec 03 05:46:18 kernel:\nAllocated by task 12184:\nkasan_save_stack (mm/kasan/common.c:48)\nkasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69)\n__kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)\nkmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141)\ncopy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480)\ncreate_new_namespaces\n---truncated---(CVE-2024-56658)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: lapb: increase LAPB_HEADER_LEN\n\nIt is unclear if net/lapb code is supposed to be ready for 8021q.\n\nWe can at least avoid crashes like the following :\n\nskbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2\n------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:206 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\n RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]\n RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216\nCode: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 \u0026lt;0f\u0026gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3\nRSP: 0018:ffffc90002ddf638 EFLAGS: 00010282\nRAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600\nRDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000\nRBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60\nR10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140\nR13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016\nFS:  00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  skb_push+0xe5/0x100 net/core/skbuff.c:2636\n  nr_header+0x36/0x320 net/netrom/nr_dev.c:69\n  dev_hard_header include/linux/netdevice.h:3148 [inline]\n  vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83\n  dev_hard_header include/linux/netdevice.h:3148 [inline]\n  lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257\n  lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447\n  lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149\n lapb_establish_data_link+0x84/0xd0\n lapb_device_event+0x4e0/0x670\n  notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93\n __dev_notify_flags+0x207/0x400\n  dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922\n  devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188\n  inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003\n  sock_do_ioctl+0x158/0x460 net/socket.c:1227\n  sock_ioctl+0x626/0x8e0 net/socket.c:1346\n  vfs_ioctl fs/ioctl.c:51 [inline]\n  __do_sys_ioctl fs/ioctl.c:907 [inline]\n  __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83(CVE-2024-56659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: mscc: ocelot: fix incorrect IFH SRC_PORT field in ocelot_ifh_set_basic()\n\nPackets injected by the CPU should have a SRC_PORT field equal to the\nCPU port module index in the Analyzer block (ocelot-\u0026gt;num_phys_ports).\n\nThe blamed commit copied the ocelot_ifh_set_basic() call incorrectly\nfrom ocelot_xmit_common() in net/dsa/tag_ocelot.c. Instead of calling\nwith \u0026quot;x\u0026quot;, it calls with BIT_ULL(x), but the field is not a port mask,\nbut rather a single port index.\n\n[ side note: this is the technical debt of code duplication :( ]\n\nThe error used to be silent and doesn\u0026apos;t appear to have other\nuser-visible manifestations, but with new changes in the packing\nlibrary, it now fails loudly as follows:\n\n------------[ cut here ]------------\nCannot store 0x40 inside bits 46-43 - will truncate\nsja1105 spi2.0: xmit timed out\nWARNING: CPU: 1 PID: 102 at lib/packing.c:98 __pack+0x90/0x198\nsja1105 spi2.0: timed out polling for tstamp\nCPU: 1 UID: 0 PID: 102 Comm: felix_xmit\nTainted: G        W        N 6.13.0-rc1-00372-gf706b85d972d-dirty #2605\nCall trace:\n __pack+0x90/0x198 (P)\n __pack+0x90/0x198 (L)\n packing+0x78/0x98\n ocelot_ifh_set_basic+0x260/0x368\n ocelot_port_inject_frame+0xa8/0x250\n felix_port_deferred_xmit+0x14c/0x258\n kthread_worker_fn+0x134/0x350\n kthread+0x114/0x138\n\nThe code path pertains to the ocelot switchdev driver and to the felix\nsecondary DSA tag protocol, ocelot-8021q. Here seen with ocelot-8021q.\n\nThe messenger (packing) is not really to blame, so fix the original\ncommit instead.(CVE-2024-56717)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: at_xdmac: avoid null_prt_deref in at_xdmac_prep_dma_memset\n\nThe at_xdmac_memset_create_desc may return NULL, which will lead to a\nnull pointer dereference. For example, the len input is error, or the\natchan-\u0026gt;free_descs_list is empty and memory is exhausted. Therefore, add\ncheck to avoid this.(CVE-2024-56767)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: gpio-charger: Fix set charge current limits\n\nFix set charge current limits for devices which allow to set the lowest\ncharge current limit to be greater zero. If requested charge current limit\nis below lowest limit, the index equals current_limit_map_size which leads\nto accessing memory beyond allocated memory.(CVE-2024-57792)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix corrupt config pages PHY state is switched in sysfs\n\nThe driver, through the SAS transport, exposes a sysfs interface to\nenable/disable PHYs in a controller/expander setup.  When multiple PHYs\nare disabled and enabled in rapid succession, the persistent and current\nconfig pages related to SAS IO unit/SAS Expander pages could get\ncorrupted.\n\nUse separate memory for each config request.(CVE-2024-57804)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: megaraid_sas: Fix for a potential deadlock\n\nThis fixes a \u0026apos;possible circular locking dependency detected\u0026apos; warning\n      CPU0                    CPU1\n      ----                    ----\n lock(\u0026amp;instance-\u0026gt;reset_mutex);\n                              lock(\u0026amp;shost-\u0026gt;scan_mutex);\n                              lock(\u0026amp;instance-\u0026gt;reset_mutex);\n lock(\u0026amp;shost-\u0026gt;scan_mutex);\n\nFix this by temporarily releasing the reset_mutex.(CVE-2024-57807)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Have process_string() also allow arrays\n\nIn order to catch a common bug where a TRACE_EVENT() TP_fast_assign()\nassigns an address of an allocated string to the ring buffer and then\nreferences it in TP_printk(), which can be executed hours later when the\nstring is free, the function test_event_printk() runs on all events as\nthey are registered to make sure there\u0026apos;s no unwanted dereferencing.\n\nIt calls process_string() to handle cases in TP_printk() format that has\n\u0026quot;%s\u0026quot;. It returns whether or not the string is safe. But it can have some\nfalse positives.\n\nFor instance, xe_bo_move() has:\n\n TP_printk(\u0026quot;move_lacks_source:%s, migrate object %p [size %zu] from %s to %s device_id:%s\u0026quot;,\n            __entry-\u0026gt;move_lacks_source ? \u0026quot;yes\u0026quot; : \u0026quot;no\u0026quot;, __entry-\u0026gt;bo, __entry-\u0026gt;size,\n            xe_mem_type_to_name[__entry-\u0026gt;old_placement],\n            xe_mem_type_to_name[__entry-\u0026gt;new_placement], __get_str(device_id))\n\nWhere the \u0026quot;%s\u0026quot; references into xe_mem_type_to_name[]. This is an array of\npointers that should be safe for the event to access. Instead of flagging\nthis as a bad reference, if a reference points to an array, where the\nrecord field is the index, consider it safe.(CVE-2024-57930)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-blk: don\u0026apos;t keep queue frozen during system suspend\n\nCommit 4ce6e2db00de (\u0026quot;virtio-blk: Ensure no requests in virtqueues before\ndeleting vqs.\u0026quot;) replaces queue quiesce with queue freeze in virtio-blk\u0026apos;s\nPM callbacks. And the motivation is to drain inflight IOs before suspending.\n\nblock layer\u0026apos;s queue freeze looks very handy, but it is also easy to cause\ndeadlock, such as, any attempt to call into bio_queue_enter() may run into\ndeadlock if the queue is frozen in current context. There are all kinds\nof -\u0026gt;suspend() called in suspend context, so keeping queue frozen in the\nwhole suspend context isn\u0026apos;t one good idea. And Marek reported lockdep\nwarning[1] caused by virtio-blk\u0026apos;s freeze queue in virtblk_freeze().\n\n[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/\n\nGiven the motivation is to drain in-flight IOs, it can be done by calling\nfreeze \u0026amp; unfreeze, meantime restore to previous behavior by keeping queue\nquiesced during suspend.(CVE-2024-57946)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock, bfq: fix waker_bfqq UAF after bfq_split_bfqq()\n\nOur syzkaller report a following UAF for v6.6:\n\nBUG: KASAN: slab-use-after-free in bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958\nRead of size 8 at addr ffff8881b57147d8 by task fsstress/232726\n\nCPU: 2 PID: 232726 Comm: fsstress Not tainted 6.6.0-g3629d1885222 #39\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106\n print_address_description.constprop.0+0x66/0x300 mm/kasan/report.c:364\n print_report+0x3e/0x70 mm/kasan/report.c:475\n kasan_report+0xb8/0xf0 mm/kasan/report.c:588\n hlist_add_head include/linux/list.h:1023 [inline]\n bfq_init_rq+0x175d/0x17a0 block/bfq-iosched.c:6958\n bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271\n bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323\n blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660\n blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143\n __submit_bio+0xa0/0x6b0 block/blk-core.c:639\n __submit_bio_noacct_mq block/blk-core.c:718 [inline]\n submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747\n submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847\n __ext4_read_bh fs/ext4/super.c:205 [inline]\n ext4_read_bh+0x15e/0x2e0 fs/ext4/super.c:230\n __read_extent_tree_block+0x304/0x6f0 fs/ext4/extents.c:567\n ext4_find_extent+0x479/0xd20 fs/ext4/extents.c:947\n ext4_ext_map_blocks+0x1a3/0x2680 fs/ext4/extents.c:4182\n ext4_map_blocks+0x929/0x15a0 fs/ext4/inode.c:660\n ext4_iomap_begin_report+0x298/0x480 fs/ext4/inode.c:3569\n iomap_iter+0x3dd/0x1010 fs/iomap/iter.c:91\n iomap_fiemap+0x1f4/0x360 fs/iomap/fiemap.c:80\n ext4_fiemap+0x181/0x210 fs/ext4/extents.c:5051\n ioctl_fiemap.isra.0+0x1b4/0x290 fs/ioctl.c:220\n do_vfs_ioctl+0x31c/0x11a0 fs/ioctl.c:811\n __do_sys_ioctl fs/ioctl.c:869 [inline]\n __se_sys_ioctl+0xae/0x190 fs/ioctl.c:857\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x70/0x120 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nAllocated by task 232719:\n kasan_save_stack+0x22/0x50 mm/kasan/common.c:45\n kasan_set_track+0x25/0x30 mm/kasan/common.c:52\n __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328\n kasan_slab_alloc include/linux/kasan.h:188 [inline]\n slab_post_alloc_hook mm/slab.h:768 [inline]\n slab_alloc_node mm/slub.c:3492 [inline]\n kmem_cache_alloc_node+0x1b8/0x6f0 mm/slub.c:3537\n bfq_get_queue+0x215/0x1f00 block/bfq-iosched.c:5869\n bfq_get_bfqq_handle_split+0x167/0x5f0 block/bfq-iosched.c:6776\n bfq_init_rq+0x13a4/0x17a0 block/bfq-iosched.c:6938\n bfq_insert_request.isra.0+0xe8/0xa20 block/bfq-iosched.c:6271\n bfq_insert_requests+0x27f/0x390 block/bfq-iosched.c:6323\n blk_mq_insert_request+0x290/0x8f0 block/blk-mq.c:2660\n blk_mq_submit_bio+0x1021/0x15e0 block/blk-mq.c:3143\n __submit_bio+0xa0/0x6b0 block/blk-core.c:639\n __submit_bio_noacct_mq block/blk-core.c:718 [inline]\n submit_bio_noacct_nocheck+0x5b7/0x810 block/blk-core.c:747\n submit_bio_noacct+0xca0/0x1990 block/blk-core.c:847\n __ext4_read_bh fs/ext4/super.c:205 [inline]\n ext4_read_bh_nowait+0x15a/0x240 fs/ext4/super.c:217\n ext4_read_bh_lock+0xac/0xd0 fs/ext4/super.c:242\n ext4_bread_batch+0x268/0x500 fs/ext4/inode.c:958\n __ext4_find_entry+0x448/0x10f0 fs/ext4/namei.c:1671\n ext4_lookup_entry fs/ext4/namei.c:1774 [inline]\n ext4_lookup.part.0+0x359/0x6f0 fs/ext4/namei.c:1842\n ext4_lookup+0x72/0x90 fs/ext4/namei.c:1839\n __lookup_slow+0x257/0x480 fs/namei.c:1696\n lookup_slow fs/namei.c:1713 [inline]\n walk_component+0x454/0x5c0 fs/namei.c:2004\n link_path_walk.part.0+0x773/0xda0 fs/namei.c:2331\n link_path_walk fs/namei.c:3826 [inline]\n path_openat+0x1b9/0x520 fs/namei.c:3826\n do_filp_open+0x1b7/0x400 fs/namei.c:3857\n do_sys_openat2+0x5dc/0x6e0 fs/open.c:1428\n do_sys_open fs/open.c:1443 [inline]\n __do_sys_openat fs/open.c:1459 [inline]\n __se_sys_openat fs/open.c:1454 [inline]\n __x64_sys_openat+0x148/0x200 fs/open.c:1454\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_6\n---truncated---(CVE-2025-21631)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occur\n\nscsi_execute_cmd() function can return both negative (linux codes) and\npositive (scsi_cmnd result field) error codes.\n\nCurrently the driver just passes error codes of scsi_execute_cmd() to\nhwmon core, which is incorrect because hwmon only checks for negative\nerror codes. This leads to hwmon reporting uninitialized data to\nuserspace in case of SCSI errors (for example if the disk drive was\ndisconnected).\n\nThis patch checks scsi_execute_cmd() output and returns -EIO if it\u0026apos;s\nerror code is positive.\n\n[groeck: Avoid inline variable declaration for portability](CVE-2025-21656)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()\n\nThis patch addresses a null-ptr-deref in qt2_process_read_urb() due to\nan incorrect bounds check in the following:\n\n       if (newport \u0026gt; serial-\u0026gt;num_ports) {\n               dev_err(\u0026amp;port-\u0026gt;dev,\n                       \u0026quot;%s - port change to invalid port: %i\\n\u0026quot;,\n                       __func__, newport);\n               break;\n       }\n\nThe condition doesn\u0026apos;t account for the valid range of the serial-\u0026gt;port\nbuffer, which is from 0 to serial-\u0026gt;num_ports - 1. When newport is equal\nto serial-\u0026gt;num_ports, the assignment of \u0026quot;port\u0026quot; in the\nfollowing code is out-of-bounds and NULL:\n\n       serial_priv-\u0026gt;current_port = newport;\n       port = serial-\u0026gt;port[serial_priv-\u0026gt;current_port];\n\nThe fix checks if newport is greater than or equal to serial-\u0026gt;num_ports\nindicating it is out-of-bounds.(CVE-2025-21689)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Truncate address space when flipping GFS2_DIF_JDATA flag\n\nTruncate an inode\u0026apos;s address space when flipping the GFS2_DIF_JDATA flag:\ndepending on that flag, the pages in the address space will either use\nbuffer heads or iomap_folio_state structs, and we cannot mix the two.(CVE-2025-21699)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdc-acm: Check control transfer buffer size before access\n\nIf the first fragment is shorter than struct usb_cdc_notification, we can\u0026apos;t\ncalculate an expected_size. Log an error and discard the notification\ninstead of reading lengths from memory outside the received data, which can\nlead to memory corruption when the expected_size decreases between\nfragments, causing `expected_size - acm-\u0026gt;nb_index` to wrap.\n\nThis issue has been present since the beginning of git history; however,\nit only leads to memory corruption since commit ea2583529cd1\n(\u0026quot;cdc-acm: reassemble fragmented notifications\u0026quot;).\n\nA mitigating factor is that acm_ctrl_irq() can only execute after userspace\nhas opened /dev/ttyACM*; but if ModemManager is running, ModemManager will\ndo that automatically depending on the USB device\u0026apos;s vendor/product IDs and\nits other interfaces.(CVE-2025-21704)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-79.0.0.72.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-79.0.0.72.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-79.0.0.72.oe2403.aarch64.rpm","kernel-6.6.0-79.0.0.72.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-79.0.0.72.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-79.0.0.72.oe2403.aarch64.rpm","kernel-devel-6.6.0-79.0.0.72.oe2403.aarch64.rpm","kernel-headers-6.6.0-79.0.0.72.oe2403.aarch64.rpm","kernel-source-6.6.0-79.0.0.72.oe2403.aarch64.rpm","kernel-tools-6.6.0-79.0.0.72.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-79.0.0.72.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-79.0.0.72.oe2403.aarch64.rpm","perf-6.6.0-79.0.0.72.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-79.0.0.72.oe2403.aarch64.rpm","python3-perf-6.6.0-79.0.0.72.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-79.0.0.72.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-79.0.0.72.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-79.0.0.72.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-79.0.0.72.oe2403.x86_64.rpm","kernel-6.6.0-79.0.0.72.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-79.0.0.72.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-79.0.0.72.oe2403.x86_64.rpm","kernel-devel-6.6.0-79.0.0.72.oe2403.x86_64.rpm","kernel-headers-6.6.0-79.0.0.72.oe2403.x86_64.rpm","kernel-source-6.6.0-79.0.0.72.oe2403.x86_64.rpm","kernel-tools-6.6.0-79.0.0.72.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-79.0.0.72.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-79.0.0.72.oe2403.x86_64.rpm","perf-6.6.0-79.0.0.72.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-79.0.0.72.oe2403.x86_64.rpm","python3-perf-6.6.0-79.0.0.72.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-79.0.0.72.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1204"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47794"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53079"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53164"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53240"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-54680"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56372"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56607"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56655"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56658"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56659"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56717"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56767"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57792"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57804"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57807"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57930"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57946"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21631"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21656"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21689"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21699"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21704"}],"database_specific":{"severity":"High"}}