{"schema_version":"1.7.2","id":"OESA-2026-1566","modified":"2026-03-15T05:54:11Z","published":"2026-03-15T05:54:11Z","upstream":["CVE-2024-57974","CVE-2025-22090","CVE-2025-38491","CVE-2025-38627","CVE-2025-38660","CVE-2025-39764","CVE-2025-39902","CVE-2025-39948","CVE-2025-40323","CVE-2025-40329","CVE-2025-68192","CVE-2025-68194","CVE-2025-68204","CVE-2025-68209","CVE-2025-68211","CVE-2025-68231","CVE-2025-68237","CVE-2025-68282","CVE-2025-68293","CVE-2025-68313","CVE-2025-68768","CVE-2025-68785","CVE-2025-68819","CVE-2025-68822","CVE-2025-71065","CVE-2025-71068","CVE-2025-71083","CVE-2025-71084","CVE-2025-71091","CVE-2025-71096","CVE-2025-71097","CVE-2025-71118","CVE-2025-71120","CVE-2025-71129","CVE-2025-71141","CVE-2025-71186","CVE-2025-71220","CVE-2025-71221","CVE-2025-71223","CVE-2025-71225","CVE-2025-71232","CVE-2025-71235","CVE-2025-71236","CVE-2026-22977","CVE-2026-22979","CVE-2026-22984","CVE-2026-22991","CVE-2026-22999","CVE-2026-23003","CVE-2026-23010","CVE-2026-23011","CVE-2026-23021","CVE-2026-23025","CVE-2026-23032","CVE-2026-23038","CVE-2026-23047","CVE-2026-23050","CVE-2026-23054","CVE-2026-23059","CVE-2026-23084","CVE-2026-23085","CVE-2026-23094","CVE-2026-23097","CVE-2026-23110","CVE-2026-23112","CVE-2026-23163","CVE-2026-23179","CVE-2026-23190","CVE-2026-23193","CVE-2026-23205","CVE-2026-23216","CVE-2026-23220","CVE-2026-23228"],"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\nudp: Deal with race between UDP socket address change and rehash\n\nIf a UDP socket changes its local address while it's receiving\ndatagrams, as a result of connect(), there is a period during which\na lookup operation might fail to find it, after the address is changed\nbut before the secondary hash (port and address) and the four-tuple\nhash (local and remote ports and addresses) are updated.\n\nSecondary hash chains were introduced by commit 30fff9231fad ("udp:\nbind() optimisation") and, as a result, a rehash operation became\nneeded to make a bound socket reachable again after a connect().\n\nThis operation was introduced by commit 719f835853a9 ("udp: add\nrehash on connect()") which isn't however a complete fix: the\nsocket will be found once the rehashing completes, but not while\nit's pending.\n\nThis is noticeable with a socat(1) server in UDP4-LISTEN mode, and a\nclient sending datagrams to it. After the server receives the first\ndatagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to\nthe address of the sender, in order to set up a directed flow.\n\nNow, if the client, running on a different CPU thread, happens to\nsend a (subsequent) datagram while the server's socket changes its\naddress, but is not rehashed yet, this will result in a failed\nlookup and a port unreachable error delivered to the client, as\napparent from the following reproducer:\n\n  LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4))\n  dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in\n\n  while :; do\n  \ttaskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc &\n  \tsleep 0.1 || sleep 1\n  \ttaskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null\n  \twait\n  done\n\nwhere the client will eventually get ECONNREFUSED on a write()\n(typically the second or third one of a given iteration):\n\n  2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused\n\nThis issue was first observed as a seldom failure in Podman's tests\nchecking UDP functionality while using pasta(1) to connect the\ncontainer's network namespace, which leads us to a reproducer with\nthe lookup error resulting in an ICMP packet on a tap device:\n\n  LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')"\n\n  while :; do\n  \t./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc &\n  \tsleep 0.2 || sleep 1\n  \tsocat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null\n  \twait\n  \tcmp tmp.in tmp.out\n  done\n\nOnce this fails:\n\n  tmp.in tmp.out differ: char 8193, line 29\n\nwe can finally have a look at what's going on:\n\n  $ tshark -r pasta.pcap\n      1   0.000000           :: ? ff02::16     ICMPv6 110 Multicast Listener Report Message v2\n      2   0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n      3   0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n      4   0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n      5   0.168827 c6:47:05:8d:dc:04 ? Broadcast    ARP 42 Who has 88.198.0.161? Tell 88.198.0.164\n      6   0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55\n      7   0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n      8   0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable)\n      9   0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n     10   0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192\n     11   0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096\n     12   0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0\n\nOn the third datagram received, the network namespace of the container\ninitiates an ARP lookup to deliver the ICMP message.\n\nIn another variant of this reproducer, starting the client with:\n\n  strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru\n---truncated---(CVE-2024-57974)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()\n\nIf track_pfn_copy() fails, we already added the dst VMA to the maple\ntree. As fork() fails, we'll cleanup the maple tree, and stumble over\nthe dst VMA for which we neither performed any reservation nor copied\nany page tables.\n\nConsequently untrack_pfn() will see VM_PAT and try obtaining the\nPAT information from the page table -- which fails because the page\ntable was not copied.\n\nThe easiest fix would be to simply clear the VM_PAT flag of the dst VMA\nif track_pfn_copy() fails. However, the whole thing is about "simply"\nclearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()\nand performed a reservation, but copying the page tables fails, we'll\nsimply clear the VM_PAT flag, not properly undoing the reservation ...\nwhich is also wrong.\n\nSo let's fix it properly: set the VM_PAT flag only if the reservation\nsucceeded (leaving it clear initially), and undo the reservation if\nanything goes wrong while copying the page tables: clearing the VM_PAT\nflag after undoing the reservation.\n\nNote that any copied page table entries will get zapped when the VMA will\nget removed later, after copy_page_range() succeeded; as VM_PAT is not set\nthen, we won't try cleaning VM_PAT up once more and untrack_pfn() will be\nhappy. Note that leaving these page tables in place without a reservation\nis not a problem, as we are aborting fork(); this process will never run.\n\nA reproducer can trigger this usually at the first try:\n\n  https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c\n\n  WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110\n  Modules linked in: ...\n  CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\n  RIP: 0010:get_pat_info+0xf6/0x110\n  ...\n  Call Trace:\n   <TASK>\n   ...\n   untrack_pfn+0x52/0x110\n   unmap_single_vma+0xa6/0xe0\n   unmap_vmas+0x105/0x1f0\n   exit_mmap+0xf6/0x460\n   __mmput+0x4b/0x120\n   copy_process+0x1bf6/0x2aa0\n   kernel_clone+0xab/0x440\n   __do_sys_clone+0x66/0x90\n   do_syscall_64+0x95/0x180\n\nLikely this case was missed in:\n\n  d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")\n\n... and instead of undoing the reservation we simply cleared the VM_PAT flag.\n\nKeep the documentation of these functions in include/linux/pgtable.h,\none place is more than sufficient -- we should clean that up for the other\nfunctions like track_pfn_remap/untrack_pfn separately.(CVE-2025-22090)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: make fallback action and fallback decision atomic\n\nSyzkaller reported the following splat:\n\n  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline]\n  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline]\n  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline]\n  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153\n  Modules linked in:\n  CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary)\n  Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n  RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline]\n  RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline]\n  RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline]\n  RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153\n  Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00\n  RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246\n  RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45\n  RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001\n  RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\n  R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000\n  FS:  00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0\n  Call Trace:\n   <IRQ>\n   tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432\n   tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975\n   tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166\n   tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925\n   tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363\n   ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205\n   ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233\n   NF_HOOK include/linux/netfilter.h:317 [inline]\n   NF_HOOK include/linux/netfilter.h:311 [inline]\n   ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254\n   dst_input include/net/dst.h:469 [inline]\n   ip_rcv_finish net/ipv4/ip_input.c:447 [inline]\n   NF_HOOK include/linux/netfilter.h:317 [inline]\n   NF_HOOK include/linux/netfilter.h:311 [inline]\n   ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567\n   __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975\n   __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088\n   process_backlog+0x301/0x1360 net/core/dev.c:6440\n   __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453\n   napi_poll net/core/dev.c:7517 [inline]\n   net_rx_action+0xb44/0x1010 net/core/dev.c:7644\n   handle_softirqs+0x1d0/0x770 kernel/softirq.c:579\n   do_softirq+0x3f/0x90 kernel/softirq.c:480\n   </IRQ>\n   <TASK>\n   __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407\n   local_bh_enable include/linux/bottom_half.h:33 [inline]\n   inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524\n   mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985\n   mptcp_check_listen_stop net/mptcp/mib.h:118 [inline]\n   __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000\n   mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066\n   inet_release+0xed/0x200 net/ipv4/af_inet.c:435\n   inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487\n   __sock_release+0xb3/0x270 net/socket.c:649\n   sock_close+0x1c/0x30 net/socket.c:1439\n   __fput+0x402/0xb70 fs/file_table.c:465\n   task_work_run+0x150/0x240 kernel/task_work.c:227\n   resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n   exit_to_user_mode_loop+0xd4\n---truncated---(CVE-2025-38491)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic\n\nThe decompress_io_ctx may be released asynchronously after\nI/O completion. If this file is deleted immediately after read,\nand the kworker of processing post_read_wq has not been executed yet\ndue to high workloads, It is possible that the inode(f2fs_inode_info)\nis evicted and freed before it is used f2fs_free_dic.\n\n    The UAF case as below:\n    Thread A                                      Thread B\n    - f2fs_decompress_end_io\n     - f2fs_put_dic\n      - queue_work\n        add free_dic work to post_read_wq\n                                                   - do_unlink\n                                                    - iput\n                                                     - evict\n                                                      - call_rcu\n    This file is deleted after read.\n\n    Thread C                                 kworker to process post_read_wq\n    - rcu_do_batch\n     - f2fs_free_inode\n      - kmem_cache_free\n     inode is freed by rcu\n                                             - process_scheduled_works\n                                              - f2fs_late_free_dic\n                                               - f2fs_free_dic\n                                                - f2fs_release_decomp_mem\n                                      read (dic->inode)->i_compress_algorithm\n\nThis patch store compress_algorithm and sbi in dic to avoid inode UAF.\n\nIn addition, the previous solution is deprecated in [1] may cause system hang.\n[1] https://lore.kernel.org/all/(CVE-2025-38627)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n[ceph] parse_longname(): strrchr() expects NUL-terminated string\n\n... and parse_longname() is not guaranteed that.  That's the reason\nwhy it uses kmemdup_nul() to build the argument for kstrtou64();\nthe problem is, kstrtou64() is not the only thing that need it.\n\nJust get a NUL-terminated copy of the entire thing and be done\nwith that...(CVE-2025-38660)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: remove refcounting in expectation dumpers\n\nSame pattern as previous patch: do not keep the expectation object\nalive via refcount, only store a cookie value and then use that\nas the skip hint for dump resumption.\n\nAFAICS this has the same issue as the one resolved in the conntrack\ndumper, when we do\n  if (!refcount_inc_not_zero(&exp->use))\n\nto increment the refcount, there is a chance that exp == last, which\ncauses a double-increment of the refcount and subsequent memory leak.(CVE-2025-39764)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: avoid accessing metadata when pointer is invalid in object_err()\n\nobject_err() reports details of an object for further debugging, such as\nthe freelist pointer, redzone, etc. However, if the pointer is invalid,\nattempting to access object metadata can lead to a crash since it does\nnot point to a valid object.\n\nOne known path to the crash is when alloc_consistency_checks()\ndetermines the pointer to the allocated object is invalid because of a\nfreelist corruption, and calls object_err() to report it. The debug code\nshould report and handle the corruption gracefully and not crash in the\nprocess.\n\nIn case the pointer is NULL or check_valid_pointer() returns false for\nthe pointer, only print the pointer value and skip accessing metadata.(CVE-2025-39902)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: fix Rx page leak on multi-buffer frames\n\nThe ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each\nbuffer in the current frame. This function was introduced as part of\nhandling multi-buffer XDP support in the ice driver.\n\nIt works by iterating over the buffers from first_desc up to 1 plus the\ntotal number of fragments in the frame, cached from before the XDP program\nwas executed.\n\nIf the hardware posts a descriptor with a size of 0, the logic used in\nice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added\nas fragments in ice_add_xdp_frag. Since the buffer isn't counted as a\nfragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't\ncall ice_put_rx_buf().\n\nBecause we don't call ice_put_rx_buf(), we don't attempt to re-use the\npage or free it. This leaves a stale page in the ring, as we don't\nincrement next_to_alloc.\n\nThe ice_reuse_rx_page() assumes that the next_to_alloc has been incremented\nproperly, and that it always points to a buffer with a NULL page. Since\nthis function doesn't check, it will happily recycle a page over the top\nof the next_to_alloc buffer, losing track of the old page.\n\nNote that this leak only occurs for multi-buffer frames. The\nice_put_rx_mbuf() function always handles at least one buffer, so a\nsingle-buffer frame will always get handled correctly. It is not clear\nprecisely why the hardware hands us descriptors with a size of 0 sometimes,\nbut it happens somewhat regularly with "jumbo frames" used by 9K MTU.\n\nTo fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on\nall buffers between first_desc and next_to_clean. Borrow the logic of a\nsimilar function in i40e used for this same purpose. Use the same logic\nalso in ice_get_pgcnts().\n\nInstead of iterating over just the number of fragments, use a loop which\niterates until the current index reaches to the next_to_clean element just\npast the current frame. Unlike i40e, the ice_put_rx_mbuf() function does\ncall ice_put_rx_buf() on the last buffer of the frame indicating the end of\npacket.\n\nFor non-linear (multi-buffer) frames, we need to take care when adjusting\nthe pagecnt_bias. An XDP program might release fragments from the tail of\nthe frame, in which case that fragment page is already released. Only\nupdate the pagecnt_bias for the first descriptor and fragments still\nremaining post-XDP program. Take care to only access the shared info for\nfragmented buffers, as this avoids a significant cache miss.\n\nThe xdp_xmit value only needs to be updated if an XDP program is run, and\nonly once per packet. Drop the xdp_xmit pointer argument from\nice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function\ndirectly. This avoids needing to pass the argument and avoids an extra\nbit-wise OR for each buffer in the frame.\n\nMove the increment of the ntc local variable to ensure its updated *before*\nall calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic\nrequires the index of the element just after the current frame.\n\nNow that we use an index pointer in the ring to identify the packet, we no\nlonger need to track or cache the number of fragments in the rx_ring.(CVE-2025-39948)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: Set fb_display[i]->mode to NULL when the mode is released\n\nRecently, we discovered the following issue through syzkaller:\n\nBUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0\nRead of size 4 at addr ff11000001b3c69c by task syz.xxx\n...\nCall Trace:\n <TASK>\n dump_stack_lvl+0xab/0xe0\n print_address_description.constprop.0+0x2c/0x390\n print_report+0xb9/0x280\n kasan_report+0xb8/0xf0\n fb_mode_is_equal+0x285/0x2f0\n fbcon_mode_deleted+0x129/0x180\n fb_set_var+0xe7f/0x11d0\n do_fb_ioctl+0x6a0/0x750\n fb_ioctl+0xe0/0x140\n __x64_sys_ioctl+0x193/0x210\n do_syscall_64+0x5f/0x9c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nBased on experimentation and analysis, during framebuffer unregistration,\nonly the memory of fb_info->modelist is freed, without setting the\ncorresponding fb_display[i]->mode to NULL for the freed modes. This leads\nto UAF issues during subsequent accesses. Here's an example of reproduction\nsteps:\n1. With /dev/fb0 already registered in the system, load a kernel module\n   to register a new device /dev/fb1;\n2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);\n3. Switch console from fb to VGA (to allow normal rmmod of the ko);\n4. Unload the kernel module, at this point fb1's modelist is freed, leaving\n   a wild pointer in fb_display[];\n5. Trigger the bug via system calls through fb0 attempting to delete a mode\n   from fb0.\n\nAdd a check in do_unregister_framebuffer(): if the mode to be freed exists\nin fb_display[], set the corresponding mode pointer to NULL.(CVE-2025-40323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb\n\nThe Mesa issue referenced below pointed out a possible deadlock:\n\n[ 1231.611031]  Possible interrupt unsafe locking scenario:\n\n[ 1231.611033]        CPU0                    CPU1\n[ 1231.611034]        ----                    ----\n[ 1231.611035]   lock(&xa->xa_lock#17);\n[ 1231.611038]                                local_irq_disable();\n[ 1231.611039]                                lock(&fence->lock);\n[ 1231.611041]                                lock(&xa->xa_lock#17);\n[ 1231.611044]   <Interrupt>\n[ 1231.611045]     lock(&fence->lock);\n[ 1231.611047]\n                *** DEADLOCK ***\n\nIn this example, CPU0 would be any function accessing job->dependencies\nthrough the xa_* functions that don't disable interrupts (eg:\ndrm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).\n\nCPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling\ncallback so in an interrupt context. It will deadlock when trying to\ngrab the xa_lock which is already held by CPU0.\n\nReplacing all xa_* usage by their xa_*_irq counterparts would fix\nthis issue, but Christian pointed out another issue: dma_fence_signal\ntakes fence.lock and so does dma_fence_add_callback.\n\n  dma_fence_signal() // locks f1.lock\n  -> drm_sched_entity_kill_jobs_cb()\n  -> foreach dependencies\n     -> dma_fence_add_callback() // locks f2.lock\n\nThis will deadlock if f1 and f2 share the same spinlock.\n\nTo fix both issues, the code iterating on dependencies and re-arming them\nis moved out to drm_sched_entity_kill_jobs_work().\n\n[phasta: commit message nits](CVE-2025-40329)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup\n\nRaw IP packets have no MAC header, leaving skb->mac_header uninitialized.\nThis can trigger kernel panics on ARM64 when xfrm or other subsystems\naccess the offset due to strict alignment checks.\n\nInitialize the MAC header to prevent such crashes.\n\nThis can trigger kernel panics on ARM when running IPsec over the\nqmimux0 interface.\n\nExample trace:\n\n    Internal error: Oops: 000000009600004f [#1] SMP\n    CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1\n    Hardware name: LS1028A RDB Board (DT)\n    pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n    pc : xfrm_input+0xde8/0x1318\n    lr : xfrm_input+0x61c/0x1318\n    sp : ffff800080003b20\n    Call trace:\n     xfrm_input+0xde8/0x1318\n     xfrm6_rcv+0x38/0x44\n     xfrm6_esp_rcv+0x48/0xa8\n     ip6_protocol_deliver_rcu+0x94/0x4b0\n     ip6_input_finish+0x44/0x70\n     ip6_input+0x44/0xc0\n     ipv6_rcv+0x6c/0x114\n     __netif_receive_skb_one_core+0x5c/0x8c\n     __netif_receive_skb+0x18/0x60\n     process_backlog+0x78/0x17c\n     __napi_poll+0x38/0x180\n     net_rx_action+0x168/0x2f0(CVE-2025-68192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: imon: make send_packet() more robust\n\nsyzbot is reporting that imon has three problems which result in\nhung tasks due to forever holding device lock [1].\n\nFirst problem is that when usb_rx_callback_intf0() once got -EPROTO error\nafter ictx->dev_present_intf0 became true, usb_rx_callback_intf0()\nresubmits urb after printk(), and resubmitted urb causes\nusb_rx_callback_intf0() to again get -EPROTO error. This results in\nprintk() flooding (RCU stalls).\n\nAlan Stern commented [2] that\n\n  In theory it's okay to resubmit _if_ the driver has a robust\n  error-recovery scheme (such as giving up after some fixed limit on the\n  number of errors or after some fixed time has elapsed, perhaps with a\n  time delay to prevent a flood of errors).  Most drivers don't bother to\n  do this; they simply give up right away.  This makes them more\n  vulnerable to short-term noise interference during USB transfers, but in\n  reality such interference is quite rare.  There's nothing really wrong\n  with giving up right away.\n\nbut imon has a poor error-recovery scheme which just retries forever;\nthis behavior should be fixed.\n\nSince I'm not sure whether it is safe for imon users to give up upon any\nerror code, this patch takes care of only union of error codes chosen from\nmodules in drivers/media/rc/ directory which handle -EPROTO error (i.e.\nir_toy, mceusb and igorplugusb).\n\nSecond problem is that when usb_rx_callback_intf0() once got -EPROTO error\nbefore ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always\nresubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedge\nhardware after early callbacks"). Move the ictx->dev_present_intf0 test\nintroduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodes\nuntil intf configured") to immediately before imon_incoming_packet(), or\nthe first problem explained above happens without printk() flooding (i.e.\nhung task).\n\nThird problem is that when usb_rx_callback_intf0() is not called for some\nreason (e.g. flaky hardware; the reproducer for this problem sometimes\nprevents usb_rx_callback_intf0() from being called),\nwait_for_completion_interruptible() in send_packet() never returns (i.e.\nhung task). As a workaround for such situation, change send_packet() to\nwait for completion with timeout of 10 seconds.(CVE-2025-68194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npmdomain: arm: scmi: Fix genpd leak on provider registration failure\n\nIf of_genpd_add_provider_onecell() fails during probe, the previously\ncreated generic power domains are not removed, leading to a memory leak\nand potential kernel crash later in genpd_debug_add().\n\nAdd proper error handling to unwind the initialized domains before\nreturning from probe to ensure all resources are correctly released on\nfailure.\n\nExample crash trace observed without this fix:\n\n  | Unable to handle kernel paging request at virtual address fffffffffffffc70\n  | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT\n  | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform\n  | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  | pc : genpd_debug_add+0x2c/0x160\n  | lr : genpd_debug_init+0x74/0x98\n  | Call trace:\n  |  genpd_debug_add+0x2c/0x160 (P)\n  |  genpd_debug_init+0x74/0x98\n  |  do_one_initcall+0xd0/0x2d8\n  |  do_initcall_level+0xa0/0x140\n  |  do_initcalls+0x60/0xa8\n  |  do_basic_setup+0x28/0x40\n  |  kernel_init_freeable+0xe8/0x170\n  |  kernel_init+0x2c/0x140\n  |  ret_from_fork+0x10/0x20(CVE-2025-68204)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlx5: Fix default values in create CQ\n\nCurrently, CQs without a completion function are assigned the\nmlx5_add_cq_to_tasklet function by default. This is problematic since\nonly user CQs created through the mlx5_ib driver are intended to use\nthis function.\n\nAdditionally, all CQs that will use doorbells instead of polling for\ncompletions must call mlx5_cq_arm. However, the default CQ creation flow\nleaves a valid value in the CQ's arm_db field, allowing FW to send\ninterrupts to polling-only CQs in certain corner cases.\n\nThese two factors would allow a polling-only kernel CQ to be triggered\nby an EQ interrupt and call a completion function intended only for user\nCQs, causing a null pointer exception.\n\nSome areas in the driver have prevented this issue with one-off fixes\nbut did not address the root cause.\n\nThis patch fixes the described issue by adding defaults to the create CQ\nflow. It adds a default dummy completion function to protect against\nnull pointer exceptions, and it sets an invalid command sequence number\nby default in kernel CQs to prevent the FW from sending an interrupt to\nthe CQ until it is armed. User CQs are responsible for their own\ninitialization values.\n\nCallers of mlx5_core_create_cq are responsible for changing the\ncompletion function and arming the CQ per their needs.(CVE-2025-68209)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksm: use range-walk function to jump over holes in scan_get_next_rmap_item\n\nCurrently, scan_get_next_rmap_item() walks every page address in a VMA to\nlocate mergeable pages.  This becomes highly inefficient when scanning\nlarge virtual memory areas that contain mostly unmapped regions, causing\nksmd to use large amount of cpu without deduplicating much pages.\n\nThis patch replaces the per-address lookup with a range walk using\nwalk_page_range().  The range walker allows KSM to skip over entire\nunmapped holes in a VMA, avoiding unnecessary lookups.  This problem was\npreviously discussed in [1].\n\nConsider the following test program which creates a 32 TiB mapping in the\nvirtual address space but only populates a single page:\n\n#include <unistd.h>\n#include <stdio.h>\n#include <sys/mman.h>\n\n/* 32 TiB */\nconst size_t size = 32ul * 1024 * 1024 * 1024 * 1024;\n\nint main() {\n        char *area = mmap(NULL, size, PROT_READ | PROT_WRITE,\n                          MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0);\n\n        if (area == MAP_FAILED) {\n                perror("mmap() failed\\n");\n                return -1;\n        }\n\n        /* Populate a single page such that we get an anon_vma. */\n        *area = 0;\n\n        /* Enable KSM. */\n        madvise(area, size, MADV_MERGEABLE);\n        pause();\n        return 0;\n}\n\n$ ./ksm-sparse  &\n$ echo 1 > /sys/kernel/mm/ksm/run \n\nWithout this patch ksmd uses 100% of the cpu for a long time (more then 1\nhour in my test machine) scanning all the 32 TiB virtual address space\nthat contain only one mapped page.  This makes ksmd essentially deadlocked\nnot able to deduplicate anything of value.  With this patch ksmd walks\nonly the one mapped page and skips the rest of the 32 TiB virtual address\nspace, making the scan fast using little cpu.(CVE-2025-68211)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempool: fix poisoning order>0 pages with HIGHMEM\n\nThe kernel test has reported:\n\n  BUG: unable to handle page fault for address: fffba000\n  #PF: supervisor write access in kernel mode\n  #PF: error_code(0x0002) - not-present page\n  *pde = 03171067 *pte = 00000000\n  Oops: Oops: 0002 [#1]\n  CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G                T   6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE  a1d066dfe789f54bc7645c7989957d2bdee593ca\n  Tainted: [T]=RANDSTRUCT\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n  EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17)\n  Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 <f3> aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56\n  EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b\n  ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8\n  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287\n  CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690\n  Call Trace:\n   poison_element (mm/mempool.c:83 mm/mempool.c:102)\n   mempool_init_node (mm/mempool.c:142 mm/mempool.c:226)\n   mempool_init_noprof (mm/mempool.c:250 (discriminator 1))\n   ? mempool_alloc_pages (mm/mempool.c:640)\n   bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8))\n   ? mempool_alloc_pages (mm/mempool.c:640)\n   do_one_initcall (init/main.c:1283)\n\nChristoph found out this is due to the poisoning code not dealing\nproperly with CONFIG_HIGHMEM because only the first page is mapped but\nthen the whole potentially high-order page is accessed.\n\nWe could give up on HIGHMEM here, but it's straightforward to fix this\nwith a loop that's mapping, poisoning or checking and unmapping\nindividual pages.(CVE-2025-68231)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmtdchar: fix integer overflow in read/write ioctls\n\nThe "req.start" and "req.len" variables are u64 values that come from the\nuser at the start of the function.  We mask away the high 32 bits of\n"req.len" so that's capped at U32_MAX but the "req.start" variable can go\nup to U64_MAX which means that the addition can still integer overflow.\n\nUse check_add_overflow() to fix this bug.(CVE-2025-68237)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: udc: fix use-after-free in usb_gadget_state_work\n\nA race condition during gadget teardown can lead to a use-after-free\nin usb_gadget_state_work(), as reported by KASAN:\n\n  BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0\n  Workqueue: events usb_gadget_state_work\n\nThe fundamental race occurs because a concurrent event (e.g., an\ninterrupt) can call usb_gadget_set_state() and schedule gadget->work\nat any time during the cleanup process in usb_del_gadget().\n\nCommit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after\ndevice removal") attempted to fix this by moving flush_work() to after\ndevice_del(). However, this does not fully solve the race, as a new\nwork item can still be scheduled *after* flush_work() completes but\nbefore the gadget's memory is freed, leading to the same use-after-free.\n\nThis patch fixes the race condition robustly by introducing a 'teardown'\nflag and a 'state_lock' spinlock to the usb_gadget struct. The flag is\nset during cleanup in usb_del_gadget() *before* calling flush_work() to\nprevent any new work from being scheduled once cleanup has commenced.\nThe scheduling site, usb_gadget_set_state(), now checks this flag under\nthe lock before queueing the work, thus safely closing the race window.(CVE-2025-68282)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix NULL pointer deference when splitting folio\n\nCommit c010d47f107f ("mm: thp: split huge page to any lower order pages")\nintroduced an early check on the folio's order via mapping->flags before\nproceeding with the split work.\n\nThis check introduced a bug: for shmem folios in the swap cache and\ntruncated folios, the mapping pointer can be NULL.  Accessing\nmapping->flags in this state leads directly to a NULL pointer dereference.\n\nThis commit fixes the issue by moving the check for mapping != NULL before\nany attempt to access mapping->flags.(CVE-2025-68293)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/CPU/AMD: Add RDSEED fix for Zen5\n\nThere's an issue with RDSEED's 16-bit and 32-bit register output\nvariants on Zen5 which return a random value of 0 "at a rate inconsistent\nwith randomness while incorrectly signaling success (CF=1)". Search the\nweb for AMD-SB-7055 for more detail.\n\nAdd a fix glue which checks microcode revisions.\n\n  [ bp: Add microcode revisions checking, rewrite. ](CVE-2025-68313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ninet: frags: flush pending skbs in fqdir_pre_exit()\n\nWe have been seeing occasional deadlocks on pernet_ops_rwsem since\nSeptember in NIPA. The stuck task was usually modprobe (often loading\na driver like ipvlan), trying to take the lock as a Writer.\nlockdep does not track readers for rwsems so the read wasn't obvious\nfrom the reports.\n\nOn closer inspection the Reader holding the lock was conntrack looping\nforever in nf_conntrack_cleanup_net_list(). Based on past experience\nwith occasional NIPA crashes I looked thru the tests which run before\nthe crash and noticed that the crash follows ip_defrag.sh. An immediate\nred flag. Scouring thru (de)fragmentation queues reveals skbs sitting\naround, holding conntrack references.\n\nThe problem is that since conntrack depends on nf_defrag_ipv6,\nnf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its\nnetns exit hooks run _after_ conntrack's netns exit hook.\n\nFlush all fragment queue SKBs during fqdir_pre_exit() to release\nconntrack references before conntrack cleanup runs. Also flush\nthe queues in timer expiry handlers when they discover fqdir->dead\nis set, in case packet sneaks in while we're running the pre_exit\nflush.\n\nThe commit under Fixes is not exactly the culprit, but I think\npreviously the timer firing would eventually unblock the spinning\nconntrack.(CVE-2025-68768)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix middle attribute validation in push_nsh() action\n\nThe push_nsh() action structure looks like this:\n\n OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))\n\nThe outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by the\nnla_for_each_nested() inside __ovs_nla_copy_actions().  The innermost\nOVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested()\ninside nsh_key_put_from_nlattr().  But nothing checks if the attribute\nin the middle is OK.  We don't even check that this attribute is the\nOVS_KEY_ATTR_NSH.  We just do a double unwrap with a pair of nla_data()\ncalls - first time directly while calling validate_push_nsh() and the\nsecond time as part of the nla_for_each_nested() macro, which isn't\nsafe, potentially causing invalid memory access if the size of this\nattribute is incorrect.  The failure may not be noticed during\nvalidation due to larger netlink buffer, but cause trouble later during\naction execution where the buffer is allocated exactly to the size:\n\n BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]\n Read of size 184 at addr ffff88816459a634 by task a.out/22624\n\n CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary)\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0x51/0x70\n  print_address_description.constprop.0+0x2c/0x390\n  kasan_report+0xdd/0x110\n  kasan_check_range+0x35/0x1b0\n  __asan_memcpy+0x20/0x60\n  nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch]\n  push_nsh+0x82/0x120 [openvswitch]\n  do_execute_actions+0x1405/0x2840 [openvswitch]\n  ovs_execute_actions+0xd5/0x3b0 [openvswitch]\n  ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch]\n  genl_family_rcv_msg_doit+0x1d6/0x2b0\n  genl_family_rcv_msg+0x336/0x580\n  genl_rcv_msg+0x9f/0x130\n  netlink_rcv_skb+0x11f/0x370\n  genl_rcv+0x24/0x40\n  netlink_unicast+0x73e/0xaa0\n  netlink_sendmsg+0x744/0xbf0\n  __sys_sendto+0x3d6/0x450\n  do_syscall_64+0x79/0x2c0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  </TASK>\n\nLet's add some checks that the attribute is properly sized and it's\nthe only one attribute inside the action.  Technically, there is no\nreal reason for OVS_KEY_ATTR_NSH to be there, as we know that we're\npushing an NSH header already, it just creates extra nesting, but\nthat's how uAPI works today.  So, keeping as it is.(CVE-2025-68785)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()\n\nrlen value is a user-controlled value, but dtv5100_i2c_msg() does not\ncheck the size of the rlen value. Therefore, if it is set to a value\nlarger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.\n\nTherefore, we need to add proper range checking to prevent this vuln.(CVE-2025-68819)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nInput: alps - fix use-after-free bugs caused by dev3_register_work\n\nThe dev3_register_work delayed work item is initialized within\nalps_reconnect() and scheduled upon receipt of the first bare\nPS/2 packet from an external PS/2 device connected to the ALPS\ntouchpad. During device detachment, the original implementation\ncalls flush_workqueue() in psmouse_disconnect() to ensure\ncompletion of dev3_register_work. However, the flush_workqueue()\nin psmouse_disconnect() only blocks and waits for work items that\nwere already queued to the workqueue prior to its invocation. Any\nwork items submitted after flush_workqueue() is called are not\nincluded in the set of tasks that the flush operation awaits.\nThis means that after flush_workqueue() has finished executing,\nthe dev3_register_work could still be scheduled. Although the\npsmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),\nthe scheduling of dev3_register_work remains unaffected.\n\nThe race condition can occur as follows:\n\nCPU 0 (cleanup path)     | CPU 1 (delayed work)\npsmouse_disconnect()     |\n  psmouse_set_state()    |\n  flush_workqueue()      | alps_report_bare_ps2_packet()\n  alps_disconnect()      |   psmouse_queue_work()\n    kfree(priv); // FREE | alps_register_bare_ps2_mouse()\n                         |   priv = container_of(work...); // USE\n                         |   priv->dev3 // USE\n\nAdd disable_delayed_work_sync() in alps_disconnect() to ensure\nthat dev3_register_work is properly canceled and prevented from\nexecuting after the alps_data structure has been deallocated.\n\nThis bug is identified by static analysis.(CVE-2025-68822)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid potential deadlock\n\nAs Jiaming Zhang and syzbot reported, there is potential deadlock in\nf2fs as below:\n\nChain exists of:\n  &sbi->cp_rwsem --> fs_reclaim --> sb_internal#2\n\n Possible unsafe locking scenario:\n\n       CPU0                    CPU1\n       ----                    ----\n  rlock(sb_internal#2);\n                               lock(fs_reclaim);\n                               lock(sb_internal#2);\n  rlock(&sbi->cp_rwsem);\n\n *** DEADLOCK ***\n\n3 locks held by kswapd0/73:\n #0: ffffffff8e247a40 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat mm/vmscan.c:7015 [inline]\n #0: ffffffff8e247a40 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x951/0x2800 mm/vmscan.c:7389\n #1: ffff8880118400e0 (&type->s_umount_key#50){.+.+}-{4:4}, at: super_trylock_shared fs/super.c:562 [inline]\n #1: ffff8880118400e0 (&type->s_umount_key#50){.+.+}-{4:4}, at: super_cache_scan+0x91/0x4b0 fs/super.c:197\n #2: ffff888011840610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x8d9/0x1b60 fs/f2fs/inode.c:890\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 73 Comm: kswapd0 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_circular_bug+0x2ee/0x310 kernel/locking/lockdep.c:2043\n check_noncircular+0x134/0x160 kernel/locking/lockdep.c:2175\n check_prev_add kernel/locking/lockdep.c:3165 [inline]\n check_prevs_add kernel/locking/lockdep.c:3284 [inline]\n validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3908\n __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5237\n lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868\n down_read+0x46/0x2e0 kernel/locking/rwsem.c:1537\n f2fs_down_read fs/f2fs/f2fs.h:2278 [inline]\n f2fs_lock_op fs/f2fs/f2fs.h:2357 [inline]\n f2fs_do_truncate_blocks+0x21c/0x10c0 fs/f2fs/file.c:791\n f2fs_truncate_blocks+0x10a/0x300 fs/f2fs/file.c:867\n f2fs_truncate+0x489/0x7c0 fs/f2fs/file.c:925\n f2fs_evict_inode+0x9f2/0x1b60 fs/f2fs/inode.c:897\n evict+0x504/0x9c0 fs/inode.c:810\n f2fs_evict_inode+0x1dc/0x1b60 fs/f2fs/inode.c:853\n evict+0x504/0x9c0 fs/inode.c:810\n dispose_list fs/inode.c:852 [inline]\n prune_icache_sb+0x21b/0x2c0 fs/inode.c:1000\n super_cache_scan+0x39b/0x4b0 fs/super.c:224\n do_shrink_slab+0x6ef/0x1110 mm/shrinker.c:437\n shrink_slab_memcg mm/shrinker.c:550 [inline]\n shrink_slab+0x7ef/0x10d0 mm/shrinker.c:628\n shrink_one+0x28a/0x7c0 mm/vmscan.c:4955\n shrink_many mm/vmscan.c:5016 [inline]\n lru_gen_shrink_node mm/vmscan.c:5094 [inline]\n shrink_node+0x315d/0x3780 mm/vmscan.c:6081\n kswapd_shrink_node mm/vmscan.c:6941 [inline]\n balance_pgdat mm/vmscan.c:7124 [inline]\n kswapd+0x147c/0x2800 mm/vmscan.c:7389\n kthread+0x70e/0x8a0 kernel/kthread.c:463\n ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n </TASK>\n\nThe root cause is deadlock among four locks as below:\n\nkswapd\n- fs_reclaim\t\t\t\t--- Lock A\n - shrink_one\n  - evict\n   - f2fs_evict_inode\n    - sb_start_intwrite\t\t\t--- Lock B\n\n- iput\n - evict\n  - f2fs_evict_inode\n   - sb_start_intwrite\t\t\t--- Lock B\n   - f2fs_truncate\n    - f2fs_truncate_blocks\n     - f2fs_do_truncate_blocks\n      - f2fs_lock_op\t\t\t--- Lock C\n\nioctl\n- f2fs_ioc_commit_atomic_write\n - f2fs_lock_op\t\t\t\t--- Lock C\n  - __f2fs_commit_atomic_write\n   - __replace_atomic_write_block\n    - f2fs_get_dnode_of_data\n     - __get_node_folio\n      - f2fs_check_nid_range\n       - f2fs_handle_error\n        - f2fs_record_errors\n         - f2fs_down_write\t\t--- Lock D\n\nopen\n- do_open\n - do_truncate\n  - security_inode_need_killpriv\n   - f2fs_getxattr\n    - lookup_all_xattrs\n     - f2fs_handle_error\n      - f2fs_record_errors\n       - f2fs_down_write\t\t--- Lock D\n        - f2fs_commit_super\n         - read_mapping_folio\n          - filemap_alloc_folio_noprof\n           - prepare_alloc_pages\n            - fs_reclaim_acquire\t--- Lock A\n\nIn order to a\n---truncated---(CVE-2025-71065)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsvcrdma: bound check rq_pages index in inline path\n\nsvc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] without\nverifying rc_curpage stays within the allocated page array. Add guards\nbefore the first use and after advancing to a new page.(CVE-2025-71068)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ttm: Avoid NULL pointer deref for evicted BOs\n\nIt is possible for a BO to exist that is not currently associated with a\nresource, e.g. because it has been evicted.\n\nWhen devcoredump tries to read the contents of all BOs for dumping, we need\nto expect this as well -- in this case, ENODATA is recorded instead of the\nbuffer contents.(CVE-2025-71083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cm: Fix leaking the multicast GID table reference\n\nIf the CM ID is destroyed while the CM event for multicast creating is\nstill queued the cancel_work_sync() will prevent the work from running\nwhich also prevents destroying the ah_attr. This leaks a refcount and\ntriggers a WARN:\n\n   GID entry ref leak for dev syz1 index 2 ref=573\n   WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]\n   WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886\n\nDestroy the ah_attr after canceling the work, it is safe to call this\ntwice.(CVE-2025-71084)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nteam: fix check for port enabled in team_queue_override_port_prio_changed()\n\nThere has been a syzkaller bug reported recently with the following\ntrace:\n\nlist_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:59!\nOops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\nCPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59\nCode: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286\nRAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000\nRDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005\nRBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230\nR13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480\nFS:  00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0\nCall Trace:\n <TASK>\n __list_del_entry_valid include/linux/list.h:132 [inline]\n __list_del_entry include/linux/list.h:223 [inline]\n list_del_rcu include/linux/rculist.h:178 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline]\n team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline]\n team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534\n team_option_set drivers/net/team/team_core.c:376 [inline]\n team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653\n genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346\n netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg net/socket.c:742 [inline]\n ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684\n __sys_sendmsg+0x16d/0x220 net/socket.c:2716\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe problem is in this flow:\n1) Port is enabled, queue_id != 0, in qom_list\n2) Port gets disabled\n        -> team_port_disable()\n        -> team_queue_override_port_del()\n        -> del (removed from list)\n3) Port is disabled, queue_id != 0, not in any list\n4) Priority changes\n        -> team_queue_override_port_prio_changed()\n        -> checks: port disabled && queue_id != 0\n        -> calls del - hits the BUG as it is removed already\n\nTo fix this, change the check in team_queue_override_port_prio_changed()\nso it returns early if port is not enabled.(CVE-2025-71091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctly\n\nThe netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have a\nLS_NLA_TYPE_DGID attribute, it is invalid if it does not.\n\nUse the nl parsing logic properly and call nla_parse_deprecated() to fill\nthe nlattrs array and then directly index that array to get the data for\nthe DGID. Just fail if it is NULL.\n\nRemove the for loop searching for the nla, and squash the validation and\nparsing into one function.\n\nFixes an uninitialized read from the stack triggered by userspace if it\ndoes not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVE\nquery.\n\n    BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline]\n    BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490\n     hex_byte_pack include/linux/hex.h:13 [inline]\n     ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490\n     ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509\n     ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633\n     pointer+0xc09/0x1bd0 lib/vsprintf.c:2542\n     vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930\n     vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279\n     vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426\n     vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465\n     vprintk+0x36/0x50 kernel/printk/printk_safe.c:82\n     _printk+0x17e/0x1b0 kernel/printk/printk.c:2475\n     ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline]\n     ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141\n     rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline]\n     rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]\n     rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259\n     netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n     netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346\n     netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896\n     sock_sendmsg_nosec net/socket.c:714 [inline]\n     __sock_sendmsg+0x333/0x3d0 net/socket.c:729\n     ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617\n     ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671\n     __sys_sendmsg+0x1aa/0x300 net/socket.c:2703\n     __compat_sys_sendmsg net/compat.c:346 [inline]\n     __do_compat_sys_sendmsg net/compat.c:353 [inline]\n     __se_compat_sys_sendmsg net/compat.c:350 [inline]\n     __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350\n     ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371\n     do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n     __do_fast_syscall_32+0xb0/0x150 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:3(CVE-2025-71096)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: Fix reference count leak when using error routes with nexthop objects\n\nWhen a nexthop object is deleted, it is marked as dead and then\nfib_table_flush() is called to flush all the routes that are using the\ndead nexthop.\n\nThe current logic in fib_table_flush() is to only flush error routes\n(e.g., blackhole) when it is called as part of network namespace\ndismantle (i.e., with flush_all=true). Therefore, error routes are not\nflushed when their nexthop object is deleted:\n\n # ip link add name dummy1 up type dummy\n # ip nexthop add id 1 dev dummy1\n # ip route add 198.51.100.1/32 nhid 1\n # ip route add blackhole 198.51.100.2/32 nhid 1\n # ip nexthop del id 1\n # ip route show\n blackhole 198.51.100.2 nhid 1 dev dummy1\n\nAs such, they keep holding a reference on the nexthop object which in\nturn holds a reference on the nexthop device, resulting in a reference\ncount leak:\n\n # ip link del dev dummy1\n [   70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2\n\nFix by flushing error routes when their nexthop is marked as dead.\n\nIPv6 does not suffer from this problem.(CVE-2025-71097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Avoid walking the Namespace if start_node is NULL\n\nAlthough commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespace\nif it is not there") fixed the situation when both start_node and\nacpi_gbl_root_node are NULL, the Linux kernel mainline now still crashed\non Honor Magicbook 14 Pro [1].\n\nThat happens due to the access to the member of parent_node in\nacpi_ns_get_next_node().  The NULL pointer dereference will always\nhappen, no matter whether or not the start_node is equal to\nACPI_ROOT_OBJECT, so move the check of start_node being NULL\nout of the if block.\n\nUnfortunately, all the attempts to contact Honor have failed, they\nrefused to provide any technical support for Linux.\n\nThe bad DSDT table's dump could be found on GitHub [2].\n\nDMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025\n\n[ rjw: Subject adjustment, changelog edits ](CVE-2025-71118)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf\n\nA zero length gss_token results in pages == 0 and in_token->pages[0]\nis NULL. The code unconditionally evaluates\npage_address(in_token->pages[0]) for the initial memcpy, which can\ndereference NULL even when the copy length is 0. Guard the first\nmemcpy so it only runs when length > 0.(CVE-2025-71120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: BPF: Sign extend kfunc call arguments\n\nThe kfunc calls are native calls so they should follow LoongArch calling\nconventions. Sign extend its arguments properly to avoid kernel panic.\nThis is done by adding a new emit_abi_ext() helper. The emit_abi_ext()\nhelper performs extension in place meaning a value already store in the\ntarget register (Note: this is different from the existing sign_extend()\nhelper and thus we can't reuse it).(CVE-2025-71129)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/tilcdc: Fix removal actions in case of failed probe\n\nThe drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers\nshould only be called when the device has been successfully registered.\nCurrently, these functions are called unconditionally in tilcdc_fini(),\nwhich causes warnings during probe deferral scenarios.\n\n[    7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68\n...\n[    8.005820]  drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108\n[    8.005858]  drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8\n[    8.005885]  drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144\n[    8.005911]  drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc]\n[    8.005957]  tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc]\n\nFix this by rewriting the failed probe cleanup path using the standard\ngoto error handling pattern, which ensures that cleanup functions are\nonly called on successfully initialized resources. Additionally, remove\nthe now-unnecessary is_registered flag.(CVE-2025-71141)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: stm32: dmamux: fix device leak on route allocation\n\nMake sure to drop the reference taken when looking up the DMA mux\nplatform device during route allocation.\n\nNote that holding a reference to a device does not prevent its driver\ndata from going away so there is no point in keeping the reference.(CVE-2025-71186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb/server: call ksmbd_session_rpc_close() on error path in create_smb2_pipe()\n\nWhen ksmbd_iov_pin_rsp() fails, we should call ksmbd_session_rpc_close().(CVE-2025-71220)\n\nIn the Linux kernel, a race condition vulnerability exists in the mmp_pdma driver. The vulnerability occurs in the mmp_pdma_residue() function which lacks proper locking mechanisms, potentially leading to use-after-free issues when accessing descriptor lists and descriptor contents.\n\nThe race condition occurs when multiple threads call tx_status() while the tasklet on another CPU is freeing completed descriptors. This issue can be reproduced when running dmatest on the same channel with multiple threads (threads_per_chan > 1).\n\nThe fix involves protecting the chain_running list iteration and descriptor access with the chan->desc_lock spinlock.(CVE-2025-71221)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb/server: fix refcount leak in smb2_open()\n\nWhen ksmbd_vfs_getattr() fails, the reference count of ksmbd_file\nmust be released.(CVE-2025-71223)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: suspend array while updating raid_disks via sysfs\n\nIn raid1_reshape(), freeze_array() is called before modifying the r1bio\nmemory pool (conf->r1bio_pool) and conf->raid_disks, and\nunfreeze_array() is called after the update is completed.\n\nHowever, freeze_array() only waits until nr_sync_pending and\n(nr_pending - nr_queued) of all buckets reaches zero. When an I/O error\noccurs, nr_queued is increased and the corresponding r1bio is queued to\neither retry_list or bio_end_io_list. As a result, freeze_array() may\nunblock before these r1bios are released.\n\nThis can lead to a situation where conf->raid_disks and the mempool have\nalready been updated while queued r1bios, allocated with the old\nraid_disks value, are later released. Consequently, free_r1bio() may\naccess memory out of bounds in put_all_bios() and release r1bios of the\nwrong size to the new mempool, potentially causing issues with the\nmempool as well.\n\nSince only normal I/O might increase nr_queued while an I/O error occurs,\nsuspending the array avoids this issue.\n\nNote: Updating raid_disks via ioctl SET_ARRAY_INFO already suspends\nthe array. Therefore, we suspend the array when updating raid_disks\nvia sysfs to avoid this issue too.(CVE-2025-71225)\n\nIn the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Free sp in error path to fix system crash  System crash seen during load/unload test in a loop,  [61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X. [61110.467494](CVE-2025-71232)\n\nIn the Linux kernel, there is a race condition vulnerability in the SCSI qla2xxx driver. System crash was observed during load/unload loop testing. The root cause was a memory free operation occurring in interrupt context. When device discovery/fabric scan was in progress and module unload was issued setting the UNLOADING flag, work queue items could not be allocated and mapped memory had to be freed in interrupt context, leading to system crash.(CVE-2025-71235)\n\nA NULL pointer dereference vulnerability exists in the SCSI qla2xxx driver subsystem of the Linux kernel. When the system attempts to free associated memory in the qla_fab_async_scan function, it fails to validate whether the sp pointer is NULL, leading to kernel NULL pointer dereference and system crashes. This vulnerability can be exploited by attackers to cause denial of service.(CVE-2025-71236)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: sock: fix hardened usercopy panic in sock_recv_errqueue\n\nskbuff_fclone_cache was created without defining a usercopy region,\n[1] unlike skbuff_head_cache which properly whitelists the cb[] field.\n[2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY is\nenabled and the kernel attempts to copy sk_buff.cb data to userspace\nvia sock_recv_errqueue() -> put_cmsg().\n\nThe crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone()\n   (from skbuff_fclone_cache) [1]\n2. The skb is cloned via skb_clone() using the pre-allocated fclone\n[3] 3. The cloned skb is queued to sk_error_queue for timestamp\nreporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE)\n5. sock_recv_errqueue() calls put_cmsg() to copy serr->ee from skb->cb\n[4] 6. __check_heap_object() fails because skbuff_fclone_cache has no\n   usercopy whitelist [5]\n\nWhen cloned skbs allocated from skbuff_fclone_cache are used in the\nsocket error queue, accessing the sock_exterr_skb structure in skb->cb\nvia put_cmsg() triggers a usercopy hardening violation:\n\n[    5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)!\n[    5.382796] kernel BUG at mm/usercopy.c:102!\n[    5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\n[    5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7\n[    5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[    5.384903] RIP: 0010:usercopy_abort+0x6c/0x80\n[    5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490\n[    5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246\n[    5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74\n[    5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0\n[    5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74\n[    5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001\n[    5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00\n[    5.384903] FS:  0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000\n[    5.384903] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0\n[    5.384903] PKRU: 55555554\n[    5.384903] Call Trace:\n[    5.384903]  <TASK>\n[    5.384903]  __check_heap_object+0x9a/0xd0\n[    5.384903]  __check_object_size+0x46c/0x690\n[    5.384903]  put_cmsg+0x129/0x5e0\n[    5.384903]  sock_recv_errqueue+0x22f/0x380\n[    5.384903]  tls_sw_recvmsg+0x7ed/0x1960\n[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5\n[    5.384903]  ? schedule+0x6d/0x270\n[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5\n[    5.384903]  ? mutex_unlock+0x81/0xd0\n[    5.384903]  ? __pfx_mutex_unlock+0x10/0x10\n[    5.384903]  ? __pfx_tls_sw_recvmsg+0x10/0x10\n[    5.384903]  ? _raw_spin_lock_irqsave+0x8f/0xf0\n[    5.384903]  ? _raw_read_unlock_irqrestore+0x20/0x40\n[    5.384903]  ? srso_alias_return_thunk+0x5/0xfbef5\n\nThe crash offset 296 corresponds to skb2->cb within skbuff_fclones:\n  - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 -\n  offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 =\n  272 + 24 (inside sock_exterr_skb.ee)\n\nThis patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.\n\n[1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885\n[2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104\n[3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566\n[4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491\n[5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719(CVE-2026-22977)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix memory leak in skb_segment_list for GRO packets\n\nWhen skb_segment_list() is called during packet forwarding, it handles\npackets that were aggregated by the GRO engine.\n\nHistorically, the segmentation logic in skb_segment_list assumes that\nindividual segments are split from a parent SKB and may need to carry\ntheir own socket memory accounting. Accordingly, the code transfers\ntruesize from the parent to the newly created segments.\n\nPrior to commit ed4cccef64c1 ("gro: fix ownership transfer"), this\ntruesize subtraction in skb_segment_list() was valid because fragments\nstill carry a reference to the original socket.\n\nHowever, commit ed4cccef64c1 ("gro: fix ownership transfer") changed\nthis behavior by ensuring that fraglist entries are explicitly\norphaned (skb->sk = NULL) to prevent illegal orphaning later in the\nstack. This change meant that the entire socket memory charge remained\nwith the head SKB, but the corresponding accounting logic in\nskb_segment_list() was never updated.\n\nAs a result, the current code unconditionally adds each fragment's\ntruesize to delta_truesize and subtracts it from the parent SKB. Since\nthe fragments are no longer charged to the socket, this subtraction\nresults in an effective under-count of memory when the head is freed.\nThis causes sk_wmem_alloc to remain non-zero, preventing socket\ndestruction and leading to a persistent memory leak.\n\nThe leak can be observed via KMEMLEAK when tearing down the networking\nenvironment:\n\nunreferenced object 0xffff8881e6eb9100 (size 2048):\n  comm "ping", pid 6720, jiffies 4295492526\n  backtrace:\n    kmem_cache_alloc_noprof+0x5c6/0x800\n    sk_prot_alloc+0x5b/0x220\n    sk_alloc+0x35/0xa00\n    inet6_create.part.0+0x303/0x10d0\n    __sock_create+0x248/0x640\n    __sys_socket+0x11b/0x1d0\n\nSince skb_segment_list() is exclusively used for SKB_GSO_FRAGLIST\npackets constructed by GRO, the truesize adjustment is removed.\n\nThe call to skb_release_head_state() must be preserved. As documented in\ncommit cf673ed0e057 ("net: fix fraglist segmentation reference count\nleak"), it is still required to correctly drop references to SKB\nextensions that may be overwritten during __copy_skb_header().(CVE-2026-22979)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: prevent potential out-of-bounds reads in handle_auth_done()\n\nPerform an explicit bounds check on payload_len to avoid a possible\nout-of-bounds access in the callout.\n\n[ idryomov: changelog ](CVE-2026-22984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: make free_choose_arg_map() resilient to partial allocation\n\nfree_choose_arg_map() may dereference a NULL pointer if its caller fails\nafter a partial allocation.\n\nFor example, in decode_choose_args(), if allocation of arg_map->args\nfails, execution jumps to the fail label and free_choose_arg_map() is\ncalled. Since arg_map->size is updated to a non-zero value before memory\nallocation, free_choose_arg_map() will iterate over arg_map->args and\ndereference a NULL pointer.\n\nTo prevent this potential NULL pointer dereference and make\nfree_choose_arg_map() more resilient, add checks for pointers before\niterating.(CVE-2026-22991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: do not free existing class in qfq_change_class()\n\nFixes qfq_change_class() error case.\n\ncl->qdisc and cl should only be freed if a new class and qdisc\nwere allocated, or we risk various UAF.(CVE-2026-22999)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()\n\nBlamed commit did not take care of VLAN encapsulations\nas spotted by syzbot [1].\n\nUse skb_vlan_inet_prepare() instead of pskb_inet_may_pull().\n\n[1]\n BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321\n  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n  IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321\n  ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729\n  __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860\n  ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903\n gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1\n  ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438\n  ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489\n  NF_HOOK include/linux/netfilter.h:318 [inline]\n  ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500\n  ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590\n  dst_input include/net/dst.h:474 [inline]\n  ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79\n  NF_HOOK include/linux/netfilter.h:318 [inline]\n  ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311\n  __netif_receive_skb_one_core net/core/dev.c:6139 [inline]\n  __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252\n  netif_receive_skb_internal net/core/dev.c:6338 [inline]\n  netif_receive_skb+0x57/0x630 net/core/dev.c:6397\n  tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485\n  tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953\n  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999\n  new_sync_write fs/read_write.c:593 [inline]\n  vfs_write+0xbe2/0x15d0 fs/read_write.c:686\n  ksys_write fs/read_write.c:738 [inline]\n  __do_sys_write fs/read_write.c:749 [inline]\n  __se_sys_write fs/read_write.c:746 [inline]\n  __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746\n  x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:4960 [inline]\n  slab_alloc_node mm/slub.c:5263 [inline]\n  kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315\n  kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586\n  __alloc_skb+0x805/0x1040 net/core/skbuff.c:690\n  alloc_skb include/linux/skbuff.h:1383 [inline]\n  alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712\n  sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995\n  tun_alloc_skb drivers/net/tun.c:1461 [inline]\n  tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794\n  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999\n  new_sync_write fs/read_write.c:593 [inline]\n  vfs_write+0xbe2/0x15d0 fs/read_write.c:686\n  ksys_write fs/read_write.c:738 [inline]\n  __do_sys_write fs/read_write.c:749 [inline]\n  __se_sys_write fs/read_write.c:746 [inline]\n  __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746\n  x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025(CVE-2026-23003)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix use-after-free in inet6_addr_del().\n\nsyzbot reported use-after-free of inet6_ifaddr in\ninet6_addr_del(). [0]\n\nThe cited commit accidentally moved ipv6_del_addr() for\nmngtmpaddr before reading its ifp->flags for temporary\naddresses in inet6_addr_del().\n\nLet's move ipv6_del_addr() down to fix the UAF.\n\n[0]:\nBUG: KASAN: slab-use-after-free in inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117\nRead of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593\n\nCPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nCall Trace:\n <TASK>\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:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117\n addrconf_del_ifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181\n inet6_ioctl+0x1e5/0x2b0 net/ipv6/af_inet6.c:582\n sock_do_ioctl+0x118/0x280 net/socket.c:1254\n sock_ioctl+0x227/0x6b0 net/socket.c:1375\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl fs/ioctl.c:583 [inline]\n __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f164cf8f749\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749\nRDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003\nRBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288\n </TASK>\n\nAllocated by task 9593:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:56\n kasan_save_track+0x14/0x30 mm/kasan/common.c:77\n poison_kmalloc_redzone mm/kasan/common.c:397 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414\n kmalloc_noprof include/linux/slab.h:957 [inline]\n kzalloc_noprof include/linux/slab.h:1094 [inline]\n ipv6_add_addr+0x4e3/0x2010 net/ipv6/addrconf.c:1120\n inet6_addr_add+0x256/0x9b0 net/ipv6/addrconf.c:3050\n addrconf_add_ifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160\n inet6_ioctl+0x103/0x2b0 net/ipv6/af_inet6.c:580\n sock_do_ioctl+0x118/0x280 net/socket.c:1254\n sock_ioctl+0x227/0x6b0 net/socket.c:1375\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl fs/ioctl.c:583 [inline]\n __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 6099:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:56\n kasan_save_track+0x14/0x30 mm/kasan/common.c:77\n kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584\n poison_slab_object mm/kasan/common.c:252 [inline]\n __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284\n kasan_slab_free include/linux/kasan.h:234 [inline]\n slab_free_hook mm/slub.c:2540 [inline]\n slab_free_freelist_hook mm/slub.c:2569 [inline]\n slab_free_bulk mm/slub.c:6696 [inline]\n kmem_cache_free_bulk mm/slub.c:7383 [inline]\n kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362\n kfree_bulk include/linux/slab.h:830 [inline]\n kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523\n kvfree_rcu_drain_ready mm/slab_common.c:1728 [inline]\n kfree_rcu_monitor+0x1d0/0x2f0 mm/slab_common.c:1801\n process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257\n process_scheduled_works kernel/workqu\n---truncated---(CVE-2026-23010)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: ip_gre: make ipgre_header() robust\n\nAnalog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")\n\nOver the years, syzbot found many ways to crash the kernel\nin ipgre_header() [1].\n\nThis involves team or bonding drivers ability to dynamically\nchange their dev->needed_headroom and/or dev->hard_header_len\n\nIn this particular crash mld_newpack() allocated an skb\nwith a too small reserve/headroom, and by the time mld_sendpack()\nwas called, syzbot managed to attach an ipgre device.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0\n kernel BUG at net/core/skbuff.c:213 !\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nWorkqueue: mld mld_ifc_work\n RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213\nCall Trace:\n <TASK>\n  skb_under_panic net/core/skbuff.c:223 [inline]\n  skb_push+0xc3/0xe0 net/core/skbuff.c:2641\n  ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897\n  dev_hard_header include/linux/netdevice.h:3436 [inline]\n  neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618\n  NF_HOOK_COND include/linux/netfilter.h:307 [inline]\n  ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247\n  NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318\n  mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855\n  mld_send_cr net/ipv6/mcast.c:2154 [inline]\n  mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693\n  process_one_work kernel/workqueue.c:3257 [inline]\n  process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340\n  worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421\n  kthread+0x711/0x8a0 kernel/kthread.c:463\n  ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246(CVE-2026-23011)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: pegasus: fix memory leak in update_eth_regs_async()\n\nWhen asynchronously writing to the device registers and if usb_submit_urb()\nfail, the code fail to release allocated to this point resources.(CVE-2026-23021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: prevent pcp corruption with SMP=n\n\nThe kernel test robot has reported:\n\n BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28\n  lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0\n CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT  8cc09ef94dcec767faa911515ce9e609c45db470\n Call Trace:\n  <IRQ>\n  __dump_stack (lib/dump_stack.c:95)\n  dump_stack_lvl (lib/dump_stack.c:123)\n  dump_stack (lib/dump_stack.c:130)\n  spin_dump (kernel/locking/spinlock_debug.c:71)\n  do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?)\n  _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138)\n  __free_frozen_pages (mm/page_alloc.c:2973)\n  ___free_pages (mm/page_alloc.c:5295)\n  __free_pages (mm/page_alloc.c:5334)\n  tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290)\n  ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289)\n  ? rcu_core (kernel/rcu/tree.c:?)\n  rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861)\n  rcu_core_si (kernel/rcu/tree.c:2879)\n  handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623)\n  __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725)\n  irq_exit_rcu (kernel/softirq.c:741)\n  sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052)\n  </IRQ>\n  <TASK>\n RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194)\n  free_pcppages_bulk (mm/page_alloc.c:1494)\n  drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632)\n  __drain_all_pages (mm/page_alloc.c:2731)\n  drain_all_pages (mm/page_alloc.c:2747)\n  kcompactd (mm/compaction.c:3115)\n  kthread (kernel/kthread.c:465)\n  ? __cfi_kcompactd (mm/compaction.c:3166)\n  ? __cfi_kthread (kernel/kthread.c:412)\n  ret_from_fork (arch/x86/kernel/process.c:164)\n  ? __cfi_kthread (kernel/kthread.c:412)\n  ret_from_fork_asm (arch/x86/entry/entry_64.S:255)\n  </TASK>\n\nMatthew has analyzed the report and identified that in drain_page_zone()\nwe are in a section protected by spin_lock(&pcp->lock) and then get an\ninterrupt that attempts spin_trylock() on the same lock.  The code is\ndesigned to work this way without disabling IRQs and occasionally fail the\ntrylock with a fallback.  However, the SMP=n spinlock implementation\nassumes spin_trylock() will always succeed, and thus it's normally a\nno-op.  Here the enabled lock debugging catches the problem, but otherwise\nit could cause a corruption of the pcp structure.\n\nThe problem has been introduced by commit 574907741599 ("mm/page_alloc:\nleave IRQs enabled for per-cpu page allocations").  The pcp locking scheme\nrecognizes the need for disabling IRQs to prevent nesting spin_trylock()\nsections on SMP=n, but the need to prevent the nesting in spin_lock() has\nnot been recognized.  Fix it by introducing local wrappers that change the\nspin_lock() to spin_lock_iqsave() with SMP=n and use them in all places\nthat do spin_lock(&pcp->lock).\n\n[(CVE-2026-23025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnull_blk: fix kmemleak by releasing references to fault configfs items\n\nWhen CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blk\ndriver sets up fault injection support by creating the timeout_inject,\nrequeue_inject, and init_hctx_fault_inject configfs items as children\nof the top-level nullbX configfs group.\n\nHowever, when the nullbX device is removed, the references taken to\nthese fault-config configfs items are not released. As a result,\nkmemleak reports a memory leak, for example:\n\nunreferenced object 0xc00000021ff25c40 (size 32):\n  comm "mkdir", pid 10665, jiffies 4322121578\n  hex dump (first 32 bytes):\n    69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f  init_hctx_fault_\n    69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00  inject..........\n  backtrace (crc 1a018c86):\n    __kmalloc_node_track_caller_noprof+0x494/0xbd8\n    kvasprintf+0x74/0xf4\n    config_item_set_name+0xf0/0x104\n    config_group_init_type_name+0x48/0xfc\n    fault_config_init+0x48/0xf0\n    0xc0080000180559e4\n    configfs_mkdir+0x304/0x814\n    vfs_mkdir+0x49c/0x604\n    do_mkdirat+0x314/0x3d0\n    sys_mkdir+0xa0/0xd8\n    system_call_exception+0x1b0/0x4f0\n    system_call_vectored_common+0x15c/0x2ec\n\nFix this by explicitly releasing the references to the fault-config\nconfigfs items when dropping the reference to the top-level nullbX\nconfigfs group.(CVE-2026-23032)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()\n\nIn nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,\nthe function jumps to the out_scratch label without freeing the already\nallocated dsaddrs list, leading to a memory leak.\n\nFix this by jumping to the out_err_drain_dsaddrs label, which properly\nfrees the dsaddrs list before cleaning up other resources.(CVE-2026-23038)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: make calc_target() set t->paused, not just clear it\n\nCurrently calc_target() clears t->paused if the request shouldn't be\npaused anymore, but doesn't ever set t->paused even though it's able to\ndetermine when the request should be paused.  Setting t->paused is left\nto __submit_request() which is fine for regular requests but doesn't\nwork for linger requests -- since __submit_request() doesn't operate\non linger requests, there is nowhere for lreq->t.paused to be set.\nOne consequence of this is that watches don't get reestablished on\npaused -> unpaused transitions in cases where requests have been paused\nlong enough for the (paused) unwatch request to time out and for the\nsubsequent (re)watch request to enter the paused state.  On top of the\nwatch not getting reestablished, rbd_reregister_watch() gets stuck with\nrbd_dev->watch_mutex held:\n\n  rbd_register_watch\n    __rbd_register_watch\n      ceph_osdc_watch\n        linger_reg_commit_wait\n\nIt's waiting for lreq->reg_commit_wait to be completed, but for that to\nhappen the respective request needs to end up on need_resend_linger list\nand be kicked when requests are unpaused.  There is no chance for that\nif the request in question is never marked paused in the first place.\n\nThe fact that rbd_dev->watch_mutex remains taken out forever then\nprevents the image from getting unmapped -- "rbd unmap" would inevitably\nhang in D state on an attempt to grab the mutex.(CVE-2026-23047)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npNFS: Fix a deadlock when returning a delegation during open()\n\nBen Coddington reports seeing a hang in the following stack trace:\n  0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415\n  1 [ffffd0b50e177548] schedule at ffffffff9ca05717\n  2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1\n  3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb\n  4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5\n  5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4]\n  6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4]\n  7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4]\n  8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4]\n  9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4]\n 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4]\n 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4]\n 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4]\n 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4]\n 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4]\n 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4]\n 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4]\n 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea\n 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e\n 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935\n\nThe issue is that the delegreturn is being asked to wait for a layout\nreturn that cannot complete because a state recovery was initiated. The\nstate recovery cannot complete until the open() finishes processing the\ndelegations it was given.\n\nThe solution is to propagate the existing flags that indicate a\nnon-blocking call to the function pnfs_roc(), so that it knows not to\nwait in this situation.(CVE-2026-23050)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hv_netvsc: reject RSS hash key programming without RX indirection table\n\nRSS configuration requires a valid RX indirection table. When the device\nreports a single receive queue, rndis_filter_device_add() does not\nallocate an indirection table, accepting RSS hash key updates in this\nstate leads to a hang.\n\nFix this by gating netvsc_set_rxfh() on ndc->rx_table_sz and return\n-EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device\ncapabilities and prevents incorrect behavior.(CVE-2026-23054)\n\nA buffer overflow vulnerability exists in the QLogic Fibre Channel driver (qla2xxx) of the Linux kernel. In the functions `qla27xx_copy_fpin_pkt()` and `qla27xx_copy_multiple_pkt()`, the code uses the firmware-reported `frame_size` to calculate the copy length into `item->iocb`. However, the `iocb` member is defined as a fixed-size 64-byte array within `struct purex_item`. If the reported `frame_size` exceeds 64 bytes, subsequent `memcpy` calls will overflow the boundary of the `iocb` member. This cross-member write is unsafe and can lead to memory corruption, potentially exploitable to compromise the confidentiality, integrity, and availability of the kernel.(CVE-2026-23059)\n\nA NULL pointer dereference vulnerability exists in the be2net network driver within the Linux kernel, specifically in the be_cmd_get_mac_from_list() function. According to the function's contract, when the parameter pmac_id_valid is set to false, the driver may request a PMAC_ID from the network card's firmware and store it at the provided address pmac_id. However, there is a location within the driver where both conditions pmac_id_valid == false and pmac_id == NULL are passed simultaneously. This results in an attempt to dereference a NULL pointer, potentially leading to a kernel crash or system instability.(CVE-2026-23084)\n\nA memory address truncation vulnerability exists in the irqchip/gic-v3-its driver of the Linux kernel. On 32-bit ARM machines with CONFIG_ARM_LPAE enabled, when using larger VMSPLIT configurations, lowmem allocations may be backed by physical memory addresses above the 32-bit address limit. The GICv3 driver allocates the 'itt' object using GFP_KERNEL. Since all memory below the 4GB physical address limit is in ZONE_DMA in this configuration, kmalloc() defaults to higher addresses in ZONE_NORMAL. However, the driver stores these physical addresses in 32-bit 'unsigned long' variables, causing the high addresses to be truncated, which leads to system crashes.(CVE-2026-23085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nuacce: fix isolate sysfs check condition\n\nuacce supports the device isolation feature. If the driver\nimplements the isolate_err_threshold_read and\nisolate_err_threshold_write callback functions, uacce will create\nsysfs files now. Users can read and configure the isolation policy\nthrough sysfs. Currently, sysfs files are created as long as either\nisolate_err_threshold_read or isolate_err_threshold_write callback\nfunctions are present.\n\nHowever, accessing a non-existent callback function may cause the\nsystem to crash. Therefore, intercept the creation of sysfs if\nneither read nor write exists; create sysfs if either is supported,\nbut intercept unsupported operations at the call site.(CVE-2026-23094)\n\nA deadlock vulnerability exists in the Linux kernel due to incorrect lock acquisition ordering. This vulnerability affects the migration functionality for hugetlb (huge page) file folios. The specific scenario is: when two kernel tasks (Tasks) attempt to acquire the `folio_lock` and `i_mmap_rwsem` locks in opposite orders, a circular wait is formed, leading to a system deadlock. For example, Task A holds `folio_lock` and then tries to acquire the `i_mmap_rwsem` read lock, while Task B holds the `i_mmap_rwsem` write lock and then tries to acquire `folio_lock`. This lock ordering violates the rules defined in mm/rmap.c. This vulnerability can render parts of the affected system unavailable, impacting system availability.(CVE-2026-23097)\n\nIn the Linux kernel SCSI core layer, there is a fragile ordering logic between marking commands as completed or failed, designed to ensure the error handler only wakes when the last running command completes or times out. This logic contains race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance. Specifically, there are two issues: 1. A memory ordering issue within the `scsi_dec_host_busy()` function. The write operation that clears the `SCMD_STATE_INFLIGHT` flag may be reordered with read counting operations in `scsi_host_busy()`. This can cause other CPUs to see inconsistent busy counts, preventing the correct triggering of the error handler wake-up. 2. A general ordering issue with the `scsi_eh_inc_host_failed()` function. It counts busy commands before incrementing the `host_failed` count, which can race with the processing of a final command in `scsi_dec_host_busy()`, resulting in neither side waking the error handler task.(CVE-2026-23110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec\n\nnvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU\nlength or offset exceeds sg_cnt and then use bogus sg->length/offset\nvalues, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining\nentries, and sg->length/offset before building the bvec.(CVE-2026-23112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove\n\nOn APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and\nih2 interrupt ring buffers are not initialized. This is by design, as\nthese secondary IH rings are only available on discrete GPUs. See\nvega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when\nAMD_IS_APU is set.\n\nHowever, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to\nget the timestamp of the last interrupt entry. When retry faults are\nenabled on APUs (noretry=0), this function is called from the SVM page\nfault recovery path, resulting in a NULL pointer dereference when\namdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[].\n\nThe crash manifests as:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000004\n  RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu]\n  Call Trace:\n   amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu]\n   svm_range_restore_pages+0xae5/0x11c0 [amdgpu]\n   amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu]\n   gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu]\n   amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu]\n   amdgpu_ih_process+0x84/0x100 [amdgpu]\n\nThis issue was exposed by commit 1446226d32a4 ("drm/amdgpu: Remove GC HW\nIP 9.3.0 from noretry=1") which changed the default for Renoir APU from\nnoretry=1 to noretry=0, enabling retry fault handling and thus\nexercising the buggy code path.\n\nFix this by adding a check for ih1.ring_size before attempting to use\nit. Also restore the soft_ih support from commit dd299441654f ("drm/amdgpu:\nRework retry fault removal").  This is needed if the hardware doesn't\nsupport secondary HW IH rings.\n\nv2: additional updates (Alex)\n\n(cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)(CVE-2026-23163)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: fixup hang in nvmet_tcp_listen_data_ready()\n\nWhen the socket is closed while in TCP_LISTEN a callback is run to\nflush all outstanding packets, which in turns calls\nnvmet_tcp_listen_data_ready() with the sk_callback_lock held.\nSo we need to check if we are in TCP_LISTEN before attempting\nto get the sk_callback_lock() to avoid a deadlock.(CVE-2026-23179)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: amd: fix memory leak in acp3x pdm dma ops(CVE-2026-23190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()\n\nIn iscsit_dec_session_usage_count(), the function calls complete() while\nholding the sess->session_usage_lock. Similar to the connection usage count\nlogic, the waiter signaled by complete() (e.g., in the session release\npath) may wake up and free the iscsit_session structure immediately.\n\nThis creates a race condition where the current thread may attempt to\nexecute spin_unlock_bh() on a session structure that has already been\ndeallocated, resulting in a KASAN slab-use-after-free.\n\nTo resolve this, release the session_usage_lock before calling complete()\nto ensure all dereferences of the sess pointer are finished before the\nwaiter is allowed to proceed with deallocation.(CVE-2026-23193)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb/client: fix memory leak in smb2_open_file()\n\nReproducer:\n\n  1. server: directories are exported read-only\n  2. client: mount -t cifs //${server_ip}/export /mnt\n  3. client: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct\n  4. client: umount /mnt\n  5. client: sleep 1\n  6. client: modprobe -r cifs\n\nThe error message is as follows:\n\n  =============================================================================\n  BUG cifs_small_rq (Not tainted): Objects remaining on __kmem_cache_shutdown()\n  -----------------------------------------------------------------------------\n\n  Object 0x00000000d47521be @offset=14336\n  ...\n  WARNING: mm/slub.c:1251 at __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577\n  ...\n  Call Trace:\n   <TASK>\n   kmem_cache_destroy+0x94/0x190\n   cifs_destroy_request_bufs+0x3e/0x50 [cifs]\n   cleanup_module+0x4e/0x540 [cifs]\n   __se_sys_delete_module+0x278/0x400\n   __x64_sys_delete_module+0x5f/0x70\n   x64_sys_call+0x2299/0x2ff0\n   do_syscall_64+0x89/0x350\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  ...\n  kmem_cache_destroy cifs_small_rq: Slab cache still has objects when called from cifs_destroy_request_bufs+0x3e/0x50 [cifs]\n  WARNING: mm/slab_common.c:532 at kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577(CVE-2026-23205)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()\n\nIn iscsit_dec_conn_usage_count(), the function calls complete() while\nholding the conn->conn_usage_lock. As soon as complete() is invoked, the\nwaiter (such as iscsit_close_connection()) may wake up and proceed to free\nthe iscsit_conn structure.\n\nIf the waiter frees the memory before the current thread reaches\nspin_unlock_bh(), it results in a KASAN slab-use-after-free as the function\nattempts to release a lock within the already-freed connection structure.\n\nFix this by releasing the spinlock before calling complete().(CVE-2026-23216)\n\nIn the Linux kernel, the ksmbd component contains an infinite loop vulnerability. The problem occurs when a signed request fails smb2 signature verification check. In __process_request(), if check_sign_req() returns an error, set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called. set_smb2_rsp_status() sets work->next_smb2_rcv_hdr_off to zero. By resetting next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain is lost. Consequently, is_chained_smb2_message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing __handle_ksmbd_work() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with "bad smb2 signature" messages and high CPU usage.(CVE-2026-23220)\n\nIn the Linux kernel, the following vulnerability has been resolved:  smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()  On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is freed via free_transport(), which does not decrement active_num_conn, leaking this counter.  Replace free_transport() with ksmbd_tcp_disconnect().  The Linux kernel CVE team has assigned CVE-2026-23228 to this issue.(CVE-2026-23228)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-142.0.0.136.oe2403sp1"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","kernel-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","perf-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-142.0.0.136.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-142.0.0.136.oe2403sp1.src.rpm"],"x86_64":["bpftool-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","kernel-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","perf-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-142.0.0.136.oe2403sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1566"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57974"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22090"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38491"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38627"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38660"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39764"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39902"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-39948"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40323"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40329"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68192"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68194"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68204"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68209"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68211"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68231"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68237"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68282"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68293"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68313"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68768"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68785"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68819"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68822"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71065"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71068"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71083"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71084"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71091"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71096"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71097"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71118"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71120"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71129"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71141"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71186"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71220"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71221"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71223"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71225"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71232"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71235"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-71236"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-22977"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-22979"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-22984"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-22991"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-22999"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23003"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23010"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23011"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23025"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23032"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23038"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23047"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23050"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23054"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23059"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23084"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23085"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23094"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23097"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23110"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23112"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23163"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23179"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23190"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23193"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23205"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23216"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23220"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-23228"}],"database_specific":{"severity":"High"}}