{"id":"OESA-2025-2122","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\ngtp: Destroy device along with udp socket's netns dismantle.\n\ngtp_newlink() links the device to a list in dev_net(dev) instead of\nsrc_net, where a udp tunnel socket is created.\n\nEven when src_net is removed, the device stays alive on dev_net(dev).\nThen, removing src_net triggers the splat below. [0]\n\nIn this example, gtp0 is created in ns2, and the udp socket is created\nin ns1.\n\n  ip netns add ns1\n  ip netns add ns2\n  ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn\n  ip netns del ns1\n\nLet's link the device to the socket's netns instead.\n\nNow, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove\nall gtp devices in the netns.\n\n[0]:\nref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at\n     sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)\n     inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)\n     __sock_create (net/socket.c:1558)\n     udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)\n     gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423)\n     gtp_create_sockets (drivers/net/gtp.c:1447)\n     gtp_newlink (drivers/net/gtp.c:1507)\n     rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)\n     rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)\n     netlink_rcv_skb (net/netlink/af_netlink.c:2542)\n     netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)\n     netlink_sendmsg (net/netlink/af_netlink.c:1891)\n     ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)\n     ___sys_sendmsg (net/socket.c:2639)\n     __sys_sendmsg (net/socket.c:2669)\n     do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\n\nWARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)\nModules linked in:\nCPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: netns cleanup_net\nRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)\nCode: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89\nRSP: 0018:ff11000009a07b60 EFLAGS: 00010286\nRAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c\nRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae\nR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0\nR13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000\nFS:  0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n <TASK>\n ? __warn (kernel/panic.c:748)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? report_bug (lib/bug.c:201 lib/bug.c:219)\n ? handle_bug (arch/x86/kernel/traps.c:285)\n ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))\n ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158)\n ? kfree (mm/slub.c:4613 mm/slub.c:4761)\n net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467)\n cleanup_net (net/core/net_namespace.c:664 (discriminator 3))\n process_one_work (kernel/workqueue.c:3229)\n worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391\n---truncated---(CVE-2025-21678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpi3mr: Fix possible crash when setting up bsg fails\n\nIf bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value.\nConsequently, in mpi3mr_bsg_exit(), the condition "if(!mrioc->bsg_queue)"\nwill not be satisfied, preventing execution from entering\nbsg_remove_queue(), which could lead to the following crash:\n\nBUG: kernel NULL pointer dereference, address: 000000000000041c\nCall Trace:\n  <TASK>\n  mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr]\n  mpi3mr_remove+0x6f/0x340 [mpi3mr]\n  pci_device_remove+0x3f/0xb0\n  device_release_driver_internal+0x19d/0x220\n  unbind_store+0xa4/0xb0\n  kernfs_fop_write_iter+0x11f/0x200\n  vfs_write+0x1fc/0x3e0\n  ksys_write+0x67/0xe0\n  do_syscall_64+0x38/0x80\n  entry_SYSCALL_64_after_hwframe+0x78/0xe2(CVE-2025-21723)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: drop secpath at the same time as we currently drop dst\n\nXiumei reported hitting the WARN in xfrm6_tunnel_net_exit while\nrunning tests that boil down to:\n - create a pair of netns\n - run a basic TCP test over ipcomp6\n - delete the pair of netns\n\nThe xfrm_state found on spi_byaddr was not deleted at the time we\ndelete the netns, because we still have a reference on it. This\nlingering reference comes from a secpath (which holds a ref on the\nxfrm_state), which is still attached to an skb. This skb is not\nleaked, it ends up on sk_receive_queue and then gets defer-free'd by\nskb_attempt_defer_free.\n\nThe problem happens when we defer freeing an skb (push it on one CPU's\ndefer_list), and don't flush that list before the netns is deleted. In\nthat case, we still have a reference on the xfrm_state that we don't\nexpect at this point.\n\nWe already drop the skb's dst in the TCP receive path when it's no\nlonger needed, so let's also drop the secpath. At this point,\ntcp_filter has already called into the LSM hooks that may require the\nsecpath, so it should not be needed anymore. However, in some of those\nplaces, the MPTCP extension has just been attached to the skb, so we\ncannot simply drop all extensions.(CVE-2025-21864)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: prevent connection release during oplock break notification\n\nksmbd_work could be freed when after connection release.\nIncrement r_count of ksmbd_conn to indicate that requests\nare not finished yet and to not release the connection.(CVE-2025-21955)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix error code in chan_alloc_skb_cb()\n\nThe chan_alloc_skb_cb() function is supposed to return error pointers on\nerror.  Returning NULL will lead to a NULL dereference.(CVE-2025-22007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: socket: Lookup orig tuple for IPv6 SNAT\n\nnf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to\nrestore the original 5-tuple in case of SNAT, to be able to find the\nright socket (if any). Then socket_match() can correctly check whether\nthe socket was transparent.\n\nHowever, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this\nconntrack lookup, making xt_socket fail to match on the socket when the\npacket was SNATed. Add the same logic to nf_sk_lookup_slow_v6.\n\nIPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as\npods' addresses are in the fd00::/8 ULA subnet and need to be replaced\nwith the node's external address. Cilium leverages Envoy to enforce L7\npolicies, and Envoy uses transparent sockets. Cilium inserts an iptables\nprerouting rule that matches on `-m socket --transparent` and redirects\nthe packets to localhost, but it fails to match SNATed IPv6 packets due\nto that missing conntrack lookup.(CVE-2025-22021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_tunnel: fix geneve_opt type confusion addition\n\nWhen handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the\nparsing logic should place every geneve_opt structure one by one\ncompactly. Hence, when deciding the next geneve_opt position, the\npointer addition should be in units of char *.\n\nHowever, the current implementation erroneously does type conversion\nbefore the addition, which will lead to heap out-of-bounds write.\n\n[    6.989857] ==================================================================\n[    6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70\n[    6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178\n[    6.991162]\n[    6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1\n[    6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n[    6.992281] Call Trace:\n[    6.992423]  <TASK>\n[    6.992586]  dump_stack_lvl+0x44/0x5c\n[    6.992801]  print_report+0x184/0x4be\n[    6.993790]  kasan_report+0xc5/0x100\n[    6.994252]  kasan_check_range+0xf3/0x1a0\n[    6.994486]  memcpy+0x38/0x60\n[    6.994692]  nft_tunnel_obj_init+0x977/0xa70\n[    6.995677]  nft_obj_init+0x10c/0x1b0\n[    6.995891]  nf_tables_newobj+0x585/0x950\n[    6.996922]  nfnetlink_rcv_batch+0xdf9/0x1020\n[    6.998997]  nfnetlink_rcv+0x1df/0x220\n[    6.999537]  netlink_unicast+0x395/0x530\n[    7.000771]  netlink_sendmsg+0x3d0/0x6d0\n[    7.001462]  __sock_sendmsg+0x99/0xa0\n[    7.001707]  ____sys_sendmsg+0x409/0x450\n[    7.002391]  ___sys_sendmsg+0xfd/0x170\n[    7.003145]  __sys_sendmsg+0xea/0x170\n[    7.004359]  do_syscall_64+0x5e/0x90\n[    7.005817]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[    7.006127] RIP: 0033:0x7ec756d4e407\n[    7.006339] 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[    7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n[    7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407\n[    7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003\n[    7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000\n[    7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\n[    7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8\n\nFix this bug with correct pointer addition and conversion in parse\nand dump code.(CVE-2025-22056)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: decrease cached dst counters in dst_release\n\nUpstream fix ac888d58869b ("net: do not delay dst_entries_add() in\ndst_release()") moved decrementing the dst count from dst_destroy to\ndst_release to avoid accessing already freed data in case of netns\ndismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels\nare used, this fix is incomplete as the same issue will be seen for\ncached dsts:\n\n  Unable to handle kernel paging request at virtual address ffff5aabf6b5c000\n  Call trace:\n   percpu_counter_add_batch+0x3c/0x160 (P)\n   dst_release+0xec/0x108\n   dst_cache_destroy+0x68/0xd8\n   dst_destroy+0x13c/0x168\n   dst_destroy_rcu+0x1c/0xb0\n   rcu_do_batch+0x18c/0x7d0\n   rcu_core+0x174/0x378\n   rcu_core_si+0x18/0x30\n\nFix this by invalidating the cache, and thus decrementing cached dst\ncounters, in dst_release too.(CVE-2025-22057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets\n\nWhen calling netlbl_conn_setattr(), addr->sa_family is used\nto determine the function behavior. If sk is an IPv4 socket,\nbut the connect function is called with an IPv6 address,\nthe function calipso_sock_setattr() is triggered.\nInside this function, the following code is executed:\n\nsk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;\n\nSince sk is an IPv4 socket, pinet6 is NULL, leading to a\nnull pointer dereference.\n\nThis patch fixes the issue by checking if inet6_sk(sk)\nreturns a NULL pointer before accessing pinet6.(CVE-2025-22063)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: don't unregister hook when table is dormant\n\nWhen nf_tables_updchain encounters an error, hook registration needs to\nbe rolled back.\n\nThis should only be done if the hook has been registered, which won't\nhappen when the table is flagged as dormant (inactive).\n\nJust move the assignment into the registration block.(CVE-2025-22064)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix mlx5_poll_one() cur_qp update flow\n\nWhen cur_qp isn't NULL, in order to avoid fetching the QP from\nthe radix tree again we check if the next cqe QP is identical to\nthe one we already have.\n\nThe bug however is that we are checking if the QP is identical by\nchecking the QP number inside the CQE against the QP number inside the\nmlx5_ib_qp, but that's wrong since the QP number from the CQE is from\nFW so it should be matched against mlx5_core_qp which is our FW QP\nnumber.\n\nOtherwise we could use the wrong QP when handling a CQE which could\ncause the kernel trace below.\n\nThis issue is mainly noticeable over QPs 0 & 1, since for now they are\nthe only QPs in our driver whereas the QP number inside mlx5_ib_qp\ndoesn't match the QP number inside mlx5_core_qp.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]\n RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21\n RSP: 0018:ffff88810511bd60 EFLAGS: 00010046\n RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a\n RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10\n R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000\n R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0\n FS:  0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0\n Call Trace:\n  <TASK>\n  ? __die+0x20/0x60\n  ? page_fault_oops+0x150/0x3e0\n  ? exc_page_fault+0x74/0x130\n  ? asm_exc_page_fault+0x22/0x30\n  ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib]\n  __ib_process_cq+0x5a/0x150 [ib_core]\n  ib_cq_poll_work+0x31/0x90 [ib_core]\n  process_one_work+0x169/0x320\n  worker_thread+0x288/0x3a0\n  ? work_busy+0xb0/0xb0\n  kthread+0xd7/0x1f0\n  ? kthreads_online_cpu+0x130/0x130\n  ? kthreads_online_cpu+0x130/0x130\n  ret_from_fork+0x2d/0x50\n  ? kthreads_online_cpu+0x130/0x130\n  ret_from_fork_asm+0x11/0x20\n  </TASK>(CVE-2025-22086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Don't expose hw_counters outside of init net namespace\n\nCommit 467f432a521a ("RDMA/core: Split port and device counter sysfs\nattributes") accidentally almost exposed hw counters to non-init net\nnamespaces. It didn't expose them fully, as an attempt to read any of\nthose counters leads to a crash like this one:\n\n[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028\n[42021.814463] #PF: supervisor read access in kernel mode\n[42021.819549] #PF: error_code(0x0000) - not-present page\n[42021.824636] PGD 0 P4D 0\n[42021.827145] Oops: 0000 [#1] SMP PTI\n[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S      W I        XXX\n[42021.841697] Hardware name: XXX\n[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core]\n[42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48\n[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287\n[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000\n[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0\n[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000\n[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530\n[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000\n[42021.914418] FS:  00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000\n[42021.922423] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0\n[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[42021.949324] Call Trace:\n[42021.951756]  <TASK>\n[42021.953842]  [<ffffffff86c58674>] ? show_regs+0x64/0x70\n[42021.959030]  [<ffffffff86c58468>] ? __die+0x78/0xc0\n[42021.963874]  [<ffffffff86c9ef75>] ? page_fault_oops+0x2b5/0x3b0\n[42021.969749]  [<ffffffff87674b92>] ? exc_page_fault+0x1a2/0x3c0\n[42021.975549]  [<ffffffff87801326>] ? asm_exc_page_fault+0x26/0x30\n[42021.981517]  [<ffffffffc0775680>] ? __pfx_show_hw_stats+0x10/0x10 [ib_core]\n[42021.988482]  [<ffffffffc077564e>] ? hw_stat_device_show+0x1e/0x40 [ib_core]\n[42021.995438]  [<ffffffff86ac7f8e>] dev_attr_show+0x1e/0x50\n[42022.000803]  [<ffffffff86a3eeb1>] sysfs_kf_seq_show+0x81/0xe0\n[42022.006508]  [<ffffffff86a11134>] seq_read_iter+0xf4/0x410\n[42022.011954]  [<ffffffff869f4b2e>] vfs_read+0x16e/0x2f0\n[42022.017058]  [<ffffffff869f50ee>] ksys_read+0x6e/0xe0\n[42022.022073]  [<ffffffff8766f1ca>] do_syscall_64+0x6a/0xa0\n[42022.027441]  [<ffffffff8780013b>] entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe problem can be reproduced using the following steps:\n  ip netns add foo\n  ip netns exec foo bash\n  cat /sys/class/infiniband/mlx4_0/hw_counters/*\n\nThe panic occurs because of casting the device pointer into an\nib_device pointer using container_of() in hw_stat_device_show() is\nwrong and leads to a memory corruption.\n\nHowever the real problem is that hw counters should never been exposed\noutside of the non-init net namespace.\n\nFix this by saving the index of the corresponding attribute group\n(it might be 1 or 2 depending on the presence of driver-specific\nattributes) and zeroing the pointer to hw_counters group for compat\ndevices during the initialization.\n\nWith this fix applied hw_counters are not available in a non-init\nnet namespace:\n  find /sys/class/infiniband/mlx4_0/ -name hw_counters\n    /sys/class/infiniband/mlx4_0/ports/1/hw_counters\n    /sys/class/infiniband/mlx4_0/ports/2/hw_counters\n    /sys/class/infiniband/mlx4_0/hw_counters\n\n  ip netns add foo\n  ip netns exec foo bash\n  find /sys/class/infiniband/mlx4_0/ -name hw_counters(CVE-2025-22089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvmxnet3: unregister xdp rxq info in the reset path\n\nvmxnet3 does not unregister xdp rxq info in the\nvmxnet3_reset_work() code path as vmxnet3_rq_destroy()\nis not invoked in this code path. So, we get below message with a\nbacktrace.\n\nMissing unregister, handled but fix driver\nWARNING: CPU:48 PID: 500 at net/core/xdp.c:182\n__xdp_rxq_info_reg+0x93/0xf0\n\nThis patch fixes the problem by moving the unregister\ncode of XDP from vmxnet3_rq_destroy() to vmxnet3_rq_cleanup().(CVE-2025-22106)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ppp: Add bound checking for skb data on ppp_sync_txmung\n\nEnsure we have enough data in linear buffer from skb before accessing\ninitial bytes. This prevents potential out-of-bounds accesses\nwhen processing short packets.\n\nWhen ppp_sync_txmung receives an incoming package with an empty\npayload:\n(remote) gef➤  p *(struct pppoe_hdr *) (skb->head + skb->network_header)\n$18 = {\n\ttype = 0x1,\n\tver = 0x1,\n\tcode = 0x0,\n\tsid = 0x2,\n        length = 0x0,\n\ttag = 0xffff8880371cdb96\n}\n\nfrom the skb struct (trimmed)\n      tail = 0x16,\n      end = 0x140,\n      head = 0xffff88803346f400 "4",\n      data = 0xffff88803346f416 ":\\377",\n      truesize = 0x380,\n      len = 0x0,\n      data_len = 0x0,\n      mac_len = 0xe,\n      hdr_len = 0x0,\n\nit is not safe to access data[2].\n\n[(CVE-2025-37749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: sch_sfq: move the limit validation\n\nIt is not sufficient to directly validate the limit on the data that\nthe user passes as it can be updated based on how the other parameters\nare changed.\n\nMove the check at the end of the configuration update process to also\ncatch scenarios where the limit is indirectly updated, for example\nwith the following configurations:\n\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1\ntc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1\n\nThis fixes the following syzkaller reported crash:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:203:6\nindex 65535 is out of range for type 'struct sfq_head[128]'\nCPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:120\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0xf5/0x120 lib/ubsan.c:429\n sfq_link net/sched/sch_sfq.c:203 [inline]\n sfq_dec+0x53c/0x610 net/sched/sch_sfq.c:231\n sfq_dequeue+0x34e/0x8c0 net/sched/sch_sfq.c:493\n sfq_reset+0x17/0x60 net/sched/sch_sfq.c:518\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n tbf_reset+0x41/0x110 net/sched/sch_tbf.c:339\n qdisc_reset+0x12e/0x600 net/sched/sch_generic.c:1035\n dev_reset_queue+0x100/0x1b0 net/sched/sch_generic.c:1311\n netdev_for_each_tx_queue include/linux/netdevice.h:2590 [inline]\n dev_deactivate_many+0x7e5/0xe70 net/sched/sch_generic.c:1375(CVE-2025-37752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Fix workqueue crash in cma_netevent_work_handler\n\nstruct rdma_cm_id has member "struct work_struct net_work"\nthat is reused for enqueuing cma_netevent_work_handler()s\nonto cma_wq.\n\nBelow crash[1] can occur if more than one call to\ncma_netevent_callback() occurs in quick succession,\nwhich further enqueues cma_netevent_work_handler()s for the\nsame rdma_cm_id, overwriting any previously queued work-item(s)\nthat was just scheduled to run i.e. there is no guarantee\nthe queued work item may run between two successive calls\nto cma_netevent_callback() and the 2nd INIT_WORK would overwrite\nthe 1st work item (for the same rdma_cm_id), despite grabbing\nid_table_lock during enqueue.\n\nAlso drgn analysis [2] indicates the work item was likely overwritten.\n\nFix this by moving the INIT_WORK() to __rdma_create_id(),\nso that it doesn't race with any existing queue_work() or\nits worker thread.\n\n[1] Trimmed crash stack:\n=============================================\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nkworker/u256:6 ... 6.12.0-0...\nWorkqueue:  cma_netevent_work_handler [rdma_cm] (rdma_cm)\nRIP: 0010:process_one_work+0xba/0x31a\nCall Trace:\n worker_thread+0x266/0x3a0\n kthread+0xcf/0x100\n ret_from_fork+0x31/0x50\n ret_from_fork_asm+0x1a/0x30\n=============================================\n\n[2] drgn crash analysis:\n\n>>> trace = prog.crashed_thread().stack_trace()\n>>> trace\n(0)  crash_setup_regs (./arch/x86/include/asm/kexec.h:111:15)\n(1)  __crash_kexec (kernel/crash_core.c:122:4)\n(2)  panic (kernel/panic.c:399:3)\n(3)  oops_end (arch/x86/kernel/dumpstack.c:382:3)\n...\n(8)  process_one_work (kernel/workqueue.c:3168:2)\n(9)  process_scheduled_works (kernel/workqueue.c:3310:3)\n(10) worker_thread (kernel/workqueue.c:3391:4)\n(11) kthread (kernel/kthread.c:389:9)\n\nLine workqueue.c:3168 for this kernel version is in process_one_work():\n3168\tstrscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);\n\n>>> trace[8]["work"]\n*(struct work_struct *)0xffff92577d0a21d8 = {\n\t.data = (atomic_long_t){\n\t\t.counter = (s64)536870912,    <=== Note\n\t},\n\t.entry = (struct list_head){\n\t\t.next = (struct list_head *)0xffff924d075924c0,\n\t\t.prev = (struct list_head *)0xffff924d075924c0,\n\t},\n\t.func = (work_func_t)cma_netevent_work_handler+0x0 = 0xffffffffc2cec280,\n}\n\nSuspicion is that pwq is NULL:\n>>> trace[8]["pwq"]\n(struct pool_workqueue *)<absent>\n\nIn process_one_work(), pwq is assigned from:\nstruct pool_workqueue *pwq = get_work_pwq(work);\n\nand get_work_pwq() is:\nstatic struct pool_workqueue *get_work_pwq(struct work_struct *work)\n{\n \tunsigned long data = atomic_long_read(&work->data);\n\n \tif (data & WORK_STRUCT_PWQ)\n \t\treturn work_struct_pwq(data);\n \telse\n \t\treturn NULL;\n}\n\nWORK_STRUCT_PWQ is 0x4:\n>>> print(repr(prog['WORK_STRUCT_PWQ']))\nObject(prog, 'enum work_flags', value=4)\n\nBut work->data is 536870912 which is 0x20000000.\nSo, get_work_pwq() returns NULL and we crash in process_one_work():\n3168\tstrscpy(worker->desc, pwq->wq->name, WORKER_DESC_LEN);\n=============================================(CVE-2025-37772)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix nested key length validation in the set() action\n\nIt's not safe to access nla_len(ovs_key) if the data is smaller than\nthe netlink header.  Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Purge vif txq in ieee80211_do_stop()\n\nAfter ieee80211_do_stop() SKB from vif's txq could still be processed.\nIndeed another concurrent vif schedule_and_wake_txq call could cause\nthose packets to be dequeued (see ieee80211_handle_wake_tx_queue())\nwithout checking the sdata current state.\n\nBecause vif.drv_priv is now cleared in this function, this could lead to\ndriver crash.\n\nFor example in ath12k, ahvif is store in vif.drv_priv. Thus if\nath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can be\nNULL, leading the ath12k_warn(ahvif->ah,...) call in this function to\ntrigger the NULL deref below.\n\n  Unable to handle kernel paging request at virtual address dfffffc000000001\n  KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n  batman_adv: bat0: Interface deactivated: brbh1337\n  Mem abort info:\n    ESR = 0x0000000096000004\n    EC = 0x25: DABT (current EL), IL = 32 bits\n    SET = 0, FnV = 0\n    EA = 0, S1PTW = 0\n    FSC = 0x04: level 0 translation fault\n  Data abort info:\n    ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n    CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n    GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n  [dfffffc000000001] address between user and kernel address ranges\n  Internal error: Oops: 0000000096000004 [#1] SMP\n  CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114\n  Hardware name: HW (DT)\n  pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k]\n  lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k]\n  sp : ffffffc086ace450\n  x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4\n  x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e\n  x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0\n  x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958\n  x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8\n  x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03\n  x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40\n  x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0\n  x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001\n  x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008\n  Call trace:\n   ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P)\n   ieee80211_handle_wake_tx_queue+0x16c/0x260\n   ieee80211_queue_skb+0xeec/0x1d20\n   ieee80211_tx+0x200/0x2c8\n   ieee80211_xmit+0x22c/0x338\n   __ieee80211_subif_start_xmit+0x7e8/0xc60\n   ieee80211_subif_start_xmit+0xc4/0xee0\n   __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0\n   ieee80211_subif_start_xmit_8023+0x124/0x488\n   dev_hard_start_xmit+0x160/0x5a8\n   __dev_queue_xmit+0x6f8/0x3120\n   br_dev_queue_push_xmit+0x120/0x4a8\n   __br_forward+0xe4/0x2b0\n   deliver_clone+0x5c/0xd0\n   br_flood+0x398/0x580\n   br_dev_xmit+0x454/0x9f8\n   dev_hard_start_xmit+0x160/0x5a8\n   __dev_queue_xmit+0x6f8/0x3120\n   ip6_finish_output2+0xc28/0x1b60\n   __ip6_finish_output+0x38c/0x638\n   ip6_output+0x1b4/0x338\n   ip6_local_out+0x7c/0xa8\n   ip6_send_skb+0x7c/0x1b0\n   ip6_push_pending_frames+0x94/0xd0\n   rawv6_sendmsg+0x1a98/0x2898\n   inet_sendmsg+0x94/0xe0\n   __sys_sendto+0x1e4/0x308\n   __arm64_sys_sendto+0xc4/0x140\n   do_el0_svc+0x110/0x280\n   el0_svc+0x20/0x60\n   el0t_64_sync_handler+0x104/0x138\n   el0t_64_sync+0x154/0x158\n\nTo avoid that, empty vif's txq at ieee80211_do_stop() so no packet could\nbe dequeued after ieee80211_do_stop() (new packets cannot be queued\nbecause SDATA_STATE_RUNNING is cleared at this point).(CVE-2025-37794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()\n\ncpufreq_cpu_get_raw() can return NULL when the target CPU is not present\nin the policy->cpus mask. scpi_cpufreq_get_rate() does not check for\nthis case, which results in a NULL pointer dereference.(CVE-2025-37829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: don't try to reclaim hwpoison folio\n\nSyzkaller reports a bug as follows:\n\nInjecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000\nMemory failure: 0x18b00e: dirty swapcache page still referenced by 2 users\nMemory failure: 0x18b00e: recovery action for dirty swapcache page: Failed\npage: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e\nmemcg:ffff0000dd6d9000\nanon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)\nraw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9\nraw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000\npage dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))\n------------[ cut here ]------------\nkernel BUG at mm/swap_state.c:184!\nInternal error: Oops - BUG: 00000000f2000800 [#1] SMP\nModules linked in:\nCPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3\nHardware name: linux,dummy-virt (DT)\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : add_to_swap+0xbc/0x158\nlr : add_to_swap+0xbc/0x158\nsp : ffff800087f37340\nx29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780\nx26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0\nx23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4\nx20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000\nx17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c\nx14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b\nx11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000\nx8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001\nx5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000\nCall trace:\n add_to_swap+0xbc/0x158\n shrink_folio_list+0x12ac/0x2648\n shrink_inactive_list+0x318/0x948\n shrink_lruvec+0x450/0x720\n shrink_node_memcgs+0x280/0x4a8\n shrink_node+0x128/0x978\n balance_pgdat+0x4f0/0xb20\n kswapd+0x228/0x438\n kthread+0x214/0x230\n ret_from_fork+0x10/0x20\n\nI can reproduce this issue with the following steps:\n\n1) When a dirty swapcache page is isolated by reclaim process and the\n   page isn't locked, inject memory failure for the page. \n   me_swapcache_dirty() clears uptodate flag and tries to delete from lru,\n   but fails.  Reclaim process will put the hwpoisoned page back to lru.\n\n2) The process that maps the hwpoisoned page exits, the page is deleted\n   the page will never be freed and will be in the lru forever.\n\n3) If we trigger a reclaim again and tries to reclaim the page,\n   add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is\n   cleared.\n\nTo fix it, skip the hwpoisoned page in shrink_folio_list().  Besides, the\nhwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap\nit in shrink_folio_list(), otherwise the folio will fail to be unmaped by\nhwpoison_user_mappings() since the folio isn't in lru list.(CVE-2025-37834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: avoid infinite loop to schedule delayed worker\n\nWe noticed the kworker in page_pool_release_retry() was waken\nup repeatedly and infinitely in production because of the\nbuggy driver causing the inflight less than 0 and warning\nus in page_pool_inflight()[1].\n\nSince the inflight value goes negative, it means we should\nnot expect the whole page_pool to get back to work normally.\n\nThis patch mitigates the adverse effect by not rescheduling\nthe kworker when detecting the inflight negative in\npage_pool_release_retry().\n\n[1]\n[Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------\n[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages\n...\n[Mon Feb 10 20:36:11 2025] Call Trace:\n[Mon Feb 10 20:36:11 2025]  page_pool_release_retry+0x23/0x70\n[Mon Feb 10 20:36:11 2025]  process_one_work+0x1b1/0x370\n[Mon Feb 10 20:36:11 2025]  worker_thread+0x37/0x3a0\n[Mon Feb 10 20:36:11 2025]  kthread+0x11a/0x140\n[Mon Feb 10 20:36:11 2025]  ? process_one_work+0x370/0x370\n[Mon Feb 10 20:36:11 2025]  ? __kthread_cancel_work+0x40/0x40\n[Mon Feb 10 20:36:11 2025]  ret_from_fork+0x35/0x40\n[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---\nNote: before this patch, the above calltrace would flood the\ndmesg due to repeated reschedule of release_dw kworker.(CVE-2025-37859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nigc: fix PTM cycle trigger logic\n\nWriting to clear the PTM status 'valid' bit while the PTM cycle is\ntriggered results in unreliable PTM operation. To fix this, clear the\nPTM 'trigger' and status after each PTM transaction.\n\nThe issue can be reproduced with the following:\n\n$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m\n\nNote: 1000 Hz (-R 1000) is unrealistically large, but provides a way to\nquickly reproduce the issue.\n\nPHC2SYS exits with:\n\n"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction\n  fails\n\nThis patch also fixes a hang in igc_probe() when loading the igc\ndriver in the kdump kernel on systems supporting PTM.\n\nThe igc driver running in the base kernel enables PTM trigger in\nigc_probe().  Therefore the driver is always in PTM trigger mode,\nexcept in brief periods when manually triggering a PTM cycle.\n\nWhen a crash occurs, the NIC is reset while PTM trigger is enabled.\nDue to a hardware problem, the NIC is subsequently in a bad busmaster\nstate and doesn't handle register reads/writes.  When running\nigc_probe() in the kdump kernel, the first register access to a NIC\nregister hangs driver probing and ultimately breaks kdump.\n\nWith this patch, igc has PTM trigger disabled most of the time,\nand the trigger is only enabled for very brief (10 - 100 us) periods\nwhen manually triggering a PTM cycle.  Chances that a crash occurs\nduring a PTM trigger are not 0, but extremely reduced.(CVE-2025-37875)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/net: fix improper handling of bogus negative read/write replies\n\nIn p9_client_write() and p9_client_read_once(), if the server\nincorrectly replies with success but a negative write/read count then we\nwould consider written (negative) <= rsize (positive) because both\nvariables were signed.\n\nMake variables unsigned to avoid this problem.\n\nThe reproducer linked below now fails with the following error instead\nof a null pointer deref:\n9pnet: bogus RWRITE count (4294967295 > 3)(CVE-2025-37879)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Reset IRTE to host control if *new* route isn't postable\n\nRestore an IRTE back to host control (remapped or posted MSI mode) if the\n*new* GSI route prevents posting the IRQ directly to a vCPU, regardless of\nthe GSI routing type.  Updating the IRTE if and only if the new GSI is an\nMSI results in KVM leaving an IRTE posting to a vCPU.\n\nThe dangling IRTE can result in interrupts being incorrectly delivered to\nthe guest, and in the worst case scenario can result in use-after-free,\ne.g. if the VM is torn down, but the underlying host IRQ isn't freed.(CVE-2025-37885)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: lan743x: Fix memleak issue when GSO enabled\n\nAlways map the `skb` to the LS descriptor. Previously skb was\nmapped to EXT descriptor when the number of fragments is zero with\nGSO enabled. Mapping the skb to EXT descriptor prevents it from\nbeing freed, leading to a memory leak(CVE-2025-37909)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix out-of-bound memcpy() during ethtool -w\n\nWhen retrieving the FW coredump using ethtool, it can sometimes cause\nmemory corruption:\n\nBUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nCorrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):\n__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]\nethtool_get_dump_data+0xdc/0x1a0\n__dev_ethtool+0xa1e/0x1af0\ndev_ethtool+0xa8/0x170\ndev_ioctl+0x1b5/0x580\nsock_do_ioctl+0xab/0xf0\nsock_ioctl+0x1ce/0x2e0\n__x64_sys_ioctl+0x87/0xc0\ndo_syscall_64+0x5c/0xf0\nentry_SYSCALL_64_after_hwframe+0x78/0x80\n\n...\n\nThis happens when copying the coredump segment list in\nbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.\nThe info->dest_buf buffer is allocated based on the number of coredump\nsegments returned by the FW.  The segment list is then DMA'ed by\nthe FW and the length of the DMA is returned by FW.  The driver then\ncopies this DMA'ed segment list to info->dest_buf.\n\nIn some cases, this DMA length may exceed the info->dest_buf length\nand cause the above BUG condition.  Fix it by capping the copy\nlength to not exceed the length of info->dest_buf.  The extra\nDMA data contains no useful information.\n\nThis code path is shared for the HWRM_DBG_COREDUMP_LIST and the\nHWRM_DBG_COREDUMP_RETRIEVE FW commands.  The buffering is different\nfor these 2 FW commands.  To simplify the logic, we need to move\nthe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVE\nup, so that the new check to cap the copy length will work for both\ncommands.(CVE-2025-37911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()\n\nAs mentioned in the commit baeb705fd6a7 ("ice: always check VF VSI\npointer values"), we need to perform a null pointer check on the return\nvalue of ice_get_vf_vsi() before using it.(CVE-2025-37912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_htb: make htb_qlen_notify() idempotent\n\nhtb_qlen_notify() always deactivates the HTB class and in fact could\ntrigger a warning if it is already deactivated. Therefore, it is not\nidempotent and not friendly to its callers, like fq_codel_dequeue().\n\nLet's make it idempotent to ease qdisc_tree_reduce_backlog() callers'\nlife.(CVE-2025-37932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY\n\nDSA has 2 kinds of drivers:\n\n1. Those who call dsa_switch_suspend() and dsa_switch_resume() from\n   their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz\n2. Those who don't: all others. The above methods should be optional.\n\nFor type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(),\nand dsa_switch_resume() calls dsa_user_resume() -> phylink_start().\nThese seem good candidates for setting mac_managed_pm = true because\nthat is essentially its definition [1], but that does not seem to be the\nbiggest problem for now, and is not what this change focuses on.\n\nTalking strictly about the 2nd category of DSA drivers here (which\ndo not have MAC managed PM, meaning that for their attached PHYs,\nmdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),\nI have noticed that the following warning from mdio_bus_phy_resume() is\ntriggered:\n\n\tWARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY &&\n\t\tphydev->state != PHY_UP);\n\nbecause the PHY state machine is running.\n\nIt's running as a result of a previous dsa_user_open() -> ... ->\nphylink_start() -> phy_start() having been initiated by the user.\n\nThe previous mdio_bus_phy_suspend() was supposed to have called\nphy_stop_machine(), but it didn't. So this is why the PHY is in state\nPHY_NOLINK by the time mdio_bus_phy_resume() runs.\n\nmdio_bus_phy_suspend() did not call phy_stop_machine() because for\nphylink, the phydev->adjust_link function pointer is NULL. This seems a\ntechnicality introduced by commit fddd91016d16 ("phylib: fix PAL state\nmachine restart on resume"). That commit was written before phylink\nexisted, and was intended to avoid crashing with consumer drivers which\ndon't use the PHY state machine - phylink always does, when using a PHY.\nBut phylink itself has historically not been developed with\nsuspend/resume in mind, and apparently not tested too much in that\nscenario, allowing this bug to exist unnoticed for so long. Plus, prior\nto the WARN_ON(), it would have likely been invisible.\n\nThis issue is not in fact restricted to type 2 DSA drivers (according to\nthe above ad-hoc classification), but can be extrapolated to any MAC\ndriver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where\nthe issue was reported. Assuming mac_managed_pm is set correctly, a\nquick search indicates the following other drivers might be affected:\n\n$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pm\ndrivers/net/ethernet/atheros/ag71xx.c\ndrivers/net/ethernet/microchip/sparx5/sparx5_main.c\ndrivers/net/ethernet/microchip/lan966x/lan966x_main.c\ndrivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c\ndrivers/net/ethernet/freescale/fs_enet/fs_enet-main.c\ndrivers/net/ethernet/freescale/dpaa/dpaa_eth.c\ndrivers/net/ethernet/freescale/ucc_geth.c\ndrivers/net/ethernet/freescale/enetc/enetc_pf_common.c\ndrivers/net/ethernet/marvell/mvpp2/mvpp2_main.c\ndrivers/net/ethernet/marvell/mvneta.c\ndrivers/net/ethernet/marvell/prestera/prestera_main.c\ndrivers/net/ethernet/mediatek/mtk_eth_soc.c\ndrivers/net/ethernet/altera/altera_tse_main.c\ndrivers/net/ethernet/wangxun/txgbe/txgbe_phy.c\ndrivers/net/ethernet/meta/fbnic/fbnic_phylink.c\ndrivers/net/ethernet/tehuti/tn40_phy.c\ndrivers/net/ethernet/mscc/ocelot_net.c\n\nMake the existing conditions dependent on the PHY device having a\nphydev->phy_link_change() implementation equal to the default\nphy_link_change() provided by phylib. Otherwise, we implicitly know that\nthe phydev has the phylink-provided phylink_phy_change() callback, and\nwhen phylink is used, the PHY state machine always needs to be stopped/\nstarted on the suspend/resume path. The code is structured as such that\nif phydev->phy_link_change() is absent, it is a matter of time until the\nkernel will crash - no need to further complicate the test.\n\nThus, for the situation where the PM is not managed b\n---truncated---(CVE-2025-37945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Scrub packet on bpf_redirect_peer\n\nWhen bpf_redirect_peer is used to redirect packets to a device in\nanother network namespace, the skb isn't scrubbed. That can lead skb\ninformation from one namespace to be "misused" in another namespace.\n\nAs one example, this is causing Cilium to drop traffic when using\nbpf_redirect_peer to redirect packets that just went through IPsec\ndecryption to a container namespace. The following pwru trace shows (1)\nthe packet path from the host's XFRM layer to the container's XFRM\nlayer where it's dropped and (2) the number of active skb extensions at\neach function.\n\n    NETNS       MARK  IFACE  TUPLE                                FUNC\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  xfrm_rcv_cb\n                             .active_extensions = (__u8)2,\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  xfrm4_rcv_cb\n                             .active_extensions = (__u8)2,\n    4026533547  d00   eth0   10.244.3.124:35473->10.244.2.158:53  gro_cells_receive\n                             .active_extensions = (__u8)2,\n    [...]\n    4026533547  0     eth0   10.244.3.124:35473->10.244.2.158:53  skb_do_redirect\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  ip_rcv\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  ip_rcv_core\n                             .active_extensions = (__u8)2,\n    [...]\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  udp_queue_rcv_one_skb\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  __xfrm_policy_check\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  __xfrm_decode_session\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  security_xfrm_decode_session\n                             .active_extensions = (__u8)2,\n    4026534999  0     eth0   10.244.3.124:35473->10.244.2.158:53  kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)\n                             .active_extensions = (__u8)2,\n\nIn this case, there are no XFRM policies in the container's network\nnamespace so the drop is unexpected. When we decrypt the IPsec packet,\nthe XFRM state used for decryption is set in the skb extensions. This\ninformation is preserved across the netns switch. When we reach the\nXFRM policy check in the container's netns, __xfrm_policy_check drops\nthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRM\npolicy can't be found that matches the (host-side) XFRM state used for\ndecryption.\n\nThis patch fixes this by scrubbing the packet when using\nbpf_redirect_peer, as is done on typical netns switches via veth\ndevices except skb->mark and skb->tstamp are not zeroed.(CVE-2025-37959)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemblock: Accept allocated memory before use in memblock_double_array()\n\nWhen increasing the array size in memblock_double_array() and the slab\nis not yet available, a call to memblock_find_in_range() is used to\nreserve/allocate memory. However, the range returned may not have been\naccepted, which can result in a crash when booting an SNP guest:\n\n  RIP: 0010:memcpy_orig+0x68/0x130\n  Code: ...\n  RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006\n  RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000\n  RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00\n  RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000\n  R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78\n  R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00\n  memblock_double_array+0xff/0x310\n  memblock_add_range+0x1fb/0x2f0\n  memblock_reserve+0x4f/0xa0\n  memblock_alloc_range_nid+0xac/0x130\n  memblock_alloc_internal+0x53/0xc0\n  memblock_alloc_try_nid+0x3d/0xa0\n  swiotlb_init_remap+0x149/0x2f0\n  mem_init+0xb/0xb0\n  mm_core_init+0x8f/0x350\n  start_kernel+0x17e/0x5d0\n  x86_64_start_reservations+0x14/0x30\n  x86_64_start_kernel+0x92/0xa0\n  secondary_startup_64_no_verify+0x194/0x19b\n\nMitigate this by calling accept_memory() on the memory range returned\nbefore the slab is available.\n\nPrior to v6.12, the accept_memory() interface used a 'start' and 'end'\nparameter instead of 'start' and 'size', therefore the accept_memory()\ncall must be adjusted to specify 'start + size' for 'end' when applying\nto kernels prior to v6.12.(CVE-2025-37960)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix uninit-value for saddr in do_output_route4\n\nsyzbot reports for uninit-value for the saddr argument [1].\ncommit 4754957f04f5 ("ipvs: do not use random local source address for\ntunnels") already implies that the input value of saddr\nshould be ignored but the code is still reading it which can prevent\nto connect the route. Fix it by changing the argument to ret_saddr.\n\n[1]\nBUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147\n __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:4167 [inline]\n slab_alloc_node mm/slub.c:4210 [inline]\n __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367\n kmalloc_noprof include/linux/slab.h:905 [inline]\n ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline]\n __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323\n ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136\n ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063\n nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626\n nf_hook include/linux/netfilter.h:269 [inline]\n __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118\n ip_local_out net/ipv4/ip_output.c:127 [inline]\n ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501\n udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195\n udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483\n inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x267/0x380 net/socket.c:727\n ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620\n __sys_sendmmsg+0x41d/0x880 net/socket.c:2702\n __compat_sys_sendmmsg net/compat.c:360 [inline]\n __do_compat_sys_sendmmsg net/compat.c:367 [inline]\n __se_compat_sys_sendmmsg net/compat.c:364 [inline]\n __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364\n ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306\n do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369\n entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n\nCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)\nHardware name: Google Google Compute Engi\n---truncated---(CVE-2025-37961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: leds: fix memory leak\n\nA network restart test on a router led to an out-of-memory condition,\nwhich was traced to a memory leak in the PHY LED trigger code.\n\nThe root cause is misuse of the devm API. The registration function\n(phy_led_triggers_register) is called from phy_attach_direct, not\nphy_probe, and the unregister function (phy_led_triggers_unregister)\nis called from phy_detach, not phy_remove. This means the register and\nunregister functions can be called multiple times for the same PHY\ndevice, but devm-allocated memory is not freed until the driver is\nunbound.\n\nThis also prevents kmemleak from detecting the leak, as the devm API\ninternally stores the allocated pointer.\n\nFix this by replacing devm_kzalloc/devm_kcalloc with standard\nkzalloc/kcalloc, and add the corresponding kfree calls in the unregister\npath.(CVE-2025-37989)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()\n\nThe function brcmf_usb_dl_writeimage() calls the function\nbrcmf_usb_dl_cmd() but dose not check its return value. The\n'state.state' and the 'state.bytes' are uninitialized if the\nfunction brcmf_usb_dl_cmd() fails. It is dangerous to use\nuninitialized variables in the conditions.\n\nAdd error handling for brcmf_usb_dl_cmd() to jump to error\nhandling path if the brcmf_usb_dl_cmd() fails and the\n'state.state' and the 'state.bytes' are uninitialized.\n\nImprove the error message to report more detailed error\ninformation.(CVE-2025-37990)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: add missing rcu read protection for procfs content\n\nWhen the procfs content is generated for a bcm_op which is in the process\nto be removed the procfs output might show unreliable data (UAF).\n\nAs the removal of bcm_op's is already implemented with rcu handling this\npatch adds the missing rcu_read_lock() and makes sure the list entries\nare properly removed under rcu protection.(CVE-2025-38003)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncan: bcm: add locking for bcm_op runtime updates\n\nThe CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via\nhrtimer. The content and also the length of the sequence can be changed\nresp reduced at runtime where the 'currframe' counter is then set to zero.\n\nAlthough this appeared to be a safe operation the updates of 'currframe'\ncan be triggered from user space and hrtimer context in bcm_can_tx().\nAnderson Nascimento created a proof of concept that triggered a KASAN\nslab-out-of-bounds read access which can be prevented with a spin_lock_bh.\n\nAt the rework of bcm_can_tx() the 'count' variable has been moved into\nthe protected section as this variable can be modified from both contexts\ntoo.(CVE-2025-38004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nphy: tegra: xusb: Use a bitmask for UTMI pad power state tracking\n\nThe current implementation uses bias_pad_enable as a reference count to\nmanage the shared bias pad for all UTMI PHYs. However, during system\nsuspension with connected USB devices, multiple power-down requests for\nthe UTMI pad result in a mismatch in the reference count, which in turn\nproduces warnings such as:\n\n[  237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170\n[  237.763103] Call trace:\n[  237.763104]  tegra186_utmi_pad_power_down+0x160/0x170\n[  237.763107]  tegra186_utmi_phy_power_off+0x10/0x30\n[  237.763110]  phy_power_off+0x48/0x100\n[  237.763113]  tegra_xusb_enter_elpg+0x204/0x500\n[  237.763119]  tegra_xusb_suspend+0x48/0x140\n[  237.763122]  platform_pm_suspend+0x2c/0xb0\n[  237.763125]  dpm_run_callback.isra.0+0x20/0xa0\n[  237.763127]  __device_suspend+0x118/0x330\n[  237.763129]  dpm_suspend+0x10c/0x1f0\n[  237.763130]  dpm_suspend_start+0x88/0xb0\n[  237.763132]  suspend_devices_and_enter+0x120/0x500\n[  237.763135]  pm_suspend+0x1ec/0x270\n\nThe root cause was traced back to the dynamic power-down changes\nintroduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"),\nwhere the UTMI pad was being powered down without verifying its current\nstate. This unbalanced behavior led to discrepancies in the reference\ncount.\n\nTo rectify this issue, this patch replaces the single reference counter\nwith a bitmask, renamed to utmi_pad_enabled. Each bit in the mask\ncorresponds to one of the four USB2 PHYs, allowing us to track each pad's\nenablement status individually.\n\nWith this change:\n  - The bias pad is powered on only when the mask is clear.\n  - Each UTMI pad is powered on or down based on its corresponding bit\n    in the mask, preventing redundant operations.\n  - The overall power state of the shared bias pad is maintained\n    correctly during suspend/resume cycles.\n\nThe mutex used to prevent race conditions during UTMI pad enable/disable\noperations has been moved from the tegra186_utmi_bias_pad_power_on/off\nfunctions to the parent functions tegra186_utmi_pad_power_on/down. This\nchange ensures that there are no race conditions when updating the bitmask.(CVE-2025-38010)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices\n\nThe driver only offloads neighbors that are constructed on top of net\ndevices registered by it or their uppers (which are all Ethernet). The\ndevice supports GRE encapsulation and decapsulation of forwarded\ntraffic, but the driver will not offload dummy neighbors constructed on\ntop of GRE net devices as they are not uppers of its net devices:\n\n # ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1\n # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1\n $ ip neigh show dev gre1 nud noarp\n 0.0.0.0 lladdr 0.0.0.0 NOARP\n\n(Note that the neighbor is not marked with 'offload')\n\nWhen the driver is reloaded and the existing configuration is replayed,\nthe driver does not perform the same check regarding existing neighbors\nand offloads the previously added one:\n\n # devlink dev reload pci/0000:01:00.0\n $ ip neigh show dev gre1 nud noarp\n 0.0.0.0 lladdr 0.0.0.0 offload NOARP\n\nIf the neighbor is later deleted, the driver will ignore the\nnotification (given the GRE net device is not its upper) and will\ntherefore keep referencing freed memory, resulting in a use-after-free\n[1] when the net device is deleted:\n\n # ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1\n # ip link del dev gre1\n\nFix by skipping neighbor replay if the net device for which the replay\nis performed is not our upper.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x1ea/0x200\nRead of size 8 at addr ffff888155b0e420 by task ip/2282\n[...]\nCall Trace:\n <TASK>\n dump_stack_lvl+0x6f/0xa0\n print_address_description.constprop.0+0x6f/0x350\n print_report+0x108/0x205\n kasan_report+0xdf/0x110\n mlxsw_sp_neigh_entry_update+0x1ea/0x200\n mlxsw_sp_router_rif_gone_sync+0x2a8/0x440\n mlxsw_sp_rif_destroy+0x1e9/0x750\n mlxsw_sp_netdevice_ipip_ol_event+0x3c9/0xdc0\n mlxsw_sp_router_netdevice_event+0x3ac/0x15e0\n notifier_call_chain+0xca/0x150\n call_netdevice_notifiers_info+0x7f/0x100\n unregister_netdevice_many_notify+0xc8c/0x1d90\n rtnl_dellink+0x34e/0xa50\n rtnetlink_rcv_msg+0x6fb/0xb70\n netlink_rcv_skb+0x131/0x360\n netlink_unicast+0x426/0x710\n netlink_sendmsg+0x75a/0xc20\n __sock_sendmsg+0xc1/0x150\n ____sys_sendmsg+0x5aa/0x7b0\n ___sys_sendmsg+0xfc/0x180\n __sys_sendmsg+0x121/0x1b0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-38019)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Disable MACsec offload for uplink representor profile\n\nMACsec offload is not supported in switchdev mode for uplink\nrepresentors. When switching to the uplink representor profile, the\nMACsec offload feature must be cleared from the netdevice's features.\n\nIf left enabled, attempts to add offloads result in a null pointer\ndereference, as the uplink representor does not support MACsec offload\neven though the feature bit remains set.\n\nClear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features().\n\nKernel log:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]\nCPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:__mutex_lock+0x128/0x1dd0\nCode: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff\nRSP: 0018:ffff888147a4f160 EFLAGS: 00010206\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001\nRDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078\nRBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000\nFS:  00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n ? die_addr+0x3d/0xa0\n ? exc_general_protection+0x144/0x220\n ? asm_exc_general_protection+0x22/0x30\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? __mutex_lock+0x128/0x1dd0\n ? lockdep_set_lock_cmp_fn+0x190/0x190\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? mutex_lock_io_nested+0x1ae0/0x1ae0\n ? lock_acquire+0x1c2/0x530\n ? macsec_upd_offload+0x145/0x380\n ? lockdep_hardirqs_on_prepare+0x400/0x400\n ? kasan_save_stack+0x30/0x40\n ? kasan_save_stack+0x20/0x40\n ? kasan_save_track+0x10/0x30\n ? __kasan_kmalloc+0x77/0x90\n ? __kmalloc_noprof+0x249/0x6b0\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240\n ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core]\n ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core]\n macsec_update_offload+0x26c/0x820\n ? macsec_set_mac_address+0x4b0/0x4b0\n ? lockdep_hardirqs_on_prepare+0x284/0x400\n ? _raw_spin_unlock_irqrestore+0x47/0x50\n macsec_upd_offload+0x2c8/0x380\n ? macsec_update_offload+0x820/0x820\n ? __nla_parse+0x22/0x30\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240\n genl_family_rcv_msg_doit+0x1cc/0x2a0\n ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240\n ? cap_capable+0xd4/0x330\n genl_rcv_msg+0x3ea/0x670\n ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0\n ? lockdep_set_lock_cmp_fn+0x190/0x190\n ? macsec_update_offload+0x820/0x820\n netlink_rcv_skb+0x12b/0x390\n ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0\n ? netlink_ack+0xd80/0xd80\n ? rwsem_down_read_slowpath+0xf90/0xf90\n ? netlink_deliver_tap+0xcd/0xac0\n ? netlink_deliver_tap+0x155/0xac0\n ? _copy_from_iter+0x1bb/0x12c0\n genl_rcv+0x24/0x40\n netlink_unicast+0x440/0x700\n ? netlink_attachskb+0x760/0x760\n ? lock_acquire+0x1c2/0x530\n ? __might_fault+0xbb/0x170\n netlink_sendmsg+0x749/0xc10\n ? netlink_unicast+0x700/0x700\n ? __might_fault+0xbb/0x170\n ? netlink_unicast+0x700/0x700\n __sock_sendmsg+0xc5/0x190\n ____sys_sendmsg+0x53f/0x760\n ? import_iovec+0x7/0x10\n ? kernel_sendmsg+0x30/0x30\n ? __copy_msghdr+0x3c0/0x3c0\n ? filter_irq_stacks+0x90/0x90\n ? stack_depot_save_flags+0x28/0xa30\n ___sys_sen\n---truncated---(CVE-2025-38020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problem\n\nCall Trace:\n\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n strlen+0x93/0xa0 lib/string.c:420\n __fortify_strlen include/linux/fortify-string.h:268 [inline]\n get_kobj_path_length lib/kobject.c:118 [inline]\n kobject_get_path+0x3f/0x2a0 lib/kobject.c:158\n kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545\n ib_register_device drivers/infiniband/core/device.c:1472 [inline]\n ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393\n rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552\n rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550\n rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225\n nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796\n rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195\n rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620\n __sys_sendmsg+0x16d/0x220 net/socket.c:2652\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThis problem is similar to the problem that the\ncommit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name")\nfixes.\n\nThe root cause is: the function ib_device_rename() renames the name with\nlock. But in the function kobject_uevent(), this name is accessed without\nlock protection at the same time.\n\nThe solution is to add the lock protection when this name is accessed in\nthe function kobject_uevent().(CVE-2025-38022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug\n\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcf/0x610 mm/kasan/report.c:489\n kasan_report+0xb5/0xe0 mm/kasan/report.c:602\n rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195\n rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132\n __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232\n rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109\n create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052\n ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095\n ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679\n vfs_write fs/read_write.c:677 [inline]\n vfs_write+0x26a/0xcc0 fs/read_write.c:659\n ksys_write+0x1b8/0x200 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIn the function rxe_create_cq, when rxe_cq_from_init fails, the function\nrxe_cleanup will be called to handle the allocated resources. In fact,\nsome memory resources have already been freed in the function\nrxe_cq_from_init. Thus, this problem will occur.\n\nThe solution is to let rxe_cleanup do all the work.(CVE-2025-38024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled\n\nWhen attempting to enable MQPRIO while HTB offload is already\nconfigured, the driver currently returns `-EINVAL` and triggers a\n`WARN_ON`, leading to an unnecessary call trace.\n\nUpdate the code to handle this case more gracefully by returning\n`-EOPNOTSUPP` instead, while also providing a helpful user message.(CVE-2025-38039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn\n\nThe user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can\nrun on multiple platforms having different DMA architectures.\nOn some platforms there can be one FDQ for all flows in the RX channel\nwhile for others there is a separate FDQ for each flow in the RX channel.\n\nSo far we have been relying on the skip_fdq argument of\nk3_udma_glue_reset_rx_chn().\n\nInstead of relying on the user to provide this information, infer it\nbased on DMA architecture during k3_udma_glue_request_rx_chn() and save it\nin an internal flag 'single_fdq'. Use that flag at\nk3_udma_glue_reset_rx_chn() to deicide if the FDQ needs\nto be cleared for every flow or just for flow 0.\n\nFixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.\n\n> ip link set eth1 down\n> ip link set eth0 down\n> ethtool -L eth0 rx 8\n> ip link set eth0 up\n> modprobe -r ti_am65_cpsw_nuss\n\n[  103.045726] ------------[ cut here ]------------\n[  103.050505] k3_knav_desc_pool size 512000 != avail 64000\n[  103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[  103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas\np drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r\nfkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool]\n[  103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011\n[  103.119968] Hardware name: Texas Instruments AM625 SK (DT)\n[  103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[  103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool]\n[  103.154709] sp : ffff8000826ebbc0\n[  103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000\n[  103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0\n[  103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88\n[  103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000\n[  103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde\n[  103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000\n[  103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20\n[  103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100\n[  103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000\n[  103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000\n[  103.229274] Call trace:\n[  103.231714]  k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P)\n[  103.238408]  am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss]\n[  103.244942]  devm_action_release+0x14/0x20\n[  103.249040]  release_nodes+0x3c/0x68\n[  103.252610]  devres_release_all+0x8c/0xdc\n[  103.256614]  device_unbind_cleanup+0x18/0x60\n[  103.260876]  device_release_driver_internal+0xf8/0x178\n[  103.266004]  driver_detach+0x50/0x9c\n[  103.269571]  bus_remove_driver+0x6c/0xbc\n[  103.273485]  driver_unregister+0x30/0x60\n[  103.277401]  platform_driver_unregister+0x14/0x20\n[  103.282096]  am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss]\n[  103.288620]  __arm64_sys_delete_module+0x17c/0x25c\n[  103.293404]  invoke_syscall+0x44/0x100\n[  103.297149]  el0_svc_common.constprop.0+0xc0/0xe0\n[  103.301845]  do_el0_svc+0x1c/0x28\n[  103.305155]  el0_svc+0x28/0x98\n---truncated---(CVE-2025-38042)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cx231xx: set device_caps for 417\n\nThe video_device for the MPEG encoder did not set device_caps.\n\nAdd this, otherwise the video device can't be registered (you get a\nWARN_ON instead).\n\nNot seen before since currently 417 support is disabled, but I found\nthis while experimenting with it.(CVE-2025-38044)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nespintcp: fix skb leaks\n\nA few error paths are missing a kfree_skb.(CVE-2025-38057)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: prevent BUG_ON by blocking retries on failed device resumes\n\nA cache device failing to resume due to mapping errors should not be\nretried, as the failure leaves a partially initialized policy object.\nRepeating the resume operation risks triggering BUG_ON when reloading\ncache mappings into the incomplete policy object.\n\nReproduce steps:\n\n1. create a cache metadata consisting of 512 or more cache blocks,\n   with some mappings stored in the first array block of the mapping\n   array. Here we use cache_restore v1.0 to build the metadata.\n\ncat <<EOF >> cmeta.xml\n<superblock uuid="" block_size="128" nr_cache_blocks="512" \\\npolicy="smq" hint_width="4">\n  <mappings>\n    <mapping cache_block="0" origin_block="0" dirty="false"/>\n  </mappings>\n</superblock>\nEOF\ndmsetup create cmeta --table "0 8192 linear /dev/sdc 0"\ncache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2\ndmsetup remove cmeta\n\n2. wipe the second array block of the mapping array to simulate\n   data degradations.\n\nmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \\\n2>/dev/null | hexdump -e '1/8 "%u\\n"')\nablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \\\n2>/dev/null | hexdump -e '1/8 "%u\\n"')\ndd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock\n\n3. try bringing up the cache device. The resume is expected to fail\n   due to the broken array block.\n\ndmsetup create cmeta --table "0 8192 linear /dev/sdc 0"\ndmsetup create cdata --table "0 65536 linear /dev/sdc 8192"\ndmsetup create corig --table "0 524288 linear /dev/sdc 262144"\ndmsetup create cache --notable\ndmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"\ndmsetup resume cache\n\n4. try resuming the cache again. An unexpected BUG_ON is triggered\n   while loading cache mappings.\n\ndmsetup resume cache\n\nKernel logs:\n\n(snip)\n------------[ cut here ]------------\nkernel BUG at drivers/md/dm-cache-policy-smq.c:752!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3\nRIP: 0010:smq_load_mapping+0x3e5/0x570\n\nFix by disallowing resume operations for devices that failed the\ninitial attempt.(CVE-2025-38066)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race\n\nhuge_pmd_unshare() drops a reference on a page table that may have\npreviously been shared across processes, potentially turning it into a\nnormal page table used in another process in which unrelated VMAs can\nafterwards be installed.\n\nIf this happens in the middle of a concurrent gup_fast(), gup_fast() could\nend up walking the page tables of another process.  While I don't see any\nway in which that immediately leads to kernel memory corruption, it is\nreally weird and unexpected.\n\nFix it with an explicit broadcast IPI through tlb_remove_table_sync_one(),\njust like we do in khugepaged when removing page tables for a THP\ncollapse.(CVE-2025-38085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix use-after-free in taprio_dev_notifier\n\nSince taprio’s taprio_dev_notifier() isn’t protected by an\nRCU read-side critical section, a race with advance_sched()\ncan lead to a use-after-free.\n\nAdding rcu_read_lock() inside taprio_dev_notifier() prevents this.(CVE-2025-38087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nespintcp: remove encap socket caching to avoid reference leak\n\nThe current scheme for caching the encap socket can lead to reference\nleaks when we try to delete the netns.\n\nThe reference chain is: xfrm_state -> enacp_sk -> netns\n\nSince the encap socket is a userspace socket, it holds a reference on\nthe netns. If we delete the espintcp state (through flush or\nindividual delete) before removing the netns, the reference on the\nsocket is dropped and the netns is correctly deleted. Otherwise, the\nnetns may not be reachable anymore (if all processes within the ns\nhave terminated), so we cannot delete the xfrm state to drop its\nreference on the socket.\n\nThis patch results in a small (~2% in my tests) performance\nregression.\n\nA GC-type mechanism could be added for the socket cache, to clear\nreferences if the state hasn't been used "recently", but it's a lot\nmore complex than just not caching the socket.(CVE-2025-38097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npage_pool: Fix use-after-free in page_pool_recycle_in_ring\n\nsyzbot reported a uaf in page_pool_recycle_in_ring:\n\nBUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862\nRead of size 8 at addr ffff8880286045a0 by task syz.0.284/6943\n\nCPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862\n __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline]\n _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210\n spin_unlock_bh include/linux/spinlock.h:396 [inline]\n ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline]\n page_pool_recycle_in_ring net/core/page_pool.c:707 [inline]\n page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826\n page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline]\n page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline]\n napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036\n skb_pp_recycle net/core/skbuff.c:1047 [inline]\n skb_free_head net/core/skbuff.c:1094 [inline]\n skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125\n skb_release_all net/core/skbuff.c:1190 [inline]\n __kfree_skb net/core/skbuff.c:1204 [inline]\n sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242\n kfree_skb_reason include/linux/skbuff.h:1263 [inline]\n __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]\n\nroot cause is:\n\npage_pool_recycle_in_ring\n  ptr_ring_produce\n    spin_lock(&r->producer_lock);\n    WRITE_ONCE(r->queue[r->producer++], ptr)\n      //recycle last page to pool\n\t\t\t\tpage_pool_release\n\t\t\t\t  page_pool_scrub\n\t\t\t\t    page_pool_empty_ring\n\t\t\t\t      ptr_ring_consume\n\t\t\t\t      page_pool_return_page  //release all page\n\t\t\t\t  __page_pool_destroy\n\t\t\t\t     free_percpu(pool->recycle_stats);\n\t\t\t\t     free(pool) //free\n\n     spin_unlock(&r->producer_lock); //pool->ring uaf read\n  recycle_stat_inc(pool, ring);\n\npage_pool can be free while page pool recycle the last page in ring.\nAdd producer-lock barrier to page_pool_release to prevent the page\npool from being free before all pages have been recycled.\n\nrecycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is not\nenabled, which will trigger Wempty-body build warning. Add definition\nfor pool stat macro to fix warning.(CVE-2025-38129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Avoid using sk_socket after free when sending\n\nThe sk->sk_socket is not locked or referenced in backlog thread, and\nduring the call to skb_send_sock(), there is a race condition with\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\nwill be affected.\n\nRace conditions:\n'''\nCPU0                               CPU1\n\nbacklog::skb_send_sock\n  sendmsg_unlocked\n    sock_sendmsg\n      sock_sendmsg_nosec\n                                   close(fd):\n                                     ...\n                                     ops->release() -> sock_map_close()\n                                     sk_socket->ops = NULL\n                                     free(socket)\n      sock->ops->sendmsg\n            ^\n            panic here\n'''\n\nThe ref of psock become 0 after sock_map_close() executed.\n'''\nvoid sock_map_close()\n{\n    ...\n    if (likely(psock)) {\n    ...\n    // !! here we remove psock and the ref of psock become 0\n    sock_map_remove_links(sk, psock)\n    psock = sk_psock_get(sk);\n    if (unlikely(!psock))\n        goto no_psock; <=== Control jumps here via goto\n        ...\n        cancel_delayed_work_sync(&psock->work); <=== not executed\n        sk_psock_put(sk, psock);\n        ...\n}\n'''\n\nBased on the fact that we already wait for the workqueue to finish in\nsock_map_close() if psock is held, we simply increase the psock\nreference count to avoid race conditions.\n\nWith this patch, if the backlog thread is running, sock_map_close() will\nwait for the backlog thread to complete and cancel all pending work.\n\nIf no backlog running, any pending work that hasn't started by then will\nfail when invoked by sk_psock_get(), as the psock reference count have\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\ncancel_delayed_work_sync().\n\nIn summary, we require synchronization to coordinate the backlog thread\nand close() thread.\n\nThe panic I catched:\n'''\nWorkqueue: events sk_psock_backlog\nRIP: 0010:sock_sendmsg+0x21d/0x440\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\n...\nCall Trace:\n <TASK>\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x14c/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? sock_sendmsg+0x21d/0x440\n ? sock_sendmsg+0x3e0/0x440\n ? __pfx_sock_sendmsg+0x10/0x10\n __skb_send_sock+0x543/0xb70\n sk_psock_backlog+0x247/0xb80\n...\n'''(CVE-2025-38154)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix panic when calling skb_linearize\n\nThe panic can be reproduced by executing the command:\n./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000\n\nThen a kernel panic was captured:\n'''\n[  657.460555] kernel BUG at net/core/skbuff.c:2178!\n[  657.462680] Tainted: [W]=WARN\n[  657.463287] Workqueue: events sk_psock_backlog\n...\n[  657.469610]  <TASK>\n[  657.469738]  ? die+0x36/0x90\n[  657.469916]  ? do_trap+0x1d0/0x270\n[  657.470118]  ? pskb_expand_head+0x612/0xf40\n[  657.470376]  ? pskb_expand_head+0x612/0xf40\n[  657.470620]  ? do_error_trap+0xa3/0x170\n[  657.470846]  ? pskb_expand_head+0x612/0xf40\n[  657.471092]  ? handle_invalid_op+0x2c/0x40\n[  657.471335]  ? pskb_expand_head+0x612/0xf40\n[  657.471579]  ? exc_invalid_op+0x2d/0x40\n[  657.471805]  ? asm_exc_invalid_op+0x1a/0x20\n[  657.472052]  ? pskb_expand_head+0xd1/0xf40\n[  657.472292]  ? pskb_expand_head+0x612/0xf40\n[  657.472540]  ? lock_acquire+0x18f/0x4e0\n[  657.472766]  ? find_held_lock+0x2d/0x110\n[  657.472999]  ? __pfx_pskb_expand_head+0x10/0x10\n[  657.473263]  ? __kmalloc_cache_noprof+0x5b/0x470\n[  657.473537]  ? __pfx___lock_release.isra.0+0x10/0x10\n[  657.473826]  __pskb_pull_tail+0xfd/0x1d20\n[  657.474062]  ? __kasan_slab_alloc+0x4e/0x90\n[  657.474707]  sk_psock_skb_ingress_enqueue+0x3bf/0x510\n[  657.475392]  ? __kasan_kmalloc+0xaa/0xb0\n[  657.476010]  sk_psock_backlog+0x5cf/0xd70\n[  657.476637]  process_one_work+0x858/0x1a20\n'''\n\nThe panic originates from the assertion BUG_ON(skb_shared(skb)) in\nskb_linearize(). A previous commit(see Fixes tag) introduced skb_get()\nto avoid race conditions between skb operations in the backlog and skb\nrelease in the recvmsg path. However, this caused the panic to always\noccur when skb_linearize is executed.\n\nThe "--rx-strp 100000" parameter forces the RX path to use the strparser\nmodule which aggregates data until it reaches 100KB before calling sockmap\nlogic. The 100KB payload exceeds MAX_MSG_FRAGS, triggering skb_linearize.\n\nTo fix this issue, just move skb_get into sk_psock_skb_ingress_enqueue.\n\n'''\nsk_psock_backlog:\n    sk_psock_handle_skb\n       skb_get(skb) <== we move it into 'sk_psock_skb_ingress_enqueue'\n       sk_psock_skb_ingress____________\n                                       ↓\n                                       |\n                                       | → sk_psock_skb_ingress_self\n                                       |      sk_psock_skb_ingress_enqueue\nsk_psock_verdict_apply_________________↑          skb_linearize\n'''\n\nNote that for verdict_apply path, the skb_get operation is unnecessary so\nwe add 'take_ref' param to control it's behavior.(CVE-2025-38165)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix ktls panic with sockmap\n\n[ 2172.936997] ------------[ cut here ]------------\n[ 2172.936999] kernel BUG at lib/iov_iter.c:629!\n......\n[ 2172.944996] PKRU: 55555554\n[ 2172.945155] Call Trace:\n[ 2172.945299]  <TASK>\n[ 2172.945428]  ? die+0x36/0x90\n[ 2172.945601]  ? do_trap+0xdd/0x100\n[ 2172.945795]  ? iov_iter_revert+0x178/0x180\n[ 2172.946031]  ? iov_iter_revert+0x178/0x180\n[ 2172.946267]  ? do_error_trap+0x7d/0x110\n[ 2172.946499]  ? iov_iter_revert+0x178/0x180\n[ 2172.946736]  ? exc_invalid_op+0x50/0x70\n[ 2172.946961]  ? iov_iter_revert+0x178/0x180\n[ 2172.947197]  ? asm_exc_invalid_op+0x1a/0x20\n[ 2172.947446]  ? iov_iter_revert+0x178/0x180\n[ 2172.947683]  ? iov_iter_revert+0x5c/0x180\n[ 2172.947913]  tls_sw_sendmsg_locked.isra.0+0x794/0x840\n[ 2172.948206]  tls_sw_sendmsg+0x52/0x80\n[ 2172.948420]  ? inet_sendmsg+0x1f/0x70\n[ 2172.948634]  __sys_sendto+0x1cd/0x200\n[ 2172.948848]  ? find_held_lock+0x2b/0x80\n[ 2172.949072]  ? syscall_trace_enter+0x140/0x270\n[ 2172.949330]  ? __lock_release.isra.0+0x5e/0x170\n[ 2172.949595]  ? find_held_lock+0x2b/0x80\n[ 2172.949817]  ? syscall_trace_enter+0x140/0x270\n[ 2172.950211]  ? lockdep_hardirqs_on_prepare+0xda/0x190\n[ 2172.950632]  ? ktime_get_coarse_real_ts64+0xc2/0xd0\n[ 2172.951036]  __x64_sys_sendto+0x24/0x30\n[ 2172.951382]  do_syscall_64+0x90/0x170\n......\n\nAfter calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase,\ne.g., when the BPF program executes bpf_msg_push_data().\n\nIf the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,\nit will return -ENOSPC and attempt to roll back to the non-zero copy\nlogic. However, during rollback, msg->msg_iter is reset, but since\nmsg_pl->sg.size has been increased, subsequent executions will exceed the\nactual size of msg_iter.\n'''\niov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size);\n'''\n\nThe changes in this commit are based on the following considerations:\n\n1. When cork_bytes is set, rolling back to non-zero copy logic is\npointless and can directly go to zero-copy logic.\n\n2. We can not calculate the correct number of bytes to revert msg_iter.\n\nAssume the original data is "abcdefgh" (8 bytes), and after 3 pushes\nby the BPF program, it becomes 11-byte data: "abc?de?fgh?".\nThen, we set cork_bytes to 6, which means the first 6 bytes have been\nprocessed, and the remaining 5 bytes "?fgh?" will be cached until the\nlength meets the cork_bytes requirement.\n\nHowever, some data in "?fgh?" is not within 'sg->msg_iter'\n(but in msg_pl instead), especially the data "?" we pushed.\n\nSo it doesn't seem as simple as just reverting through an offset of\nmsg_iter.\n\n3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs,\nthe user-space send() doesn't return an error, and the returned length is\nthe same as the input length parameter, even if some data is cached.\n\nAdditionally, I saw that the current non-zero-copy logic for handling\ncorking is written as:\n'''\nline 1177\nelse if (ret != -EAGAIN) {\n\tif (ret == -ENOSPC)\n\t\tret = 0;\n\tgoto send_end;\n'''\n\nSo it's ok to just return 'copied' without error when a "cork" situation\noccurs.(CVE-2025-38166)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_hfsc: make hfsc_qlen_notify() idempotent\n\nhfsc_qlen_notify() is not idempotent either and not friendly\nto its callers, like fq_codel_dequeue(). Let's make it idempotent\nto ease qdisc_tree_reduce_backlog() callers' life:\n\n1. update_vf() decreases cl->cl_nactive, so we can check whether it is\nnon-zero before calling it.\n\n2. eltree_remove() always removes RB node cl->el_node, but we can use\n   RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.(CVE-2025-38177)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX\n\nOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()\nwhen resizing hashtable because __GFP_NOWARN is unset.\n\nSimilar to:\n\n  b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush\n\nIn KVM guests with Hyper-V hypercalls enabled, the hypercalls\nHVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX\nallow a guest to request invalidation of portions of a virtual TLB.\nFor this, the hypercall parameter includes a list of GVAs that are supposed\nto be invalidated.\n\nHowever, when non-canonical GVAs are passed, there is currently no\nfiltering in place and they are eventually passed to checked invocations of\nINVVPID on Intel / INVLPGA on AMD.  While AMD's INVLPGA silently ignores\nnon-canonical addresses (effectively a no-op), Intel's INVVPID explicitly\nsignals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():\n\n  invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000\n  WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482\n  invvpid_error+0x91/0xa0 [kvm_intel]\n  Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse\n  CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)\n  RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]\n  Call Trace:\n    vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]\n    kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]\n    kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]\n\nHyper-V documents that invalid GVAs (those that are beyond a partition's\nGVA space) are to be ignored.  While not completely clear whether this\nruling also applies to non-canonical GVAs, it is likely fine to make that\nassumption, and manual testing on Azure confirms "real" Hyper-V interprets\nthe specification in the same way.\n\nSkip non-canonical GVAs when processing the list of address to avoid\ntripping the INVVPID failure.  Alternatively, KVM could filter out "bad"\nGVAs before inserting into the FIFO, but practically speaking the only\ndownside of pushing validation to the final processing is that doing so\nis suboptimal for the guest, and no well-behaved guest will request TLB\nflushes for non-canonical addresses.(CVE-2025-38351)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks\n\nAfter retrieving WMI data blocks in sysfs callbacks, check for the\nvalidity of them before dereferencing their content.(CVE-2025-38412)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: do not bypass hid_hw_raw_request\n\nhid_hw_raw_request() is actually useful to ensure the provided buffer\nand length are valid. Directly calling in the low level transport driver\nfunction bypassed those checks and allowed invalid paramto be used.(CVE-2025-38494)\n\nIn the Linux kernel, the collect_md property of xfrm interfaces can only be set during device creation. However, the xfrmi_changelink() function failed to properly validate this when called. This resulted in the erroneous placement of the special interface xi in the xfrmi_net->xfrmi hash when attempting to modify a collect_md interface. Since it also exists in the xfrmi_net->collect_md_xfrmi pointer, this led to a double free when the net namespace was taken down, causing a kernel crash.(CVE-2025-38500)\n\nIn the Linux kernel, the wx_rx_buffer structure contained two DMA address fields: 'dma' and 'page_dma'. However, only 'page_dma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Although such error has not yet occurred, it is worth fixing in the code.(CVE-2025-38533)\n\nIn the Linux kernel, the following vulnerability has been resolved: HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras. The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-38540)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Prevent VMA split of buffer mappings\n\nThe perf mmap code is careful about mmap()'ing the user page with the\nringbuffer and additionally the auxiliary buffer, when the event supports\nit. Once the first mapping is established, subsequent mapping have to use\nthe same offset and the same size in both cases. The reference counting for\nthe ringbuffer and the auxiliary buffer depends on this being correct.\n\nThough perf does not prevent that a related mapping is split via mmap(2),\nmunmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls,\nwhich take reference counts, but then the subsequent perf_mmap_close()\ncalls are not longer fulfilling the offset and size checks. This leads to\nreference count leaks.\n\nAs perf already has the requirement for subsequent mappings to match the\ninitial mapping, the obvious consequence is that VMA splits, caused by\nresizing of a mapping or partial unmapping, have to be prevented.\n\nImplement the vm_operations_struct::may_split() callback and return\nunconditionally -EINVAL.\n\nThat ensures that the mapping offsets and sizes cannot be changed after the\nfact. Remapping to a different fixed address with the same size is still\npossible as it takes the references for the new mapping and drops those of\nthe old mapping.(CVE-2025-38563)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbenet: fix BUG when creating VFs\n\nbenet crashes as soon as SRIOV VFs are created:\n\n kernel BUG at mm/vmalloc.c:3457!\n Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary)\n [...]\n RIP: 0010:vunmap+0x5f/0x70\n [...]\n Call Trace:\n  <TASK>\n  __iommu_dma_free+0xe8/0x1c0\n  be_cmd_set_mac_list+0x3fe/0x640 [be2net]\n  be_cmd_set_mac+0xaf/0x110 [be2net]\n  be_vf_eth_addr_config+0x19f/0x330 [be2net]\n  be_vf_setup+0x4f7/0x990 [be2net]\n  be_pci_sriov_configure+0x3a1/0x470 [be2net]\n  sriov_numvfs_store+0x20b/0x380\n  kernfs_fop_write_iter+0x354/0x530\n  vfs_write+0x9b9/0xf60\n  ksys_write+0xf3/0x1d0\n  do_syscall_64+0x8c/0x3d0\n\nbe_cmd_set_mac_list() calls dma_free_coherent() under a spin_lock_bh.\nFix it by freeing only after the lock has been released.(CVE-2025-38569)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvmci: Prevent the dispatching of uninitialized payloads\n\nThe reproducer executes the host's unlocked_ioctl call in two different\ntasks. When init_context fails, the struct vmci_event_ctx is not fully\ninitialized when executing vmci_datagram_dispatch() to send events to all\nvm contexts. This affects the datagram taken from the datagram queue of\nits context by another task, because the datagram payload is not initialized\naccording to the size payload_size, which causes the kernel data to leak\nto the user space.\n\nBefore dispatching the datagram, and before setting the payload content,\nexplicitly set the payload content to 0 to avoid data leakage caused by\nincomplete payload initialization.(CVE-2025-38611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npinmux: fix race causing mux_owner NULL with active mux_usecount\n\ncommit 5a3e85c3c397 ("pinmux: Use sequential access to access\ndesc->pinmux data") tried to address the issue when two client of the\nsame gpio calls pinctrl_select_state() for the same functionality, was\nresulting in NULL pointer issue while accessing desc->mux_owner.\nHowever, issue was not completely fixed due to the way it was handled\nand it can still result in the same NULL pointer.\n\nThe issue occurs due to the following interleaving:\n\n     cpu0 (process A)                   cpu1 (process B)\n\n      pin_request() {                   pin_free() {\n\n                                         mutex_lock()\n                                         desc->mux_usecount--; //becomes 0\n                                         ..\n                                         mutex_unlock()\n\n  mutex_lock(desc->mux)\n  desc->mux_usecount++; // becomes 1\n  desc->mux_owner = owner;\n  mutex_unlock(desc->mux)\n\n                                         mutex_lock(desc->mux)\n                                         desc->mux_owner = NULL;\n                                         mutex_unlock(desc->mux)\n\nThis sequence leads to a state where the pin appears to be in use\n(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can\ncause NULL pointer on next pin_request on the same pin.\n\nEnsure that updates to mux_usecount and mux_owner are performed\natomically under the same lock. Only clear mux_owner when mux_usecount\nreaches zero and no new owner has been assigned.(CVE-2025-38632)\n\nIn the Linux kernel, a vulnerability has been resolved where checking proc_lseek in the same manner as proc_read_iter and others could lead to a Use-After-Free (UAF) scenario during rmmod. This was a gap in proc_reg_open() after commit 654b33ada4ab (proc: fix UAF in proc_get_inode()). Following AI Viro's suggestion, it was fixed in the same manner.(CVE-2025-38653)\n\nIn the Linux kernel, a vulnerability was found in the i2c: qup driver where the original logic only sets the return value but does not break out of the loop when the bus remains active due to a client. This unexpected behavior could allow a malicious or faulty i2c client to hang the kernel. The issue was observed during long-term testing with a PCA953x GPIO extender. The fix modifies the logic to not only set the return value but also break out of the loop and return -ETIMEDOUT to the caller.(CVE-2025-38671)","modified":"2026-03-11T07:11:47.164286Z","published":"2025-09-05T12:41:58Z","upstream":["CVE-2025-21678","CVE-2025-21723","CVE-2025-21864","CVE-2025-21955","CVE-2025-22007","CVE-2025-22021","CVE-2025-22056","CVE-2025-22057","CVE-2025-22063","CVE-2025-22064","CVE-2025-22086","CVE-2025-22089","CVE-2025-22106","CVE-2025-37749","CVE-2025-37752","CVE-2025-37772","CVE-2025-37789","CVE-2025-37794","CVE-2025-37829","CVE-2025-37834","CVE-2025-37859","CVE-2025-37875","CVE-2025-37879","CVE-2025-37885","CVE-2025-37909","CVE-2025-37911","CVE-2025-37912","CVE-2025-37932","CVE-2025-37945","CVE-2025-37959","CVE-2025-37960","CVE-2025-37961","CVE-2025-37989","CVE-2025-37990","CVE-2025-38003","CVE-2025-38004","CVE-2025-38010","CVE-2025-38019","CVE-2025-38020","CVE-2025-38022","CVE-2025-38024","CVE-2025-38039","CVE-2025-38042","CVE-2025-38044","CVE-2025-38057","CVE-2025-38066","CVE-2025-38085","CVE-2025-38087","CVE-2025-38097","CVE-2025-38129","CVE-2025-38154","CVE-2025-38165","CVE-2025-38166","CVE-2025-38177","CVE-2025-38201","CVE-2025-38351","CVE-2025-38412","CVE-2025-38494","CVE-2025-38500","CVE-2025-38533","CVE-2025-38540","CVE-2025-38563","CVE-2025-38569","CVE-2025-38611","CVE-2025-38632","CVE-2025-38653","CVE-2025-38671"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2122"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21678"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21723"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21864"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21955"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22007"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22056"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22057"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22063"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22064"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22086"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22089"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22106"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37749"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37752"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37772"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37789"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37794"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37829"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37834"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37859"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37875"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37879"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37885"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37909"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37911"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37912"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37932"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37945"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37959"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37960"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37961"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37989"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37990"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38003"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38004"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38010"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38019"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38020"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38022"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38024"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38039"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38042"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38044"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38057"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38066"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38085"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38087"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38097"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38129"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38154"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38165"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38166"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38177"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38201"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38351"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38412"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38494"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38500"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38533"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38540"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38563"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38569"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38611"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38632"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38653"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38671"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS-SP2","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP2"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-108.0.0.114.oe2403sp2"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","bpftool-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","kernel-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","kernel-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","kernel-debugsource-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","kernel-devel-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","kernel-extra-modules-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","kernel-headers-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","kernel-source-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","kernel-tools-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","kernel-tools-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","kernel-tools-devel-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","perf-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","perf-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","python3-perf-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm","python3-perf-debuginfo-6.6.0-108.0.0.114.oe2403sp2.aarch64.rpm"],"src":["kernel-6.6.0-108.0.0.114.oe2403sp2.src.rpm"],"x86_64":["bpftool-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","bpftool-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","kernel-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","kernel-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","kernel-debugsource-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","kernel-devel-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","kernel-extra-modules-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","kernel-headers-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","kernel-source-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","kernel-tools-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","kernel-tools-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","kernel-tools-devel-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","perf-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","perf-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","python3-perf-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm","python3-perf-debuginfo-6.6.0-108.0.0.114.oe2403sp2.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2025-2122.json"}}],"schema_version":"1.7.5"}