{"schema_version":"1.7.2","id":"OESA-2025-1879","modified":"2025-07-25T13:15:58Z","published":"2025-07-25T13:15:58Z","upstream":["CVE-2024-58237","CVE-2025-21703","CVE-2025-21829","CVE-2025-21894","CVE-2025-21904","CVE-2025-21920","CVE-2025-21926","CVE-2025-21938","CVE-2025-21960","CVE-2025-21961","CVE-2025-21975","CVE-2025-21997","CVE-2025-22004","CVE-2025-22050","CVE-2025-22053","CVE-2025-22054","CVE-2025-22055","CVE-2025-22058","CVE-2025-22062","CVE-2025-22103","CVE-2025-22111","CVE-2025-23142","CVE-2025-23155","CVE-2025-37757","CVE-2025-37786","CVE-2025-37787","CVE-2025-37788","CVE-2025-37790","CVE-2025-37797","CVE-2025-37817","CVE-2025-37820","CVE-2025-37823","CVE-2025-37824","CVE-2025-37864","CVE-2025-37865","CVE-2025-38061","CVE-2025-38075","CVE-2025-38079","CVE-2025-38103","CVE-2025-38115","CVE-2025-38117","CVE-2025-38120","CVE-2025-38124","CVE-2025-38127","CVE-2025-38157","CVE-2025-38219","CVE-2025-38220","CVE-2025-38226","CVE-2025-38298","CVE-2025-38337"],"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: consider that tail calls invalidate packet pointers\n\nTail-called programs could execute any of the helpers that invalidate\npacket pointers. Hence, conservatively assume that each tail call\ninvalidates packet pointers.\n\nMaking the change in bpf_helper_changes_pkt_data() automatically makes\nuse of check_cfg() logic that computes 'changes_pkt_data' effect for\nglobal sub-programs, such that the following program could be\nrejected:\n\n    int tail_call(struct __sk_buff *sk)\n    {\n    \tbpf_tail_call_static(sk, &jmp_table, 0);\n    \treturn 0;\n    }\n\n    SEC("tc")\n    int not_safe(struct __sk_buff *sk)\n    {\n    \tint *p = (void *)(long)sk->data;\n    \t... make p valid ...\n    \ttail_call(sk);\n    \t*p = 42; /* this is unsafe */\n    \t...\n    }\n\nThe tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that\ncan invalidate packet pointers. Otherwise, it can't be freplaced with\ntailcall_freplace.c:entry_freplace() that does a tail call.(CVE-2024-58237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetem: Update sch->q.qlen before qdisc_tree_reduce_backlog()\n\nqdisc_tree_reduce_backlog() notifies parent qdisc only if child\nqdisc becomes empty, therefore we need to reduce the backlog of the\nchild qdisc before calling it. Otherwise it would miss the opportunity\nto call cops->qlen_notify(), in the case of DRR, it resulted in UAF\nsince DRR uses ->qlen_notify() to maintain its active list.(CVE-2025-21703)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix the warning "__rxe_cleanup+0x12c/0x170 [rdma_rxe]"\n\nThe Call Trace is as below:\n"\n  <TASK>\n  ? show_regs.cold+0x1a/0x1f\n  ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]\n  ? __warn+0x84/0xd0\n  ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]\n  ? report_bug+0x105/0x180\n  ? handle_bug+0x46/0x80\n  ? exc_invalid_op+0x19/0x70\n  ? asm_exc_invalid_op+0x1b/0x20\n  ? __rxe_cleanup+0x12c/0x170 [rdma_rxe]\n  ? __rxe_cleanup+0x124/0x170 [rdma_rxe]\n  rxe_destroy_qp.cold+0x24/0x29 [rdma_rxe]\n  ib_destroy_qp_user+0x118/0x190 [ib_core]\n  rdma_destroy_qp.cold+0x43/0x5e [rdma_cm]\n  rtrs_cq_qp_destroy.cold+0x1d/0x2b [rtrs_core]\n  rtrs_srv_close_work.cold+0x1b/0x31 [rtrs_server]\n  process_one_work+0x21d/0x3f0\n  worker_thread+0x4a/0x3c0\n  ? process_one_work+0x3f0/0x3f0\n  kthread+0xf0/0x120\n  ? kthread_complete_and_exit+0x20/0x20\n  ret_from_fork+0x22/0x30\n  </TASK>\n"\nWhen too many rdma resources are allocated, rxe needs more time to\nhandle these rdma resources. Sometimes with the current timeout, rxe\ncan not release the rdma resources correctly.\n\nCompared with other rdma drivers, a bigger timeout is used.(CVE-2025-21829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNC\n\nActually ENETC VFs do not support HWTSTAMP_TX_ONESTEP_SYNC because only\nENETC PF can access PMa_SINGLE_STEP registers. And there will be a crash\nif VFs are used to test one-step timestamp, the crash log as follows.\n\n[  129.110909] Unable to handle kernel paging request at virtual address 00000000000080c0\n[  129.287769] Call trace:\n[  129.290219]  enetc_port_mac_wr+0x30/0xec (P)\n[  129.294504]  enetc_start_xmit+0xda4/0xe74\n[  129.298525]  enetc_xmit+0x70/0xec\n[  129.301848]  dev_hard_start_xmit+0x98/0x118(CVE-2025-21894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncaif_virtio: fix wrong pointer check in cfv_probe()\n\ndel_vqs() frees virtqueues, therefore cfv->vq_tx pointer should be checked\nfor NULL before calling it, not cfv->vdev. Also the current implementation\nis redundant because the pointer cfv->vdev is dereferenced before it is\nchecked for NULL.\n\nFix this by checking cfv->vq_tx for NULL instead of cfv->vdev before\ncalling del_vqs().(CVE-2025-21904)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvlan: enforce underlying device type\n\nCurrently, VLAN devices can be created on top of non-ethernet devices.\n\nBesides the fact that it doesn't make much sense, this also causes a\nbug which leaks the address of a kernel function to usermode.\n\nWhen creating a VLAN device, we initialize GARP (garp_init_applicant)\nand MRP (mrp_init_applicant) for the underlying device.\n\nAs part of the initialization process, we add the multicast address of\neach applicant to the underlying device, by calling dev_mc_add.\n\n__dev_mc_add uses dev->addr_len to determine the length of the new\nmulticast address.\n\nThis causes an out-of-bounds read if dev->addr_len is greater than 6,\nsince the multicast addresses provided by GARP and MRP are only 6\nbytes long.\n\nThis behaviour can be reproduced using the following commands:\n\nip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo\nip l set up dev gretest\nip link add link gretest name vlantest type vlan id 100\n\nThen, the following command will display the address of garp_pdu_rcv:\n\nip maddr show | grep 01:80:c2:00:00:21\n\nFix the bug by enforcing the type of the underlying device during VLAN\ndevice initialization.(CVE-2025-21920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gso: fix ownership in __udp_gso_segment\n\nIn __udp_gso_segment the skb destructor is removed before segmenting the\nskb but the socket reference is kept as-is. This is an issue if the\noriginal skb is later orphaned as we can hit the following bug:\n\n  kernel BUG at ./include/linux/skbuff.h:3312!  (skb_orphan)\n  RIP: 0010:ip_rcv_core+0x8b2/0xca0\n  Call Trace:\n   ip_rcv+0xab/0x6e0\n   __netif_receive_skb_one_core+0x168/0x1b0\n   process_backlog+0x384/0x1100\n   __napi_poll.constprop.0+0xa1/0x370\n   net_rx_action+0x925/0xe50\n\nThe above can happen following a sequence of events when using\nOpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes an\nOVS_ACTION_ATTR_OUTPUT action:\n\n1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb\n   goes through queue_gso_packets and then __udp_gso_segment, where its\n   destructor is removed.\n2. The segments' data are copied and sent to userspace.\n3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the\n   same original skb is sent to its path.\n4. If it later hits skb_orphan, we hit the bug.\n\nFix this by also removing the reference to the socket in\n__udp_gso_segment.(CVE-2025-21926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix 'scheduling while atomic' in mptcp_pm_nl_append_new_local_addr\n\nIf multiple connection requests attempt to create an implicit mptcp\nendpoint in parallel, more than one caller may end up in\nmptcp_pm_nl_append_new_local_addr because none found the address in\nlocal_addr_list during their call to mptcp_pm_nl_get_local_id.  In this\ncase, the concurrent new_local_addr calls may delete the address entry\ncreated by the previous caller.  These deletes use synchronize_rcu, but\nthis is not permitted in some of the contexts where this function may be\ncalled.  During packet recv, the caller may be in a rcu read critical\nsection and have preemption disabled.\n\nAn example stack:\n\n   BUG: scheduling while atomic: swapper/2/0/0x00000302\n\n   Call Trace:\n   <IRQ>\n   dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))\n   dump_stack (lib/dump_stack.c:124)\n   __schedule_bug (kernel/sched/core.c:5943)\n   schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33 kernel/sched/core.c:5970)\n   __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207 kernel/sched/features.h:29 kernel/sched/core.c:6621)\n   schedule (arch/x86/include/asm/preempt.h:84 kernel/sched/core.c:6804 kernel/sched/core.c:6818)\n   schedule_timeout (kernel/time/timer.c:2160)\n   wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116 kernel/sched/completion.c:127 kernel/sched/completion.c:148)\n   __wait_rcu_gp (include/linux/rcupdate.h:311 kernel/rcu/update.c:444)\n   synchronize_rcu (kernel/rcu/tree.c:3609)\n   mptcp_pm_nl_append_new_local_addr (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061)\n   mptcp_pm_nl_get_local_id (net/mptcp/pm_netlink.c:1164)\n   mptcp_pm_get_local_id (net/mptcp/pm.c:420)\n   subflow_check_req (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213)\n   subflow_v4_route_req (net/mptcp/subflow.c:305)\n   tcp_conn_request (net/ipv4/tcp_input.c:7216)\n   subflow_v4_conn_request (net/mptcp/subflow.c:651)\n   tcp_rcv_state_process (net/ipv4/tcp_input.c:6709)\n   tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934)\n   tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2334)\n   ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))\n   ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234)\n   ip_local_deliver (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)\n   ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580)\n   ip_sublist_rcv (net/ipv4/ip_input.c:640)\n   ip_list_rcv (net/ipv4/ip_input.c:675)\n   __netif_receive_skb_list_core (net/core/dev.c:5583 net/core/dev.c:5631)\n   netif_receive_skb_list_internal (net/core/dev.c:5685 net/core/dev.c:5774)\n   napi_complete_done (include/linux/list.h:37 include/net/gro.h:449 include/net/gro.h:444 net/core/dev.c:6114)\n   igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb\n   __napi_poll (net/core/dev.c:6582)\n   net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787)\n   handle_softirqs (kernel/softirq.c:553)\n   __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)\n   irq_exit_rcu (kernel/softirq.c:651)\n   common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14))\n   </IRQ>\n\nThis problem seems particularly prevalent if the user advertises an\nendpoint that has a different external vs internal address.  In the case\nwhere the external address is advertised and multiple connections\nalready exist, multiple subflow SYNs arrive in parallel which tends to\ntrigger the race during creation of the first local_addr_list entries\nwhich have the internal address instead.\n\nFix by skipping the replacement of an existing implicit local address if\ncalled via mptcp_pm_nl_get_local_id.(CVE-2025-21938)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neth: bnxt: do not update checksum in bnxt_xdp_build_skb()\n\nThe bnxt_rx_pkt() updates ip_summed value at the end if checksum offload\nis enabled.\nWhen the XDP-MB program is attached and it returns XDP_PASS, the\nbnxt_xdp_build_skb() is called to update skb_shared_info.\nThe main purpose of bnxt_xdp_build_skb() is to update skb_shared_info,\nbut it updates ip_summed value too if checksum offload is enabled.\nThis is actually duplicate work.\n\nWhen the bnxt_rx_pkt() updates ip_summed value, it checks if ip_summed\nis CHECKSUM_NONE or not.\nIt means that ip_summed should be CHECKSUM_NONE at this moment.\nBut ip_summed may already be updated to CHECKSUM_UNNECESSARY in the\nXDP-MB-PASS path.\nSo the by skb_checksum_none_assert() WARNS about it.\n\nThis is duplicate work and updating ip_summed in the\nbnxt_xdp_build_skb() is not needed.\n\nSplat looks like:\nWARNING: CPU: 3 PID: 5782 at ./include/linux/skbuff.h:5155 bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]\nModules linked in: bnxt_re bnxt_en rdma_ucm rdma_cm iw_cm ib_cm ib_uverbs veth xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_]\nCPU: 3 UID: 0 PID: 5782 Comm: socat Tainted: G        W          6.14.0-rc4+ #27\nTainted: [W]=WARN\nHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021\nRIP: 0010:bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]\nCode: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff <0f> 0b f\nRSP: 0018:ffff88881ba09928 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: 00000000c7590303 RCX: 0000000000000000\nRDX: 1ffff1104e7d1610 RSI: 0000000000000001 RDI: ffff8881c91300b8\nRBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070\nR10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080\nR13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000\nFS:  00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4: 00000000007506f0\nPKRU: 55555554\nCall Trace:\n <IRQ>\n ? __warn+0xcd/0x2f0\n ? bnxt_rx_pkt+0x479b/0x7610\n ? report_bug+0x326/0x3c0\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x14/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? bnxt_rx_pkt+0x479b/0x7610\n ? bnxt_rx_pkt+0x3e41/0x7610\n ? __pfx_bnxt_rx_pkt+0x10/0x10\n ? napi_complete_done+0x2cf/0x7d0\n __bnxt_poll_work+0x4e8/0x1220\n ? __pfx___bnxt_poll_work+0x10/0x10\n ? __pfx_mark_lock.part.0+0x10/0x10\n bnxt_poll_p5+0x36a/0xfa0\n ? __pfx_bnxt_poll_p5+0x10/0x10\n __napi_poll.constprop.0+0xa0/0x440\n net_rx_action+0x899/0xd00\n...\n\nFollowing ping.py patch adds xdp-mb-pass case. so ping.py is going\nto be able to reproduce this issue.(CVE-2025-21960)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neth: bnxt: fix truesize for mb-xdp-pass case\n\nWhen mb-xdp is set and return is XDP_PASS, packet is converted from\nxdp_buff to sk_buff with xdp_update_skb_shared_info() in\nbnxt_xdp_build_skb().\nbnxt_xdp_build_skb() passes incorrect truesize argument to\nxdp_update_skb_shared_info().\nThe truesize is calculated as BNXT_RX_PAGE_SIZE * sinfo->nr_frags but\nthe skb_shared_info was wiped by napi_build_skb() before.\nSo it stores sinfo->nr_frags before bnxt_xdp_build_skb() and use it\ninstead of getting skb_shared_info from xdp_get_shared_info_from_buff().\n\nSplat looks like:\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590\n Modules linked in: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms\n CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3\n RIP: 0010:skb_try_coalesce+0x504/0x590\n Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99\n RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287\n RAX: 0000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0\n RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 0000000000000003\n RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900\n R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740\n R13: ffffe43600000000 R14: 0000000000000002 R15: 0000000000000002\n FS:  0000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0\n PKRU: 55555554\n Call Trace:\n  <IRQ>\n  ? __warn+0x84/0x130\n  ? skb_try_coalesce+0x504/0x590\n  ? report_bug+0x18a/0x1a0\n  ? handle_bug+0x53/0x90\n  ? exc_invalid_op+0x14/0x70\n  ? asm_exc_invalid_op+0x16/0x20\n  ? skb_try_coalesce+0x504/0x590\n  inet_frag_reasm_finish+0x11f/0x2e0\n  ip_defrag+0x37a/0x900\n  ip_local_deliver+0x51/0x120\n  ip_sublist_rcv_finish+0x64/0x70\n  ip_sublist_rcv+0x179/0x210\n  ip_list_rcv+0xf9/0x130\n\nHow to reproduce:\n<Node A>\nip link set $interface1 xdp obj xdp_pass.o\nip link set $interface1 mtu 9000 up\nip a a 10.0.0.1/24 dev $interface1\n<Node B>\nip link set $interfac2 mtu 9000 up\nip a a 10.0.0.2/24 dev $interface2\nping 10.0.0.1 -s 65000\n\nFollowing ping.py patch adds xdp-mb-pass case. so ping.py is going to be\nable to reproduce this issue.(CVE-2025-21961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: handle errors in mlx5_chains_create_table()\n\nIn mlx5_chains_create_table(), the return value of mlx5_get_fdb_sub_ns()\nand mlx5_get_flow_namespace() must be checked to prevent NULL pointer\ndereferences. If either function fails, the function should log error\nmessage with mlx5_core_warn() and return error pointer.(CVE-2025-21975)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxsk: fix an integer overflow in xp_create_and_assign_umem()\n\nSince the i and pool->chunk_size variables are of type 'u32',\ntheir product can wrap around and then be cast to 'u64'.\nThis can lead to two different XDP buffers pointing to the same\nmemory area.\n\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with SVACE.(CVE-2025-21997)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: atm: fix use after free in lec_send()\n\nThe ->send() operation frees skb so save the length before calling\n->send() to avoid a use after free.(CVE-2025-22004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet:fix NPE during rx_complete\n\nMissing usbnet_going_away Check in Critical Path.\nThe usb_submit_urb function lacks a usbnet_going_away\nvalidation, whereas __usbnet_queue_skb includes this check.\n\nThis inconsistency creates a race condition where:\nA URB request may succeed, but the corresponding SKB data\nfails to be queued.\n\nSubsequent processes:\n(e.g., rx_complete → defer_bh → __skb_unlink(skb, list))\nattempt to access skb->next, triggering a NULL pointer\ndereference (Kernel Panic).(CVE-2025-22050)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ibmveth: make veth_pool_store stop hanging\n\nv2:\n- Created a single error handling unlock and exit in veth_pool_store\n- Greatly expanded commit message with previous explanatory-only text\n\nSummary: Use rtnl_mutex to synchronize veth_pool_store with itself,\nibmveth_close and ibmveth_open, preventing multiple calls in a row to\nnapi_disable.\n\nBackground: Two (or more) threads could call veth_pool_store through\nwriting to /sys/devices/vio/30000002/pool*/*. You can do this easily\nwith a little shell script. This causes a hang.\n\nI configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new\nkernel. I ran this test again and saw:\n\n    Setting pool0/active to 0\n    Setting pool1/active to 1\n    [   73.911067][ T4365] ibmveth 30000002 eth0: close starting\n    Setting pool1/active to 1\n    Setting pool1/active to 0\n    [   73.911367][ T4366] ibmveth 30000002 eth0: close starting\n    [   73.916056][ T4365] ibmveth 30000002 eth0: close complete\n    [   73.916064][ T4365] ibmveth 30000002 eth0: open starting\n    [  110.808564][  T712] systemd-journald[712]: Sent WATCHDOG=1 notification.\n    [  230.808495][  T712] systemd-journald[712]: Sent WATCHDOG=1 notification.\n    [  243.683786][  T123] INFO: task stress.sh:4365 blocked for more than 122 seconds.\n    [  243.683827][  T123]       Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8\n    [  243.683833][  T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.\n    [  243.683838][  T123] task:stress.sh       state:D stack:28096 pid:4365  tgid:4365  ppid:4364   task_flags:0x400040 flags:0x00042000\n    [  243.683852][  T123] Call Trace:\n    [  243.683857][  T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable)\n    [  243.683868][  T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0\n    [  243.683878][  T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0\n    [  243.683888][  T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210\n    [  243.683896][  T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50\n    [  243.683904][  T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0\n    [  243.683913][  T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60\n    [  243.683921][  T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc\n    [  243.683928][  T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270\n    [  243.683936][  T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0\n    [  243.683944][  T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0\n    [  243.683951][  T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650\n    [  243.683958][  T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150\n    [  243.683966][  T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340\n    [  243.683973][  T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec\n    ...\n    [  243.684087][  T123] Showing all locks held in the system:\n    [  243.684095][  T123] 1 lock held by khungtaskd/123:\n    [  243.684099][  T123]  #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248\n    [  243.684114][  T123] 4 locks held by stress.sh/4365:\n    [  243.684119][  T123]  #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150\n    [  243.684132][  T123]  #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0\n    [  243.684143][  T123]  #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0\n    [  243.684155][  T123]  #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60\n    [  243.684166][  T123] 5 locks held by stress.sh/4366:\n    [  243.684170][  T123]  #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150\n    [  243.\n---truncated---(CVE-2025-22053)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narcnet: Add NULL check in com20020pci_probe()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\ncom20020pci_probe() does not check for this case, which results in a\nNULL pointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue and ensure\nno resources are left allocated.(CVE-2025-22054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix geneve_opt length integer overflow\n\nstruct geneve_opt uses 5 bit length for each single option, which\nmeans every vary size option should be smaller than 128 bytes.\n\nHowever, all current related Netlink policies cannot promise this\nlength condition and the attacker can exploit a exact 128-byte size\noption to *fake* a zero length option and confuse the parsing logic,\nfurther achieve heap out-of-bounds read.\n\nOne example crash log is like below:\n\n[    3.905425] ==================================================================\n[    3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0\n[    3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177\n[    3.906646]\n[    3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1\n[    3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n[    3.907784] Call Trace:\n[    3.907925]  <TASK>\n[    3.908048]  dump_stack_lvl+0x44/0x5c\n[    3.908258]  print_report+0x184/0x4be\n[    3.909151]  kasan_report+0xc5/0x100\n[    3.909539]  kasan_check_range+0xf3/0x1a0\n[    3.909794]  memcpy+0x1f/0x60\n[    3.909968]  nla_put+0xa9/0xe0\n[    3.910147]  tunnel_key_dump+0x945/0xba0\n[    3.911536]  tcf_action_dump_1+0x1c1/0x340\n[    3.912436]  tcf_action_dump+0x101/0x180\n[    3.912689]  tcf_exts_dump+0x164/0x1e0\n[    3.912905]  fw_dump+0x18b/0x2d0\n[    3.913483]  tcf_fill_node+0x2ee/0x460\n[    3.914778]  tfilter_notify+0xf4/0x180\n[    3.915208]  tc_new_tfilter+0xd51/0x10d0\n[    3.918615]  rtnetlink_rcv_msg+0x4a2/0x560\n[    3.919118]  netlink_rcv_skb+0xcd/0x200\n[    3.919787]  netlink_unicast+0x395/0x530\n[    3.921032]  netlink_sendmsg+0x3d0/0x6d0\n[    3.921987]  __sock_sendmsg+0x99/0xa0\n[    3.922220]  __sys_sendto+0x1b7/0x240\n[    3.922682]  __x64_sys_sendto+0x72/0x90\n[    3.922906]  do_syscall_64+0x5e/0x90\n[    3.923814]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[    3.924122] RIP: 0033:0x7e83eab84407\n[    3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf\n[    3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c\n[    3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407\n[    3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003\n[    3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c\n[    3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0\n[    3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8\n\nFix these issues by enforing correct length condition in related\npolicies.(CVE-2025-22055)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix memory accounting leak.\n\nMatt Dowling reported a weird UDP memory usage issue.\n\nUnder normal operation, the UDP memory usage reported in /proc/net/sockstat\nremains close to zero.  However, it occasionally spiked to 524,288 pages\nand never dropped.  Moreover, the value doubled when the application was\nterminated.  Finally, it caused intermittent packet drops.\n\nWe can reproduce the issue with the script below [0]:\n\n  1. /proc/net/sockstat reports 0 pages\n\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 0\n\n  2. Run the script till the report reaches 524,288\n\n    # python3 test.py & sleep 5\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 3 mem 524288  <-- (INT_MAX + 1) >> PAGE_SHIFT\n\n  3. Kill the socket and confirm the number never drops\n\n    # pkill python3 && sleep 5\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 524288\n\n  4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()\n\n    # python3 test.py & sleep 1 && pkill python3\n\n  5. The number doubles\n\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 1048577\n\nThe application set INT_MAX to SO_RCVBUF, which triggered an integer\noverflow in udp_rmem_release().\n\nWhen a socket is close()d, udp_destruct_common() purges its receive\nqueue and sums up skb->truesize in the queue.  This total is calculated\nand stored in a local unsigned integer variable.\n\nThe total size is then passed to udp_rmem_release() to adjust memory\naccounting.  However, because the function takes a signed integer\nargument, the total size can wrap around, causing an overflow.\n\nThen, the released amount is calculated as follows:\n\n  1) Add size to sk->sk_forward_alloc.\n  2) Round down sk->sk_forward_alloc to the nearest lower multiple of\n      PAGE_SIZE and assign it to amount.\n  3) Subtract amount from sk->sk_forward_alloc.\n  4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().\n\nWhen the issue occurred, the total in udp_destruct_common() was 2147484480\n(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().\n\nAt 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and\n2) sets -2147479552 to amount.  3) reverts the wraparound, so we don't\nsee a warning in inet_sock_destruct().  However, udp_memory_allocated\nends up doubling at 4).\n\nSince commit 3cd3399dd7a8 ("net: implement per-cpu reserves for\nmemory_allocated"), memory usage no longer doubles immediately after\na socket is close()d because __sk_mem_reduce_allocated() caches the\namount in udp_memory_per_cpu_fw_alloc.  However, the next time a UDP\nsocket receives a packet, the subtraction takes effect, causing UDP\nmemory usage to double.\n\nThis issue makes further memory allocation fail once the socket's\nsk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet\ndrops.\n\nTo prevent this issue, let's use unsigned int for the calculation and\ncall sk_forward_alloc_add() only once for the small delta.\n\nNote that first_packet_length() also potentially has the same problem.\n\n[0]:\nfrom socket import *\n\nSO_RCVBUFFORCE = 33\nINT_MAX = (2 ** 31) - 1\n\ns = socket(AF_INET, SOCK_DGRAM)\ns.bind(('', 0))\ns.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)\n\nc = socket(AF_INET, SOCK_DGRAM)\nc.connect(s.getsockname())\n\ndata = b'a' * 100\n\nwhile True:\n    c.send(data)(CVE-2025-22058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: add mutual exclusion in proc_sctp_do_udp_port()\n\nWe must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start()\nor risk a crash as syzbot reported:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]\nCPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025\n RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653\nCall Trace:\n <TASK>\n  udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181\n  sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930\n  proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553\n  proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601\n  iter_file_splice_write+0x91c/0x1150 fs/splice.c:738\n  do_splice_from fs/splice.c:935 [inline]\n  direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158\n  splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102\n  do_splice_direct_actor fs/splice.c:1201 [inline]\n  do_splice_direct+0x174/0x240 fs/splice.c:1227\n  do_sendfile+0xafd/0xe50 fs/read_write.c:1368\n  __do_sys_sendfile64 fs/read_write.c:1429 [inline]\n  __se_sys_sendfile64 fs/read_write.c:1415 [inline]\n  __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline](CVE-2025-22062)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix NULL pointer dereference in l3mdev_l3_rcv\n\nWhen delete l3s ipvlan:\n\n    ip link del link eth0 ipvlan1 type ipvlan mode l3s\n\nThis may cause a null pointer dereference:\n\n    Call trace:\n     ip_rcv_finish+0x48/0xd0\n     ip_rcv+0x5c/0x100\n     __netif_receive_skb_one_core+0x64/0xb0\n     __netif_receive_skb+0x20/0x80\n     process_backlog+0xb4/0x204\n     napi_poll+0xe8/0x294\n     net_rx_action+0xd8/0x22c\n     __do_softirq+0x12c/0x354\n\nThis is because l3mdev_l3_rcv() visit dev->l3mdev_ops after\nipvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The process\nlike this:\n\n    (CPU1)                     | (CPU2)\n    l3mdev_l3_rcv()            |\n      check dev->priv_flags:   |\n        master = skb->dev;     |\n                               |\n                               | ipvlan_l3s_unregister()\n                               |   set dev->priv_flags\n                               |   dev->l3mdev_ops = NULL;\n                               |\n      visit master->l3mdev_ops |\n\nTo avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.(CVE-2025-22103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.\n\nSIOCBRDELIF is passed to dev_ioctl() first and later forwarded to\nbr_ioctl_call(), which causes unnecessary RTNL dance and the splat\nbelow [0] under RTNL pressure.\n\nLet's say Thread A is trying to detach a device from a bridge and\nThread B is trying to remove the bridge.\n\nIn dev_ioctl(), Thread A bumps the bridge device's refcnt by\nnetdev_hold() and releases RTNL because the following br_ioctl_call()\nalso re-acquires RTNL.\n\nIn the race window, Thread B could acquire RTNL and try to remove\nthe bridge device.  Then, rtnl_unlock() by Thread B will release RTNL\nand wait for netdev_put() by Thread A.\n\nThread A, however, must hold RTNL after the unlock in dev_ifsioc(),\nwhich may take long under RTNL pressure, resulting in the splat by\nThread B.\n\n  Thread A (SIOCBRDELIF)           Thread B (SIOCBRDELBR)\n  ----------------------           ----------------------\n  sock_ioctl                       sock_ioctl\n  `- sock_do_ioctl                 `- br_ioctl_call\n     `- dev_ioctl                     `- br_ioctl_stub\n        |- rtnl_lock                     |\n        |- dev_ifsioc                    '\n        '  |- dev = __dev_get_by_name(...)\n           |- netdev_hold(dev, ...)      .\n       /   |- rtnl_unlock  ------.       |\n       |   |- br_ioctl_call       `--->  |- rtnl_lock\n  Race |   |  `- br_ioctl_stub           |- br_del_bridge\n  Window   |     |                       |  |- dev = __dev_get_by_name(...)\n       |   |     |  May take long        |  `- br_dev_delete(dev, ...)\n       |   |     |  under RTNL pressure  |     `- unregister_netdevice_queue(dev, ...)\n       |   |     |               |       `- rtnl_unlock\n       \\   |     |- rtnl_lock  <-'          `- netdev_run_todo\n           |     |- ...                        `- netdev_run_todo\n           |     `- rtnl_unlock                   |- __rtnl_unlock\n           |                                      |- netdev_wait_allrefs_any\n           |- netdev_put(dev, ...)  <----------------'\n                                                Wait refcnt decrement\n                                                and log splat below\n\nTo avoid blocking SIOCBRDELBR unnecessarily, let's not call\ndev_ioctl() for SIOCBRADDIF and SIOCBRDELIF.\n\nIn the dev_ioctl() path, we do the following:\n\n  1. Copy struct ifreq by get_user_ifreq in sock_do_ioctl()\n  2. Check CAP_NET_ADMIN in dev_ioctl()\n  3. Call dev_load() in dev_ioctl()\n  4. Fetch the master dev from ifr.ifr_name in dev_ifsioc()\n\n3. can be done by request_module() in br_ioctl_call(), so we move\n1., 2., and 4. to br_ioctl_stub().\n\nNote that 2. is also checked later in add_del_if(), but it's better\nperformed before RTNL.\n\nSIOCBRADDIF and SIOCBRDELIF have been processed in dev_ioctl() since\nthe pre-git era, and there seems to be no specific reason to process\nthem there.\n\n[0]:\nunregister_netdevice: waiting for wpan3 to become free. Usage count = 2\nref_tracker: wpan3@ffff8880662d8608 has 1/1 users at\n     __netdev_tracker_alloc include/linux/netdevice.h:4282 [inline]\n     netdev_hold include/linux/netdevice.h:4311 [inline]\n     dev_ifsioc+0xc6a/0x1160 net/core/dev_ioctl.c:624\n     dev_ioctl+0x255/0x10c0 net/core/dev_ioctl.c:826\n     sock_do_ioctl+0x1ca/0x260 net/socket.c:1213\n     sock_ioctl+0x23a/0x6c0 net/socket.c:1318\n     vfs_ioctl fs/ioctl.c:51 [inline]\n     __do_sys_ioctl fs/ioctl.c:906 [inline]\n     __se_sys_ioctl fs/ioctl.c:892 [inline]\n     __x64_sys_ioctl+0x1a4/0x210 fs/ioctl.c:892\n     do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n     do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-22111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: detect and prevent references to a freed transport in sendmsg\n\nsctp_sendmsg() re-uses associations and transports when possible by\ndoing a lookup based on the socket endpoint and the message destination\naddress, and then sctp_sendmsg_to_asoc() sets the selected transport in\nall the message chunks to be sent.\n\nThere's a possible race condition if another thread triggers the removal\nof that selected transport, for instance, by explicitly unbinding an\naddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have\nbeen set up and before the message is sent. This can happen if the send\nbuffer is full, during the period when the sender thread temporarily\nreleases the socket lock in sctp_wait_for_sndbuf().\n\nThis causes the access to the transport data in\nsctp_outq_select_transport(), when the association outqueue is flushed,\nto result in a use-after-free read.\n\nThis change avoids this scenario by having sctp_transport_free() signal\nthe freeing of the transport, tagging it as "dead". In order to do this,\nthe patch restores the "dead" bit in struct sctp_transport, which was\nremoved in\ncommit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").\n\nThen, in the scenario where the sender thread has released the socket\nlock in sctp_wait_for_sndbuf(), the bit is checked again after\nre-acquiring the socket lock to detect the deletion. This is done while\nholding a reference to the transport to prevent it from being freed in\nthe process.\n\nIf the transport was deleted while the socket lock was relinquished,\nsctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the\nsend.\n\nThe bug was found by a private syzbot instance (see the error report [1]\nand the C reproducer that triggers it [2]).(CVE-2025-23142)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: Fix accessing freed irq affinity_hint\n\nThe cpumask should not be a local variable, since its pointer is saved\nto irq_desc and may be accessed from procfs.\nTo fix it, use the persistent mask cpumask_of(cpu#).(CVE-2025-23155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix memory leak in tipc_link_xmit\n\nIn case the backlog transmit queue for system-importance messages is overloaded,\ntipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads to\nmemory leak and failure when a skb is allocated.\n\nThis commit fixes this issue by purging the skb list before tipc_link_xmit()\nreturns.(CVE-2025-37757)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: free routing table on probe failure\n\nIf complete = true in dsa_tree_setup(), it means that we are the last\nswitch of the tree which is successfully probing, and we should be\nsetting up all switches from our probe path.\n\nAfter "complete" becomes true, dsa_tree_setup_cpu_ports() or any\nsubsequent function may fail. If that happens, the entire tree setup is\nin limbo: the first N-1 switches have successfully finished probing\n(doing nothing but having allocated persistent memory in the tree's\ndst->ports, and maybe dst->rtable), and switch N failed to probe, ending\nthe tree setup process before anything is tangible from the user's PoV.\n\nIf switch N fails to probe, its memory (ports) will be freed and removed\nfrom dst->ports. However, the dst->rtable elements pointing to its ports,\nas created by dsa_link_touch(), will remain there, and will lead to\nuse-after-free if dereferenced.\n\nIf dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirely\npossible because that is where ds->ops->setup() is, we get a kasan\nreport like this:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568\nRead of size 8 at addr ffff000004f56020 by task kworker/u8:3/42\n\nCall trace:\n __asan_report_load8_noabort+0x20/0x30\n mv88e6xxx_setup_upstream_port+0x240/0x568\n mv88e6xxx_setup+0xebc/0x1eb0\n dsa_register_switch+0x1af4/0x2ae0\n mv88e6xxx_register_switch+0x1b8/0x2a8\n mv88e6xxx_probe+0xc4c/0xf60\n mdio_probe+0x78/0xb8\n really_probe+0x2b8/0x5a8\n __driver_probe_device+0x164/0x298\n driver_probe_device+0x78/0x258\n __device_attach_driver+0x274/0x350\n\nAllocated by task 42:\n __kasan_kmalloc+0x84/0xa0\n __kmalloc_cache_noprof+0x298/0x490\n dsa_switch_touch_ports+0x174/0x3d8\n dsa_register_switch+0x800/0x2ae0\n mv88e6xxx_register_switch+0x1b8/0x2a8\n mv88e6xxx_probe+0xc4c/0xf60\n mdio_probe+0x78/0xb8\n really_probe+0x2b8/0x5a8\n __driver_probe_device+0x164/0x298\n driver_probe_device+0x78/0x258\n __device_attach_driver+0x274/0x350\n\nFreed by task 42:\n __kasan_slab_free+0x48/0x68\n kfree+0x138/0x418\n dsa_register_switch+0x2694/0x2ae0\n mv88e6xxx_register_switch+0x1b8/0x2a8\n mv88e6xxx_probe+0xc4c/0xf60\n mdio_probe+0x78/0xb8\n really_probe+0x2b8/0x5a8\n __driver_probe_device+0x164/0x298\n driver_probe_device+0x78/0x258\n __device_attach_driver+0x274/0x350\n\nThe simplest way to fix the bug is to delete the routing table in its\nentirety. dsa_tree_setup_routing_table() has no problem in regenerating\nit even if we deleted links between ports other than those of switch N,\nbecause dsa_link_touch() first checks whether the port pair already\nexists in dst->rtable, allocating if not.\n\nThe deletion of the routing table in its entirety already exists in\ndsa_tree_teardown(), so refactor that into a function that can also be\ncalled from the tree setup error path.\n\nIn my analysis of the commit to blame, it is the one which added\ndsa_link elements to dst->rtable. Prior to that, each switch had its own\nds->rtable which is freed when the switch fails to probe. But the tree\nis potentially persistent memory.(CVE-2025-37786)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registered\n\nRussell King reports that a system with mv88e6xxx dereferences a NULL\npointer when unbinding this driver:\nhttps://lore.kernel.org/netdev/(CVE-2025-37787)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncxgb4: fix memory leak in cxgb4_init_ethtool_filters() error path\n\nIn the for loop used to allocate the loc_array and bmap for each port, a\nmemory leak is possible when the allocation for loc_array succeeds,\nbut the allocation for bmap fails. This is because when the control flow\ngoes to the label free_eth_finfo, only the allocations starting from\n(i-1)th iteration are freed.\n\nFix that by freeing the loc_array in the bmap allocation error path.(CVE-2025-37788)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: mctp: Set SOCK_RCU_FREE\n\nBind lookup runs under RCU, so ensure that a socket doesn't go away in\nthe middle of a lookup.(CVE-2025-37790)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class handling\n\nThis patch fixes a Use-After-Free vulnerability in the HFSC qdisc class\nhandling. The issue occurs due to a time-of-check/time-of-use condition\nin hfsc_change_class() when working with certain child qdiscs like netem\nor codel.\n\nThe vulnerability works as follows:\n1. hfsc_change_class() checks if a class has packets (q.qlen != 0)\n2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,\n   codel, netem) might drop packets and empty the queue\n3. The code continues assuming the queue is still non-empty, adding\n   the class to vttree\n4. This breaks HFSC scheduler assumptions that only non-empty classes\n   are in vttree\n5. Later, when the class is destroyed, this can lead to a Use-After-Free\n\nThe fix adds a second queue length check after qdisc_peek_len() to verify\nthe queue wasn't emptied.(CVE-2025-37797)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmcb: fix a double free bug in chameleon_parse_gdd()\n\nIn chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev'\nwould be released in mcb_device_register() via put_device().\nThus, goto 'err' label and free 'mdev' again causes a double free.\nJust return if mcb_device_register() fails.(CVE-2025-37817)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen-netfront: handle NULL returned by xdp_convert_buff_to_frame()\n\nThe function xdp_convert_buff_to_frame() may return NULL if it fails\nto correctly convert the XDP buffer into an XDP frame due to memory\nconstraints, internal errors, or invalid data. Failing to check for NULL\nmay lead to a NULL pointer dereference if the result is used later in\nprocessing, potentially causing crashes, data corruption, or undefined\nbehavior.\n\nOn XDP redirect failure, the associated page must be released explicitly\nif it was previously retained via get_page(). Failing to do so may result\nin a memory leak, as the pages reference count is not decremented.(CVE-2025-37820)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too\n\nSimilarly to the previous patch, we need to safe guard hfsc_dequeue()\ntoo. But for this one, we don't have a reliable reproducer.(CVE-2025-37823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix NULL pointer dereference in tipc_mon_reinit_self()\n\nsyzbot reported:\n\ntipc: Node number set to 1055423674\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nWorkqueue: events tipc_net_finalize_work\nRIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719\n...\nRSP: 0018:ffffc9000356fb68 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba\nRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010\nRBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007\nR13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010\nFS:  0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140\n process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238\n process_scheduled_works kernel/workqueue.c:3319 [inline]\n worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400\n kthread+0x3c2/0x780 kernel/kthread.c:464\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n </TASK>\n...\nRIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719\n...\nRSP: 0018:ffffc9000356fb68 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba\nRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010\nRBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007\nR13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010\nFS:  0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n\nThere is a racing condition between workqueue created when enabling\nbearer and another thread created when disabling bearer right after\nthat as follow:\n\nenabling_bearer                          | disabling_bearer\n---------------                          | ----------------\ntipc_disc_timeout()                      |\n{                                        | bearer_disable()\n ...                                     | {\n schedule_work(&tn->work);               |  tipc_mon_delete()\n ...                                     |  {\n}                                        |   ...\n                                         |   write_lock_bh(&mon->lock);\n                                         |   mon->self = NULL;\n                                         |   write_unlock_bh(&mon->lock);\n                                         |   ...\n                                         |  }\ntipc_net_finalize_work()                 | }\n{                                        |\n ...                                     |\n tipc_net_finalize()                     |\n {                                       |\n  ...                                    |\n  tipc_mon_reinit_self()                 |\n  {                                      |\n   ...                                   |\n   write_lock_bh(&mon->lock);            |\n   mon->self->addr = tipc_own_addr(net); |\n   write_unlock_bh(&mon->lock);          |\n   ...             \n---truncated---(CVE-2025-37824)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: clean up FDB, MDB, VLAN entries on unbind\n\nAs explained in many places such as commit b117e1e8a86d ("net: dsa:\ndelete dsa_legacy_fdb_add and dsa_legacy_fdb_del"), DSA is written given\nthe assumption that higher layers have balanced additions/deletions.\nAs such, it only makes sense to be extremely vocal when those\nassumptions are violated and the driver unbinds with entries still\npresent.\n\nBut Ido Schimmel points out a very simple situation where that is wrong:\nhttps://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/\n(also briefly discussed by me in the aforementioned commit).\n\nBasically, while the bridge bypass operations are not something that DSA\nexplicitly documents, and for the majority of DSA drivers this API\nsimply causes them to go to promiscuous mode, that isn't the case for\nall drivers. Some have the necessary requirements for bridge bypass\noperations to do something useful - see dsa_switch_supports_uc_filtering().\n\nAlthough in tools/testing/selftests/net/forwarding/local_termination.sh,\nwe made an effort to popularize better mechanisms to manage address\nfilters on DSA interfaces from user space - namely macvlan for unicast,\nand setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the\nfact is that 'bridge fdb add ... self static local' also exists as\nkernel UAPI, and might be useful to someone, even if only for a quick\nhack.\n\nIt seems counter-productive to block that path by implementing shim\n.ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP\nin order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from\nrunning, although we could do that.\n\nAccepting that cleanup is necessary seems to be the only option.\nEspecially since we appear to be coming back at this from a different\nangle as well. Russell King is noticing that the WARN_ON() triggers even\nfor VLANs:\nhttps://lore.kernel.org/netdev/(CVE-2025-37864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: mv88e6xxx: fix -ENOENT when deleting VLANs and MST is unsupported\n\nRussell King reports that on the ZII dev rev B, deleting a bridge VLAN\nfrom a user port fails with -ENOENT:\nhttps://lore.kernel.org/netdev/(CVE-2025-37865)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: pktgen: fix access outside of user given buffer in pktgen_thread_write()\n\nHonour the user given buffer size for the strn_len() calls (otherwise\nstrn_len() will access memory outside of the user given buffer).(CVE-2025-38061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix timeout on deleted connection\n\nNOPIN response timer may expire on a deleted connection and crash with\nsuch logs:\n\nDid not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d\n\nBUG: Kernel NULL pointer dereference on read at 0x00000000\nNIP  strlcpy+0x8/0xb0\nLR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod]\nCall Trace:\n iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod]\n call_timer_fn+0x58/0x1f0\n run_timer_softirq+0x740/0x860\n __do_softirq+0x16c/0x420\n irq_exit+0x188/0x1c0\n timer_interrupt+0x184/0x410\n\nThat is because nopin response timer may be re-started on nopin timer\nexpiration.\n\nStop nopin timer before stopping the nopin response timer to be sure\nthat no one of them will be re-started.(CVE-2025-38075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: algif_hash - fix double free in hash_accept\n\nIf accept(2) is called on socket type algif_hash with\nMSG_MORE flag set and crypto_ahash_import fails,\nsk2 is freed. However, it is also freed in af_alg_release,\nleading to slab-use-after-free error.(CVE-2025-38079)\n\nA vulnerability was found in Linux Kernel (Operating System) and classified as problematic.The manipulation of the argument bNumDescriptors with an unknown input leads to a unknown weakness. Using CWE to declare the problem leads to CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.Impacted is confidentiality.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 7a6d6b68db128da2078ccd9a751dfa3f75c9cf5b/41827a2dbdd7880df9881506dee13bc88d4230bb/1df80d748f984290c895e843401824215dcfbfb0/a8f842534807985d3a676006d140541b87044345/4fa7831cf0ac71a0a345369d1a6084f2b096e55e/74388368927e9c52a69524af5bbd6c55eb4690de/485e1b741eb838cbe1d6b0e81e5ab62ae6c095cf/fe7f7ac8e0c708446ff017453add769ffc15deed is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38103)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38115)\n\nA vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.93/6.12.33/6.15.2/6.16-rc1 (Operating System).Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch bdd56875c6926d8009914f427df71797693e90d4/4e83f2dbb2bf677e614109df24426c4dded472d4/d7882db79135c829a922daf3571f33ea1e056ae3/6fe26f694c824b8a4dbf50c635bee1302e3f099c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38117)\n\nA vulnerability, which was classified as problematic, was found in Linux Kernel up to 8058c88ac0df21239daee54b5934d5c80ca9685f (Operating System).CWE is classifying the issue as CWE-401. The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.This is going to have an impact on confidentiality.Upgrading to version 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch b5ad58285f9217d68cd5ea2ad86ce254a3fe7c4d/90bc7f5a244aadee4292b28098b7c98aadd4b3aa/39bab2d3517b5b50c609b4f8c66129bf619fffa0/251496ce1728c9fd47bd2b20a7b21b20b9a020ca/8068e1e42b46518ce680dc6470bcd710efc3fa0a/ea77c397bff8b6d59f6d83dae1425b08f465e8b5 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38120)\n\nA vulnerability classified as problematic has been found in Linux Kernel (Operating System).This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 0e65f38bd1aa14ea86e221b7bb814d38278d86c3/85eef1748c024da1a191aed56b30a3a65958c50c/4399f59a9467a324ed46657555f0e1f209a14acb/a04302867094bdc6efac1b598370fc47cf3f2388/3382a1ed7f778db841063f5d7e317ac55f9e7f72 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38124)\n\nA vulnerability, which was classified as problematic, has been found in Linux Kernel up to 6.6.93/6.12.33/6.15.2 (Operating System).Using CWE to declare the problem leads to CWE-371.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 1d3c5d0dec6797eca3a861dab0816fa9505d9c3e/276849954d7cbe6eec827b21fe2df43f9bf07011/0e061abaad1498c5b76c10c594d4359ceb6b9145/0153f36041b8e52019ebfa8629c13bf8f9b0a951 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38127)\n\nA vulnerability has been found in Linux Kernel up to 6.15.2 (Operating System) and classified as problematic.The CWE definition for the vulnerability is CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch e5ce9df1d68094d37360dbd9b09289d42fa21e54/7ee3fb6258da8c890a51b514f60d7570dc703605/40471b23147c86ea3ed97faee79937c618250bd0/5482ef9875eaa43f0435e14570e1193823de857e/ee5ee646385f5846dcbc881389f3c44a197c402a/5a85c21f812e02cb00ca07007d88acdd42d08c46/ac4e317a95a1092b5da5b9918b7118759342641c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19787).(CVE-2025-38157)\n\nA vulnerability classified as problematic was found in Linux Kernel up to 6.15.3 (Operating System).As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch d9a55869d8237e677ddaa18b0f58586364cfbc1c/1f6332872374b7f482fc4ad865f9422fedb587fc/fbfe8446cd3274b9e367f5708d94574230a44409/5018d035530b6fbfad33eeb1dd1bc87da419a276/a87cbcc909ccfd394d4936a94663f586453d0961/aaa644e7ffff02e12c89cbce4753bc0b6f23ff87/d14cbed4baccd712447fb3f9c011f008b56b2097/42cb74a92adaf88061039601ddf7c874f58b554e is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20037).(CVE-2025-38219)\n\nA vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3 (Operating System).Using CWE to declare the problem leads to CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.Impacted is availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch cf6a4c4ac7b6e3214f25df594c9689a62f1bb456/be5f3061a6f904e3674257879e71881ceee5b673/d7af6eee8cd60f55aa8c5fe2b91f11ec0c9a0f27/e26268ff1dcae5662c1b96c35f18cfa6ab73d9de is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20036).(CVE-2025-38220)\n\nLinux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States.\n There is a security vulnerability in Linux kernel. This vulnerability originates from improper processing of composing size in vivid drivers, which may lead to over-bounds writing.(CVE-2025-38226)\n\nA vulnerability, which was classified as problematic, was found in Linux Kernel up to 32700ecf8007e071d1ce4c78f65b85f46d05f32a (Operating System).The manipulation of the argument adxl_component_count with an unknown input leads to a unknown weakness. CWE is classifying the issue as CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.This is going to have an impact on confidentiality.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 80bf28fd623d97dd4f4825fbbe9d736cec2afba3/a6ed3a6edff09c1187cc6ade7f5967bca2376a13/bf6a8502a5f4ff6e4d135d795945cdade49ec8b0/e8530ed3c0769a4d8f79c212715ec1cf277787f8/3f5d0659000923735350da60ad710f8c804544fe/a13e8343ffcff27af1ff79597ff7ba241e6d9471/31ef6f7c9aee3be78d63789653e92350f2537f93/20d2d476b3ae18041be423671a8637ed5ffd6958 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38298)\n\nA vulnerability classified as critical was found in Linux Kernel up to 6.15.3 (Operating System).The CWE definition for the vulnerability is CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.As an impact it is known to affect availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch 5c1a34ff5b0bfdfd2f9343aa9b08d25df618bac5/ec669e5bf409f16e464bfad75f0ba039a45de29a/43d5e3bb5f1dcd91e30238ea0b59a5f77063f84e/23361b479f2700c00960d3ae9cdc8ededa762d47/2e7c64d7a92c031d016f11c8e8cb05131ab7b75a/f78b38af3540b4875147b7b884ee11a27b3dbf4c/a377996d714afb8d4d5f4906336f78510039da29/af98b0157adf6504fade79b3e6cb260c4ff68e37 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38337)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-102.0.0.105.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","kernel-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","perf-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-102.0.0.105.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-102.0.0.105.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","kernel-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","perf-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-102.0.0.105.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1879"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58237"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21703"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21829"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21894"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21904"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21920"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21926"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21938"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21960"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21961"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21975"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21997"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22004"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22050"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22053"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22054"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22055"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22058"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22062"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22103"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22111"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23142"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-23155"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37757"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37786"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37787"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37788"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37790"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37797"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37817"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37820"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37823"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37824"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37864"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37865"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38061"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38075"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38079"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38103"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38115"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38117"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38120"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38124"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38127"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38157"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38219"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38220"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38226"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38298"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38337"}],"database_specific":{"severity":"High"}}