{"id":"OESA-2025-2081","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\nblk-mq: don't touch ->tagset in blk_mq_get_sq_hctx\n\nblk_mq_run_hw_queues() could be run when there isn't queued request and\nafter queue is cleaned up, at that time tagset is freed, because tagset\nlifetime is covered by driver, and often freed after blk_cleanup_queue()\nreturns.\n\nSo don't touch ->tagset for figuring out current default hctx by the mapping\nbuilt in request queue, so use-after-free on tagset can be avoided. Meantime\nthis way should be fast than retrieving mapping from tagset.(CVE-2022-49377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f ("net: allow out-of-order netdev unregistration")\nand commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem.(CVE-2022-49390)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: don't skip expired elements during walk\n\nThere is an asymmetry between commit/abort and preparation phase if the\nfollowing conditions are met:\n\n1. set is a verdict map ("1.2.3.4 : jump foo")\n2. timeouts are enabled\n\nIn this case, following sequence is problematic:\n\n1. element E in set S refers to chain C\n2. userspace requests removal of set S\n3. kernel does a set walk to decrement chain->use count for all elements\n   from preparation phase\n4. kernel does another set walk to remove elements from the commit phase\n   (or another walk to do a chain->use increment for all elements from\n    abort phase)\n\nIf E has already expired in 1), it will be ignored during list walk, so its use count\nwon't have been changed.\n\nThen, when set is culled, ->destroy callback will zap the element via\nnf_tables_set_elem_destroy(), but this function is only safe for\nelements that have been deactivated earlier from the preparation phase:\nlack of earlier deactivate removes the element but leaks the chain use\ncount, which results in a WARN splat when the chain gets removed later,\nplus a leak of the nft_chain structure.\n\nUpdate pipapo_get() not to skip expired elements, otherwise flush\ncommand reports bogus ENOENT errors.(CVE-2023-52924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm/fault: Fix kfence page fault reporting\n\ncopy_from_kernel_nofault() can be called when doing read of /proc/kcore.\n/proc/kcore can have some unmapped kfence objects which when read via\ncopy_from_kernel_nofault() can cause page faults. Since *_nofault()\nfunctions define their own fixup table for handling fault, use that\ninstead of asking kfence to handle such faults.\n\nHence we search the exception tables for the nip which generated the\nfault. If there is an entry then we let the fixup table handler handle the\npage fault by returning an error from within ___do_page_fault().\n\nThis can be easily triggered if someone tries to do dd from /proc/kcore.\neg. dd if=/proc/kcore of=/dev/null bs=1M\n\nSome example false negatives:\n\n  ===============================\n  BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0\n  Invalid read at 0xc0000000fdff0000:\n   copy_from_kernel_nofault+0x9c/0x1a0\n   0xc00000000665f950\n   read_kcore_iter+0x57c/0xa04\n   proc_reg_read_iter+0xe4/0x16c\n   vfs_read+0x320/0x3ec\n   ksys_read+0x90/0x154\n   system_call_exception+0x120/0x310\n   system_call_vectored_common+0x15c/0x2ec\n\n  BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0\n  Use-after-free read at 0xc0000000fe050000 (in kfence-#2):\n   copy_from_kernel_nofault+0x9c/0x1a0\n   0xc00000000665f950\n   read_kcore_iter+0x57c/0xa04\n   proc_reg_read_iter+0xe4/0x16c\n   vfs_read+0x320/0x3ec\n   ksys_read+0x90/0x154\n   system_call_exception+0x120/0x310\n   system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur\n\nThe action force umount(umount -f) will attempt to kill all rpc_task even\numount operation may ultimately fail if some files remain open.\nConsequently, if an action attempts to open a file, it can potentially\nsend two rpc_task to nfs server.\n\n                   NFS CLIENT\nthread1                             thread2\nopen("file")\n...\nnfs4_do_open\n _nfs4_do_open\n  _nfs4_open_and_get_state\n   _nfs4_proc_open\n    nfs4_run_open_task\n     /* rpc_task1 */\n     rpc_run_task\n     rpc_wait_for_completion_task\n\n                                    umount -f\n                                    nfs_umount_begin\n                                     rpc_killall_tasks\n                                      rpc_signal_task\n     rpc_task1 been wakeup\n     and return -512\n _nfs4_do_open // while loop\n    ...\n    nfs4_run_open_task\n     /* rpc_task2 */\n     rpc_run_task\n     rpc_wait_for_completion_task\n\nWhile processing an open request, nfsd will first attempt to find or\nallocate an nfs4_openowner. If it finds an nfs4_openowner that is not\nmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since\ntwo rpc_task can attempt to open the same file simultaneously from the\nclient to server, and because two instances of nfsd can run\nconcurrently, this situation can lead to lots of memory leak.\nAdditionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be\ntriggered.\n\n                    NFS SERVER\nnfsd1                  nfsd2       echo 0 > /proc/fs/nfsd/threads\n\nnfsd4_open\n nfsd4_process_open1\n  find_or_alloc_open_stateowner\n   // alloc oo1, stateid1\n                       nfsd4_open\n                        nfsd4_process_open1\n                        find_or_alloc_open_stateowner\n                        // find oo1, without NFS4_OO_CONFIRMED\n                         release_openowner\n                          unhash_openowner_locked\n                          list_del_init(&oo->oo_perclient)\n                          // cannot find this oo\n                          // from client, LEAK!!!\n                         alloc_stateowner // alloc oo2\n\n nfsd4_process_open2\n  init_open_stateid\n  // associate oo1\n  // with stateid1, stateid1 LEAK!!!\n  nfs4_get_vfs_file\n  // alloc nfsd_file1 and nfsd_file_mark1\n  // all LEAK!!!\n\n                         nfsd4_process_open2\n                         ...\n\n                                    write_threads\n                                     ...\n                                     nfsd_destroy_serv\n                                      nfsd_shutdown_net\n                                       nfs4_state_shutdown_net\n                                        nfs4_state_destroy_net\n                                         destroy_client\n                                          __destroy_client\n                                          // won't find oo1!!!\n                                     nfsd_shutdown_generic\n                                      nfsd_file_cache_shutdown\n                                       kmem_cache_destroy\n                                       for nfsd_file_slab\n                                       and nfsd_file_mark_slab\n                                       // bark since nfsd_file1\n                                       // and nfsd_file_mark1\n                                       // still alive\n\n=======================================================================\nBUG nfsd_file (Not tainted): Objects remaining in nfsd_file on\n__kmem_cache_shutdown()\n-----------------------------------------------------------------------\n\nSlab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28\nflags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)\nCPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nCall Trace:\n <TASK>\n dum\n---truncated---(CVE-2024-56779)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: state: fix out-of-bounds read during lookup\n\nlookup and resize can run in parallel.\n\nThe xfrm_state_hash_generation seqlock ensures a retry, but the hash\nfunctions can observe a hmask value that is too large for the new hlist\narray.\n\nrehash does:\n  rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..]\n  net->xfrm.state_hmask = nhashmask;\n\nWhile state lookup does:\n  h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family);\n  hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {\n\nThis is only safe in case the update to state_bydst is larger than\nnet->xfrm.xfrm_state_hmask (or if the lookup function gets\nserialized via state spinlock again).\n\nFix this by prefetching state_hmask and the associated pointers.\nThe xfrm_state_hash_generation seqlock retry will ensure that the pointer\nand the hmask will be consistent.\n\nThe existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,\nadd lockdep assertions to document that they are only safe for insert\nside.\n\nxfrm_state_lookup_byaddr() uses the spinlock rather than RCU.\nAFAICS this is an oversight from back when state lookup was converted to\nRCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/platform: check the bounds of read/write syscalls\n\ncount and offset are passed from user space and not checked, only\noffset is capped to 40 bits, which can be used to read/write out of\nbounds of the device.(CVE-2025-21687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: Fix NULL pointer dereference\n\nWhen MPOA_cache_impos_rcvd() receives the msg, it can trigger\nNull Pointer Dereference Vulnerability if both entry and\nholding_time are NULL. Because there is only for the situation\nwhere entry is NULL and holding_time exists, it can be passed\nwhen both entry and holding_time are NULL. If these are NULL,\nthe entry will be passd to eg_cache_put() as parameter and\nit is referenced by entry->use code in it.\n\nkasan log:\n\n[    3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I\n[    3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[    3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102\n[    3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n[    3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470\n[    3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80\n[    3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006\n[    3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e\n[    3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030\n[    3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88\n[    3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15\n[    3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068\n[    3.324185] FS:  000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000\n[    3.325042] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0\n[    3.326430] Call Trace:\n[    3.326725]  <TASK>\n[    3.326927]  ? die_addr+0x3c/0xa0\n[    3.327330]  ? exc_general_protection+0x161/0x2a0\n[    3.327662]  ? asm_exc_general_protection+0x26/0x30\n[    3.328214]  ? vprintk_emit+0x15e/0x420\n[    3.328543]  ? eg_cache_remove_entry+0xa5/0x470\n[    3.328910]  ? eg_cache_remove_entry+0x9a/0x470\n[    3.329294]  ? __pfx_eg_cache_remove_entry+0x10/0x10\n[    3.329664]  ? console_unlock+0x107/0x1d0\n[    3.329946]  ? __pfx_console_unlock+0x10/0x10\n[    3.330283]  ? do_syscall_64+0xa6/0x1a0\n[    3.330584]  ? entry_SYSCALL_64_after_hwframe+0x47/0x7f\n[    3.331090]  ? __pfx_prb_read_valid+0x10/0x10\n[    3.331395]  ? down_trylock+0x52/0x80\n[    3.331703]  ? vprintk_emit+0x15e/0x420\n[    3.331986]  ? __pfx_vprintk_emit+0x10/0x10\n[    3.332279]  ? down_trylock+0x52/0x80\n[    3.332527]  ? _printk+0xbf/0x100\n[    3.332762]  ? __pfx__printk+0x10/0x10\n[    3.333007]  ? _raw_write_lock_irq+0x81/0xe0\n[    3.333284]  ? __pfx__raw_write_lock_irq+0x10/0x10\n[    3.333614]  msg_from_mpoad+0x1185/0x2750\n[    3.333893]  ? __build_skb_around+0x27b/0x3a0\n[    3.334183]  ? __pfx_msg_from_mpoad+0x10/0x10\n[    3.334501]  ? __alloc_skb+0x1c0/0x310\n[    3.334809]  ? __pfx___alloc_skb+0x10/0x10\n[    3.335283]  ? _raw_spin_lock+0xe0/0xe0\n[    3.335632]  ? finish_wait+0x8d/0x1e0\n[    3.335975]  vcc_sendmsg+0x684/0xba0\n[    3.336250]  ? __pfx_vcc_sendmsg+0x10/0x10\n[    3.336587]  ? __pfx_autoremove_wake_function+0x10/0x10\n[    3.337056]  ? fdget+0x176/0x3e0\n[    3.337348]  __sys_sendto+0x4a2/0x510\n[    3.337663]  ? __pfx___sys_sendto+0x10/0x10\n[    3.337969]  ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400\n[    3.338364]  ? sock_ioctl+0x1bb/0x5a0\n[    3.338653]  ? __rseq_handle_notify_resume+0x825/0xd20\n[    3.339017]  ? __pfx_sock_ioctl+0x10/0x10\n[    3.339316]  ? __pfx___rseq_handle_notify_resume+0x10/0x10\n[    3.339727]  ? selinux_file_ioctl+0xa4/0x260\n[    3.340166]  __x64_sys_sendto+0xe0/0x1c0\n[    3.340526]  ? syscall_exit_to_user_mode+0x123/0x140\n[    3.340898]  do_syscall_64+0xa6/0x1a0\n[    3.341170]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[    3.341533] RIP: 0033:0x44a380\n[    3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00\n[    \n---truncated---(CVE-2025-22018)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix memory accounting leak.\n\nMatt Dowling reported a weird UDP memory usage issue.\n\nUnder normal operation, the UDP memory usage reported in /proc/net/sockstat\nremains close to zero.  However, it occasionally spiked to 524,288 pages\nand never dropped.  Moreover, the value doubled when the application was\nterminated.  Finally, it caused intermittent packet drops.\n\nWe can reproduce the issue with the script below [0]:\n\n  1. /proc/net/sockstat reports 0 pages\n\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 0\n\n  2. Run the script till the report reaches 524,288\n\n    # python3 test.py & sleep 5\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 3 mem 524288  <-- (INT_MAX + 1) >> PAGE_SHIFT\n\n  3. Kill the socket and confirm the number never drops\n\n    # pkill python3 && sleep 5\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 524288\n\n  4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()\n\n    # python3 test.py & sleep 1 && pkill python3\n\n  5. The number doubles\n\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 1048577\n\nThe application set INT_MAX to SO_RCVBUF, which triggered an integer\noverflow in udp_rmem_release().\n\nWhen a socket is close()d, udp_destruct_common() purges its receive\nqueue and sums up skb->truesize in the queue.  This total is calculated\nand stored in a local unsigned integer variable.\n\nThe total size is then passed to udp_rmem_release() to adjust memory\naccounting.  However, because the function takes a signed integer\nargument, the total size can wrap around, causing an overflow.\n\nThen, the released amount is calculated as follows:\n\n  1) Add size to sk->sk_forward_alloc.\n  2) Round down sk->sk_forward_alloc to the nearest lower multiple of\n      PAGE_SIZE and assign it to amount.\n  3) Subtract amount from sk->sk_forward_alloc.\n  4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().\n\nWhen the issue occurred, the total in udp_destruct_common() was 2147484480\n(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().\n\nAt 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and\n2) sets -2147479552 to amount.  3) reverts the wraparound, so we don't\nsee a warning in inet_sock_destruct().  However, udp_memory_allocated\nends up doubling at 4).\n\nSince commit 3cd3399dd7a8 ("net: implement per-cpu reserves for\nmemory_allocated"), memory usage no longer doubles immediately after\na socket is close()d because __sk_mem_reduce_allocated() caches the\namount in udp_memory_per_cpu_fw_alloc.  However, the next time a UDP\nsocket receives a packet, the subtraction takes effect, causing UDP\nmemory usage to double.\n\nThis issue makes further memory allocation fail once the socket's\nsk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet\ndrops.\n\nTo prevent this issue, let's use unsigned int for the calculation and\ncall sk_forward_alloc_add() only once for the small delta.\n\nNote that first_packet_length() also potentially has the same problem.\n\n[0]:\nfrom socket import *\n\nSO_RCVBUFFORCE = 33\nINT_MAX = (2 ** 31) - 1\n\ns = socket(AF_INET, SOCK_DGRAM)\ns.bind(('', 0))\ns.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)\n\nc = socket(AF_INET, SOCK_DGRAM)\nc.connect(s.getsockname())\n\ndata = b'a' * 100\n\nwhile True:\n    c.send(data)(CVE-2025-22058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtnetlink: Allocate vfinfo size for VF GUIDs when supported\n\nCommit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")\nadded support for getting VF port and node GUIDs in netlink ifinfo\nmessages, but their size was not taken into consideration in the\nfunction that allocates the netlink message, causing the following\nwarning when a netlink message is filled with many VF port and node\nGUIDs:\n # echo 64 > /sys/bus/pci/devices/0000\\:08\\:00.0/sriov_numvfs\n # ip link show dev ib0\n RTNETLINK answers: Message too long\n Cannot send link get request: Message too long\n\nKernel warning:\n\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0\n Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core\n CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:rtnl_getlink+0x586/0x5a0\n Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00\n RSP: 0018:ffff888113557348 EFLAGS: 00010246\n RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000\n RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8\n RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000\n R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00\n R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff\n FS:  00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n  <TASK>\n  ? __warn+0xa5/0x230\n  ? rtnl_getlink+0x586/0x5a0\n  ? report_bug+0x22d/0x240\n  ? handle_bug+0x53/0xa0\n  ? exc_invalid_op+0x14/0x50\n  ? asm_exc_invalid_op+0x16/0x20\n  ? skb_trim+0x6a/0x80\n  ? rtnl_getlink+0x586/0x5a0\n  ? __pfx_rtnl_getlink+0x10/0x10\n  ? rtnetlink_rcv_msg+0x1e5/0x860\n  ? __pfx___mutex_lock+0x10/0x10\n  ? rcu_is_watching+0x34/0x60\n  ? __pfx_lock_acquire+0x10/0x10\n  ? stack_trace_save+0x90/0xd0\n  ? filter_irq_stacks+0x1d/0x70\n  ? kasan_save_stack+0x30/0x40\n  ? kasan_save_stack+0x20/0x40\n  ? kasan_save_track+0x10/0x30\n  rtnetlink_rcv_msg+0x21c/0x860\n  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n  ? arch_stack_walk+0x9e/0xf0\n  ? rcu_is_watching+0x34/0x60\n  ? lock_acquire+0xd5/0x410\n  ? rcu_is_watching+0x34/0x60\n  netlink_rcv_skb+0xe0/0x210\n  ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n  ? __pfx_netlink_rcv_skb+0x10/0x10\n  ? rcu_is_watching+0x34/0x60\n  ? __pfx___netlink_lookup+0x10/0x10\n  ? lock_release+0x62/0x200\n  ? netlink_deliver_tap+0xfd/0x290\n  ? rcu_is_watching+0x34/0x60\n  ? lock_release+0x62/0x200\n  ? netlink_deliver_tap+0x95/0x290\n  netlink_unicast+0x31f/0x480\n  ? __pfx_netlink_unicast+0x10/0x10\n  ? rcu_is_watching+0x34/0x60\n  ? lock_acquire+0xd5/0x410\n  netlink_sendmsg+0x369/0x660\n  ? lock_release+0x62/0x200\n  ? __pfx_netlink_sendmsg+0x10/0x10\n  ? import_ubuf+0xb9/0xf0\n  ? __import_iovec+0x254/0x2b0\n  ? lock_release+0x62/0x200\n  ? __pfx_netlink_sendmsg+0x10/0x10\n  ____sys_sendmsg+0x559/0x5a0\n  ? __pfx_____sys_sendmsg+0x10/0x10\n  ? __pfx_copy_msghdr_from_user+0x10/0x10\n  ? rcu_is_watching+0x34/0x60\n  ? do_read_fault+0x213/0x4a0\n  ? rcu_is_watching+0x34/0x60\n  ___sys_sendmsg+0xe4/0x150\n  ? __pfx____sys_sendmsg+0x10/0x10\n  ? do_fault+0x2cc/0x6f0\n  ? handle_pte_fault+0x2e3/0x3d0\n  ? __pfx_handle_pte_fault+0x10/0x10\n---truncated---(CVE-2025-22075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisofs: Prevent the use of too small fid\n\nsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]\n\nThe handle_bytes value passed in by the reproducing program is equal to 12.\nIn handle_to_path(), only 12 bytes of memory are allocated for the structure\nfile_handle->f_handle member, which causes an out-of-bounds access when\naccessing the member parent_block of the structure isofs_fid in isofs,\nbecause accessing parent_block requires at least 16 bytes of f_handle.\nHere, fh_len is used to indirectly confirm that the value of handle_bytes\nis greater than 3 before accessing parent_block.\n\n[1]\nBUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\nRead of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466\nCPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025\nCall trace:\n show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0x198/0x550 mm/kasan/report.c:521\n kasan_report+0xd8/0x138 mm/kasan/report.c:634\n __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380\n isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\n exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523\n do_handle_to_path+0xa0/0x198 fs/fhandle.c:257\n handle_to_path fs/fhandle.c:385 [inline]\n do_handle_open+0x8cc/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n\nAllocated by task 6466:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x40/0x78 mm/kasan/common.c:68\n kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4294 [inline]\n __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306\n kmalloc_noprof include/linux/slab.h:905 [inline]\n handle_to_path fs/fhandle.c:357 [inline]\n do_handle_open+0x5a4/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600(CVE-2025-37780)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class handling\n\nThis patch fixes a Use-After-Free vulnerability in the HFSC qdisc class\nhandling. The issue occurs due to a time-of-check/time-of-use condition\nin hfsc_change_class() when working with certain child qdiscs like netem\nor codel.\n\nThe vulnerability works as follows:\n1. hfsc_change_class() checks if a class has packets (q.qlen != 0)\n2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,\n   codel, netem) might drop packets and empty the queue\n3. The code continues assuming the queue is still non-empty, adding\n   the class to vttree\n4. This breaks HFSC scheduler assumptions that only non-empty classes\n   are in vttree\n5. Later, when the class is destroyed, this can lead to a Use-After-Free\n\nThe fix adds a second queue length check after qdisc_peek_len() to verify\nthe queue wasn't emptied.(CVE-2025-37797)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc\n\nAs described in Gerrard's report [1], we have a UAF case when an hfsc class\nhas a netem child qdisc. The crux of the issue is that hfsc is assuming\nthat checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted\nthe class in the vttree or eltree (which is not true for the netem\nduplicate case).\n\nThis patch checks the n_active class variable to make sure that the code\nwon't insert the class in the vttree or eltree twice, catering for the\nreentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37890)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()\n\nWhen enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the\nchild qdisc's peek() operation before incrementing sch->q.qlen and\nsch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may\ntrigger an immediate dequeue and potential packet drop. In such cases,\nqdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog\nhave not yet been updated, leading to inconsistent queue accounting. This\ncan leave an empty HFSC class in the active list, causing further\nconsequences like use-after-free.\n\nThis patch fixes the bug by moving the increment of sch->q.qlen and\nsch->qstats.backlog before the call to the child qdisc's peek() operation.\nThis ensures that queue length and backlog are always accurate when packet\ndrops or dequeues are triggered during the peek.(CVE-2025-38000)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Address reentrant enqueue adding class to eltree twice\n\nSavino says:\n    "We are writing to report that this recent patch\n    (141d34391abbb315d68556b7c67ad97885407547) [1]\n    can be bypassed, and a UAF can still occur when HFSC is utilized with\n    NETEM.\n\n    The patch only checks the cl->cl_nactive field to determine whether\n    it is the first insertion or not [2], but this field is only\n    incremented by init_vf [3].\n\n    By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the\n    check and insert the class twice in the eltree.\n    Under normal conditions, this would lead to an infinite loop in\n    hfsc_dequeue for the reasons we already explained in this report [5].\n\n    However, if TBF is added as root qdisc and it is configured with a\n    very low rate,\n    it can be utilized to prevent packets from being dequeued.\n    This behavior can be exploited to perform subsequent insertions in the\n    HFSC eltree and cause a UAF."\n\nTo fix both the UAF and the infinite loop, with netem as an hfsc child,\ncheck explicitly in hfsc_enqueue whether the class is already in the eltree\nwhenever the HFSC_RSC flag is set.\n\n[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547\n[2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572\n[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677\n[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574\n[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u(CVE-2025-38001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\n\nSyzbot reported a slab-use-after-free with the following call trace:\n\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n  Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25\n\n  Call Trace:\n   kasan_report+0xd9/0x110 mm/kasan/report.c:601\n   tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n   crypto_request_complete include/crypto/algapi.h:266\n   aead_request_complete include/crypto/internal/aead.h:85\n   cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772\n   crypto_request_complete include/crypto/algapi.h:266\n   cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181\n   process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\n  Allocated by task 8355:\n   kzalloc_noprof include/linux/slab.h:778\n   tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466\n   tipc_init_net+0x2dd/0x430 net/tipc/core.c:72\n   ops_init+0xb9/0x650 net/core/net_namespace.c:139\n   setup_net+0x435/0xb40 net/core/net_namespace.c:343\n   copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508\n   create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110\n   unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228\n   ksys_unshare+0x419/0x970 kernel/fork.c:3323\n   __do_sys_unshare kernel/fork.c:3394\n\n  Freed by task 63:\n   kfree+0x12a/0x3b0 mm/slub.c:4557\n   tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539\n   tipc_exit_net+0x8c/0x110 net/tipc/core.c:119\n   ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173\n   cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640\n   process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\nAfter freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done\nmay still visit it in cryptd_queue_worker workqueue.\n\nI reproduce this issue by:\n  ip netns add ns1\n  ip link add veth1 type veth peer name veth2\n  ip link set veth1 netns ns1\n  ip netns exec ns1 tipc bearer enable media eth dev veth1\n  ip netns exec ns1 tipc node set key this_is_a_master_key master\n  ip netns exec ns1 tipc bearer disable media eth dev veth1\n  ip netns del ns1\n\nThe key of reproduction is that, simd_aead_encrypt is interrupted, leading\nto crypto_simd_usable() return false. Thus, the cryptd_queue_worker is\ntriggered, and the tipc_crypto tx will be visited.\n\n  tipc_disc_timeout\n    tipc_bearer_xmit_skb\n      tipc_crypto_xmit\n        tipc_aead_encrypt\n          crypto_aead_encrypt\n            // encrypt()\n            simd_aead_encrypt\n              // crypto_simd_usable() is false\n              child = &ctx->cryptd_tfm->base;\n\n  simd_aead_encrypt\n    crypto_aead_encrypt\n      // encrypt()\n      cryptd_aead_encrypt_enqueue\n        cryptd_aead_enqueue\n          cryptd_enqueue_request\n            // trigger cryptd_queue_worker\n            queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work)\n\nFix this by holding net reference count before encrypt.(CVE-2025-38052)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38115)\n\nLinux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States.\n There is a security vulnerability in Linux kernel, which originates from improper processing of udp gso segmentation, which may lead to memory corruption.(CVE-2025-38124)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer\n\nThe reproduction steps:\n1. create a tun interface\n2. enable l2 bearer\n3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun\n\ntipc: Started in network mode\ntipc: Node identity 8af312d38a21, cluster identity 4711\ntipc: Enabled bearer <eth:syz_tun>, priority 1\nOops: general protection fault\nKASAN: null-ptr-deref in range\nCPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT\nHardware name: QEMU Ubuntu 24.04 PC\nRIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0\n\nthe ub was in fact a struct dev.\n\nwhen bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or\nother media when other thread changes it.\n\nfix this by checking media_id.(CVE-2025-38184)\n\nA vulnerability classified as critical has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc1 (Operating System).CWE is classifying the issue as CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.This is going to have an impact on availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc2 eliminates this vulnerability. Applying the patch bfa4d86e130a09f67607482e988313430e38f6c4/2a3ad42a57b43145839f2f233fb562247658a6d9/e9994e7b9f7bbb882d13c8191731649249150d21/ba9db6f907ac02215e30128770f85fbd7db2fcf9 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20064).(CVE-2025-38192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1: Fix stack memory use after return in raid1_reshape\n\nIn the raid1_reshape function, newpool is\nallocated on the stack and assigned to conf->r1bio_pool.\nThis results in conf->r1bio_pool.wait.head pointing\nto a stack address.\nAccessing this address later can lead to a kernel panic.\n\nExample access path:\n\nraid1_reshape()\n{\n\t// newpool is on the stack\n\tmempool_t newpool, oldpool;\n\t// initialize newpool.wait.head to stack address\n\tmempool_init(&newpool, ...);\n\tconf->r1bio_pool = newpool;\n}\n\nraid1_read_request() or raid1_write_request()\n{\n\talloc_r1bio()\n\t{\n\t\tmempool_alloc()\n\t\t{\n\t\t\t// if pool->alloc fails\n\t\t\tremove_element()\n\t\t\t{\n\t\t\t\t--pool->curr_nr;\n\t\t\t}\n\t\t}\n\t}\n}\n\nmempool_free()\n{\n\tif (pool->curr_nr < pool->min_nr) {\n\t\t// pool->wait.head is a stack address\n\t\t// wake_up() will try to access this invalid address\n\t\t// which leads to a kernel panic\n\t\treturn;\n\t\twake_up(&pool->wait);\n\t}\n}\n\nFix:\nreinit conf->r1bio_pool.wait after assigning newpool.(CVE-2025-38445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free in tipc_conn_close().\n\nsyzbot reported a null-ptr-deref in tipc_conn_close() during netns\ndismantle. [0]\n\ntipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls\ntipc_conn_close() for each tipc_conn.\n\nThe problem is that tipc_conn_close() is called after releasing the\nIDR lock.\n\nAt the same time, there might be tipc_conn_recv_work() running and it\ncould call tipc_conn_close() for the same tipc_conn and release its\nlast ->kref.\n\nOnce we release the IDR lock in tipc_topsrv_stop(), there is no\nguarantee that the tipc_conn is alive.\n\nLet's hold the ref before releasing the lock and put the ref after\ntipc_conn_close() in tipc_topsrv_stop().\n\n[0]:\nBUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165\nRead of size 8 at addr ffff888099305a08 by task kworker/u4:3/435\n\nCPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: netns cleanup_net\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x1fc/0x2ef lib/dump_stack.c:118\n print_address_description.cold+0x54/0x219 mm/kasan/report.c:256\n kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354\n kasan_report mm/kasan/report.c:412 [inline]\n __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433\n tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165\n tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]\n tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722\n ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153\n cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nAllocated by task 23:\n kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625\n kmalloc include/linux/slab.h:515 [inline]\n kzalloc include/linux/slab.h:709 [inline]\n tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192\n tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nFreed by task 23:\n __cache_free mm/slab.c:3503 [inline]\n kfree+0xcc/0x210 mm/slab.c:3822\n tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]\n kref_put include/linux/kref.h:70 [inline]\n conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nThe buggy address belongs to the object at ffff888099305a00\n which belongs to the cache kmalloc-512 of size 512\nThe buggy address is located 8 bytes inside of\n 512-byte region [ffff888099305a00, ffff888099305c00)\nThe buggy address belongs to the page:\npage:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0\nflags: 0xfff00000000100(slab)\nraw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940\nraw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n>ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                      ^\n ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb(CVE-2025-38464)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc5 (Operating System). It has been classified as problematic.CWE is classifying the issue as CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 9da025150b7c14a8390fc06aea314c0a4011e82c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98/fd69af06101090eaa60b3d216ae715f9c0a58e5b/76602d8e13864524382b0687dc32cd8f19164d5a/55baecb9eb90238f60a8350660d6762046ebd3bd/4b8e18af7bea92f8b7fb92d40aeae729209db250/cd7ff61bfffd7000143c42bbffb85eeb792466d6/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38465)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add down_write(trace_event_sem) when adding trace event\n\nWhen a module is loaded, it adds trace events defined by the module. It\nmay also need to modify the modules trace printk formats to replace enum\nnames with their values.\n\nIf two modules are loaded at the same time, the adding of the event to the\nftrace_events list can corrupt the walking of the list in the code that is\nmodifying the printk format strings and crash the kernel.\n\nThe addition of the event should take the trace_event_sem for write while\nit adds the new event.\n\nAlso add a lockdep_assert_held() on that semaphore in\n__trace_add_event_dirs() as it iterates the list.(CVE-2025-38539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Exit early on perf_mmap() fail\n\nWhen perf_mmap() fails to allocate a buffer, it still invokes the\nevent_mapped() callback of the related event. On X86 this might increase\nthe perf_rdpmc_allowed reference counter. But nothing undoes this as\nperf_mmap_close() is never called in this case, which causes another\nreference count leak.\n\nReturn early on failure to prevent that.(CVE-2025-38565)\n\nA vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.100/6.12.40/6.15.8 (Operating System).Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 6.6.101, 6.12.41 or 6.15.9 eliminates this vulnerability. Applying the patch 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61/708fd522b86d2a9544c34ec6a86fa3fc23336525/0f67015d72627bad72da3c2084352e0aa134416b/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38670)","modified":"2025-09-03T06:31:03.470653Z","published":"2025-08-29T11:17:50Z","upstream":["CVE-2022-49377","CVE-2022-49390","CVE-2023-52924","CVE-2024-56678","CVE-2024-56779","CVE-2024-57982","CVE-2024-58069","CVE-2025-21687","CVE-2025-22018","CVE-2025-22058","CVE-2025-22075","CVE-2025-37780","CVE-2025-37797","CVE-2025-37890","CVE-2025-38000","CVE-2025-38001","CVE-2025-38052","CVE-2025-38115","CVE-2025-38124","CVE-2025-38184","CVE-2025-38192","CVE-2025-38445","CVE-2025-38464","CVE-2025-38465","CVE-2025-38539","CVE-2025-38565","CVE-2025-38670"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2081"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49377"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49390"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52924"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56678"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56779"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57982"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58069"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21687"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22018"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22058"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22075"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37780"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37797"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37890"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38000"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38001"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38052"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38115"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38124"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38184"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38192"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38445"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38464"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38465"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38539"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38565"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38670"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:22.03-LTS-SP3","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-22.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-279.0.0.181.oe2203sp3"}]}],"ecosystem_specific":{"src":["kernel-5.10.0-279.0.0.181.oe2203sp3.src.rpm"],"aarch64":["kernel-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","kernel-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","kernel-debugsource-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","kernel-devel-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","kernel-headers-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","kernel-source-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","kernel-tools-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","kernel-tools-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","kernel-tools-devel-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","perf-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","python3-perf-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm","python3-perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm"],"x86_64":["kernel-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","kernel-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","kernel-debugsource-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","kernel-devel-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","kernel-headers-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","kernel-source-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","kernel-tools-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","kernel-tools-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","kernel-tools-devel-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","perf-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","python3-perf-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm","python3-perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2025-2081.json"}}],"schema_version":"1.7.3"}