URL	Tags
https://git.kernel.org/stable/c/88dd6be7ebb3153b6…
https://git.kernel.org/stable/c/c655d2167bf014d4c…
https://git.kernel.org/stable/c/8c6901aa29626e350…
https://git.kernel.org/stable/c/582a5e922a9652fcb…
https://git.kernel.org/stable/c/005671c60fcf1dbdb…
https://git.kernel.org/stable/c/e00b169eaac5f7cdb…
https://git.kernel.org/stable/c/2a71a1a8d0ed718b1…
https://cert-portal.siemens.com/productcert/html/…
https://cert-portal.siemens.com/productcert/html/…

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 6d07d1cd300f4c7e16005f881fea388164999cc8 , < 88dd6be7ebb3153b662c2cebcb06e032a92857f5 (git) Affected: 6d07d1cd300f4c7e16005f881fea388164999cc8 , < c655d2167bf014d4c61b4faeca59b60ff9b9f6b1 (git) Affected: 6d07d1cd300f4c7e16005f881fea388164999cc8 , < 8c6901aa29626e35045130bac09b75f791acca85 (git) Affected: 6d07d1cd300f4c7e16005f881fea388164999cc8 , < 582a5e922a9652fcbb7d0165c95d5b20aa37575d (git) Affected: 6d07d1cd300f4c7e16005f881fea388164999cc8 , < 005671c60fcf1dbdb8bddf12a62568fd5e4ec391 (git) Affected: 6d07d1cd300f4c7e16005f881fea388164999cc8 , < e00b169eaac5f7cdbf710c354c8fa76d02009115 (git) Affected: 6d07d1cd300f4c7e16005f881fea388164999cc8 , < 2a71a1a8d0ed718b1c7a9ac61f07e5755c47ae20 (git)	guessed
Linux	Linux	Affected: 4.16 Unaffected: 0 , < 4.16 (semver) Unaffected: 5.10.248 , ≤ 5.10.* (semver) Unaffected: 5.15.198 , ≤ 5.15.* (semver) Unaffected: 6.1.161 , ≤ 6.1.* (semver) Unaffected: 6.6.121 , ≤ 6.6.* (semver) Unaffected: 6.12.66 , ≤ 6.12.* (semver) Unaffected: 6.18.6 , ≤ 6.18.* (semver) Unaffected: 6.19 , ≤ * (original_commit_for_fix)	guessed
Siemens	RUGGEDCOM RST2428P	Affected: 0 , < V4.0 (custom)	guessed
Siemens	SIMATIC S7-1500 CPU 1518-4 PN/DP MFP	Affected: V3.1.6 , < * (custom)	guessed
Siemens	SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP	Affected: V3.1.6 , < * (custom)	guessed
Siemens	SIPLUS S7-1500 CPU 1518-4 PN/DP MFP	Affected: V3.1.6 , < * (custom)	guessed

oesa-2026-1566

Vulnerability from osv_openeuler

Published

2026-03-15 11:10

Modified

2026-08-06 11:10

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

udp: Deal with race between UDP socket address change and rehash

If a UDP socket changes its local address while it's receiving datagrams, as a result of connect(), there is a period during which a lookup operation might fail to find it, after the address is changed but before the secondary hash (port and address) and the four-tuple hash (local and remote ports and addresses) are updated.

Secondary hash chains were introduced by commit 30fff9231fad ("udp: bind() optimisation") and, as a result, a rehash operation became needed to make a bound socket reachable again after a connect().

This operation was introduced by commit 719f835853a9 ("udp: add rehash on connect()") which isn't however a complete fix: the socket will be found once the rehashing completes, but not while it's pending.

This is noticeable with a socat(1) server in UDP4-LISTEN mode, and a client sending datagrams to it. After the server receives the first datagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to the address of the sender, in order to set up a directed flow.

Now, if the client, running on a different CPU thread, happens to send a (subsequent) datagram while the server's socket changes its address, but is not rehashed yet, this will result in a failed lookup and a port unreachable error delivered to the client, as apparent from the following reproducer:

LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in

while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null wait done

where the client will eventually get ECONNREFUSED on a write() (typically the second or third one of a given iteration):

2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused

This issue was first observed as a seldom failure in Podman's tests checking UDP functionality while using pasta(1) to connect the container's network namespace, which leads us to a reproducer with the lookup error resulting in an ICMP packet on a tap device:

LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')"

while :; do ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.2 || sleep 1 socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out done

Once this fails:

tmp.in tmp.out differ: char 8193, line 29

we can finally have a look at what's going on:

$ tshark -r pasta.pcap 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164 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 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0

On the third datagram received, the network namespace of the container initiates an ARP lookup to deliver the ICMP message.

In another variant of this reproducer, starting the client with:

strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru ---truncated---(CVE-2024-57974)

In the Linux kernel, the following vulnerability has been resolved:

x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()

If track_pfn_copy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables.

Consequently untrack_pfn() will see VM_PAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied.

The easiest fix would be to simply clear the VM_PAT flag of the dst VMA if track_pfn_copy() fails. However, the whole thing is about "simply" clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy() and performed a reservation, but copying the page tables fails, we'll simply clear the VM_PAT flag, not properly undoing the reservation ... which is also wrong.

So let's fix it properly: set the VM_PAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VM_PAT flag after undoing the reservation.

Note that any copied page table entries will get zapped when the VMA will get removed later, after copy_page_range() succeeded; as VM_PAT is not set then, we won't try cleaning VM_PAT up once more and untrack_pfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run.

A reproducer can trigger this usually at the first try:

https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c

WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: <TASK> ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180

Likely this case was missed in:

d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")

... and instead of undoing the reservation we simply cleared the VM_PAT flag.

Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like track_pfn_remap/untrack_pfn separately.(CVE-2025-22090)

In the Linux kernel, the following vulnerability has been resolved:

mptcp: make fallback action and fallback decision atomic

Syzkaller reported the following splat:

WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline] RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153 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 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: <IRQ> tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432 tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975 tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166 tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925 tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363 ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:469 [inline] ip_rcv_finish net/ipv4/ip_input.c:447 [inline] NF_HOOK include/linux/netfilter.h:317 [inline] NF_HOOK include/linux/netfilter.h:311 [inline] ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975 __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088 process_backlog+0x301/0x1360 net/core/dev.c:6440 __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453 napi_poll net/core/dev.c:7517 [inline] net_rx_action+0xb44/0x1010 net/core/dev.c:7644 handle_softirqs+0x1d0/0x770 kernel/softirq.c:579 do_softirq+0x3f/0x90 kernel/softirq.c:480 </IRQ> <TASK> __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407 local_bh_enable include/linux/bottom_half.h:33 [inline] inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524 mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcp_check_listen_stop net/mptcp/mib.h:118 [inline] __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066 inet_release+0xed/0x200 net/ipv4/af_inet.c:435 inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x402/0xb70 fs/file_table.c:465 task_work_run+0x150/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xd4 ---truncated---(CVE-2025-38491)

In the Linux kernel, the following vulnerability has been resolved:

f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic

The decompress_io_ctx may be released asynchronously after I/O completion. If this file is deleted immediately after read, and the kworker of processing post_read_wq has not been executed yet due to high workloads, It is possible that the inode(f2fs_inode_info) is evicted and freed before it is used f2fs_free_dic.

The UAF case as below:
Thread A                                      Thread B
- f2fs_decompress_end_io
 - f2fs_put_dic
  - queue_work
    add free_dic work to post_read_wq
                                               - do_unlink
                                                - iput
                                                 - evict
                                                  - call_rcu
This file is deleted after read.

Thread C                                 kworker to process post_read_wq
- rcu_do_batch
 - f2fs_free_inode
  - kmem_cache_free
 inode is freed by rcu
                                         - process_scheduled_works
                                          - f2fs_late_free_dic
                                           - f2fs_free_dic
                                            - f2fs_release_decomp_mem
                                  read (dic-&gt;inode)-&gt;i_compress_algorithm

This patch store compress_algorithm and sbi in dic to avoid inode UAF.

In addition, the previous solution is deprecated in [1] may cause system hang. [1] https://lore.kernel.org/all/(CVE-2025-38627)

In the Linux kernel, the following vulnerability has been resolved:

[ceph] parse_longname(): strrchr() expects NUL-terminated string

... and parse_longname() is not guaranteed that. That's the reason why it uses kmemdup_nul() to build the argument for kstrtou64(); the problem is, kstrtou64() is not the only thing that need it.

Just get a NUL-terminated copy of the entire thing and be done with that...(CVE-2025-38660)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcount_inc_not_zero(&exp->use))

to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.(CVE-2025-39764)

In the Linux kernel, the following vulnerability has been resolved:

mm/slub: avoid accessing metadata when pointer is invalid in object_err()

object_err() reports details of an object for further debugging, such as the freelist pointer, redzone, etc. However, if the pointer is invalid, attempting to access object metadata can lead to a crash since it does not point to a valid object.

One known path to the crash is when alloc_consistency_checks() determines the pointer to the allocated object is invalid because of a freelist corruption, and calls object_err() to report it. The debug code should report and handle the corruption gracefully and not crash in the process.

In case the pointer is NULL or check_valid_pointer() returns false for the pointer, only print the pointer value and skip accessing metadata.(CVE-2025-39902)

In the Linux kernel, the following vulnerability has been resolved:

ice: fix Rx page leak on multi-buffer frames

The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver.

It works by iterating over the buffers from first_desc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed.

If the hardware posts a descriptor with a size of 0, the logic used in ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't call ice_put_rx_buf().

Because we don't call ice_put_rx_buf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment next_to_alloc.

The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't check, it will happily recycle a page over the top of the next_to_alloc buffer, losing track of the old page.

Note that this leak only occurs for multi-buffer frames. The ice_put_rx_mbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0 sometimes, but it happens somewhat regularly with "jumbo frames" used by 9K MTU.

To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on all buffers between first_desc and next_to_clean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in ice_get_pgcnts().

Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the next_to_clean element just past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does call ice_put_rx_buf() on the last buffer of the frame indicating the end of packet.

For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecnt_bias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecnt_bias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss.

The xdp_xmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdp_xmit pointer argument from ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame.

Move the increment of the ntc local variable to ensure its updated before all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic requires the index of the element just after the current frame.

Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rx_ring.(CVE-2025-39948)

In the Linux kernel, the following vulnerability has been resolved:

fbcon: Set fb_display[i]->mode to NULL when the mode is released

Recently, we discovered the following issue through syzkaller:

BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: <TASK> dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0.

Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL.(CVE-2025-40323)

In the Linux kernel, the following vulnerability has been resolved:

drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb

The Mesa issue referenced below pointed out a possible deadlock:

[ 1231.611031] Possible interrupt unsafe locking scenario:

[ 1231.611033] CPU0 CPU1 [ 1231.611034] ---- ---- [ 1231.611035] lock(&xa->xa_lock#17); [ 1231.611038] local_irq_disable(); [ 1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xa_lock#17); [ 1231.611044] <Interrupt> [ 1231.611045] lock(&fence->lock); [ 1231.611047] *** DEADLOCK ***

In this example, CPU0 would be any function accessing job->dependencies through the xa_* functions that don't disable interrupts (eg: drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).

CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling callback so in an interrupt context. It will deadlock when trying to grab the xa_lock which is already held by CPU0.

Replacing all xa_ usage by their xa__irq counterparts would fix this issue, but Christian pointed out another issue: dma_fence_signal takes fence.lock and so does dma_fence_add_callback.

dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lock

This will deadlock if f1 and f2 share the same spinlock.

To fix both issues, the code iterating on dependencies and re-arming them is moved out to drm_sched_entity_kill_jobs_work().

phasta: commit message nits

In the Linux kernel, the following vulnerability has been resolved:

net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup

Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks.

Initialize the MAC header to prevent such crashes.

This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface.

Example trace:

Internal error: Oops: 000000009600004f [#1] SMP
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1
Hardware name: LS1028A RDB Board (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : xfrm_input+0xde8/0x1318
lr : xfrm_input+0x61c/0x1318
sp : ffff800080003b20
Call trace:
 xfrm_input+0xde8/0x1318
 xfrm6_rcv+0x38/0x44
 xfrm6_esp_rcv+0x48/0xa8
 ip6_protocol_deliver_rcu+0x94/0x4b0
 ip6_input_finish+0x44/0x70
 ip6_input+0x44/0xc0
 ipv6_rcv+0x6c/0x114
 __netif_receive_skb_one_core+0x5c/0x8c
 __netif_receive_skb+0x18/0x60
 process_backlog+0x78/0x17c
 __napi_poll+0x38/0x180
 net_rx_action+0x168/0x2f0(CVE-2025-68192)

In the Linux kernel, the following vulnerability has been resolved:

media: imon: make send_packet() more robust

syzbot is reporting that imon has three problems which result in hung tasks due to forever holding device lock [1].

First problem is that when usb_rx_callback_intf0() once got -EPROTO error after ictx->dev_present_intf0 became true, usb_rx_callback_intf0() resubmits urb after printk(), and resubmitted urb causes usb_rx_callback_intf0() to again get -EPROTO error. This results in printk() flooding (RCU stalls).

Alan Stern commented [2] that

In theory it's okay to resubmit if the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away.

but imon has a poor error-recovery scheme which just retries forever; this behavior should be fixed.

Since I'm not sure whether it is safe for imon users to give up upon any error code, this patch takes care of only union of error codes chosen from modules in drivers/media/rc/ directory which handle -EPROTO error (i.e. ir_toy, mceusb and igorplugusb).

Second problem is that when usb_rx_callback_intf0() once got -EPROTO error before ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() always resubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedge hardware after early callbacks"). Move the ictx->dev_present_intf0 test introduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodes until intf configured") to immediately before imon_incoming_packet(), or the first problem explained above happens without printk() flooding (i.e. hung task).

Third problem is that when usb_rx_callback_intf0() is not called for some reason (e.g. flaky hardware; the reproducer for this problem sometimes prevents usb_rx_callback_intf0() from being called), wait_for_completion_interruptible() in send_packet() never returns (i.e. hung task). As a workaround for such situation, change send_packet() to wait for completion with timeout of 10 seconds.(CVE-2025-68194)

In the Linux kernel, the following vulnerability has been resolved:

pmdomain: arm: scmi: Fix genpd leak on provider registration failure

If of_genpd_add_provider_onecell() fails during probe, the previously created generic power domains are not removed, leading to a memory leak and potential kernel crash later in genpd_debug_add().

Add proper error handling to unwind the initialized domains before returning from probe to ensure all resources are correctly released on failure.

Example crash trace observed without this fix:

In the Linux kernel, the following vulnerability has been resolved:

mlx5: Fix default values in create CQ

Currently, CQs without a completion function are assigned the mlx5_add_cq_to_tasklet function by default. This is problematic since only user CQs created through the mlx5_ib driver are intended to use this function.

Additionally, all CQs that will use doorbells instead of polling for completions must call mlx5_cq_arm. However, the default CQ creation flow leaves a valid value in the CQ's arm_db field, allowing FW to send interrupts to polling-only CQs in certain corner cases.

These two factors would allow a polling-only kernel CQ to be triggered by an EQ interrupt and call a completion function intended only for user CQs, causing a null pointer exception.

Some areas in the driver have prevented this issue with one-off fixes but did not address the root cause.

This patch fixes the described issue by adding defaults to the create CQ flow. It adds a default dummy completion function to protect against null pointer exceptions, and it sets an invalid command sequence number by default in kernel CQs to prevent the FW from sending an interrupt to the CQ until it is armed. User CQs are responsible for their own initialization values.

Callers of mlx5_core_create_cq are responsible for changing the completion function and arming the CQ per their needs.(CVE-2025-68209)

In the Linux kernel, the following vulnerability has been resolved:

ksm: use range-walk function to jump over holes in scan_get_next_rmap_item

Currently, scan_get_next_rmap_item() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages.

This patch replaces the per-address lookup with a range walk using walk_page_range(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1].

Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page:

include <unistd.h>

include <stdio.h>

include <sys/mman.h>

/ 32 TiB / const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;

int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0);

    if (area == MAP_FAILED) {
            perror(&quot;mmap() failed\n&quot;);
            return -1;
    }

    /* Populate a single page such that we get an anon_vma. */
    *area = 0;

    /* Enable KSM. */
    madvise(area, size, MADV_MERGEABLE);
    pause();
    return 0;

}

$ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run

Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.(CVE-2025-68211)

In the Linux kernel, the following vulnerability has been resolved:

mm/mempool: fix poisoning order>0 pages with HIGHMEM

The kernel test has reported:

BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page pde = 03171067 pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) 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 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283)

Christoph found out this is due to the poisoning code not dealing properly with CONFIG_HIGHMEM because only the first page is mapped but then the whole potentially high-order page is accessed.

We could give up on HIGHMEM here, but it's straightforward to fix this with a loop that's mapping, poisoning or checking and unmapping individual pages.(CVE-2025-68231)

In the Linux kernel, the following vulnerability has been resolved:

mtdchar: fix integer overflow in read/write ioctls

The "req.start" and "req.len" variables are u64 values that come from the user at the start of the function. We mask away the high 32 bits of "req.len" so that's capped at U32_MAX but the "req.start" variable can go up to U64_MAX which means that the addition can still integer overflow.

Use check_add_overflow() to fix this bug.(CVE-2025-68237)

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: udc: fix use-after-free in usb_gadget_state_work

A race condition during gadget teardown can lead to a use-after-free in usb_gadget_state_work(), as reported by KASAN:

BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_work

The fundamental race occurs because a concurrent event (e.g., an interrupt) can call usb_gadget_set_state() and schedule gadget->work at any time during the cleanup process in usb_del_gadget().

Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after device removal") attempted to fix this by moving flush_work() to after device_del(). However, this does not fully solve the race, as a new work item can still be scheduled after flush_work() completes but before the gadget's memory is freed, leading to the same use-after-free.

This patch fixes the race condition robustly by introducing a 'teardown' flag and a 'state_lock' spinlock to the usb_gadget struct. The flag is set during cleanup in usb_del_gadget() before calling flush_work() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usb_gadget_set_state(), now checks this flag under the lock before queueing the work, thus safely closing the race window.(CVE-2025-68282)

In the Linux kernel, the following vulnerability has been resolved:

mm/huge_memory: fix NULL pointer deference when splitting folio

Commit c010d47f107f ("mm: thp: split huge page to any lower order pages") introduced an early check on the folio's order via mapping->flags before proceeding with the split work.

This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference.

This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags.(CVE-2025-68293)

In the Linux kernel, the following vulnerability has been resolved:

x86/CPU/AMD: Add RDSEED fix for Zen5

There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 "at a rate inconsistent with randomness while incorrectly signaling success (CF=1)". Search the web for AMD-SB-7055 for more detail.

Add a fix glue which checks microcode revisions.

bp: Add microcode revisions checking, rewrite.

In the Linux kernel, the following vulnerability has been resolved:

inet: frags: flush pending skbs in fqdir_pre_exit()

We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports.

On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references.

The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run after conntrack's netns exit hook.

Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush.

The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.(CVE-2025-68768)

In the Linux kernel, the following vulnerability has been resolved:

net: openvswitch: fix middle attribute validation in push_nsh() action

The push_nsh() action structure looks like this:

OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))

The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by the nla_for_each_nested() inside __ovs_nla_copy_actions(). The innermost OVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested() inside nsh_key_put_from_nlattr(). But nothing checks if the attribute in the middle is OK. We don't even check that this attribute is the OVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data() calls - first time directly while calling validate_push_nsh() and the second time as part of the nla_for_each_nested() macro, which isn't safe, potentially causing invalid memory access if the size of this attribute is incorrect. The failure may not be noticed during validation due to larger netlink buffer, but cause trouble later during action execution where the buffer is allocated exactly to the size:

BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624

CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] push_nsh+0x82/0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>

Let's add some checks that the attribute is properly sized and it's the only one attribute inside the action. Technically, there is no real reason for OVS_KEY_ATTR_NSH to be there, as we know that we're pushing an NSH header already, it just creates extra nesting, but that's how uAPI works today. So, keeping as it is.(CVE-2025-68785)

In the Linux kernel, the following vulnerability has been resolved:

media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()

rlen value is a user-controlled value, but dtv5100_i2c_msg() does not check the size of the rlen value. Therefore, if it is set to a value larger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.

Therefore, we need to add proper range checking to prevent this vuln.(CVE-2025-68819)

In the Linux kernel, the following vulnerability has been resolved:

Input: alps - fix use-after-free bugs caused by dev3_register_work

The dev3_register_work delayed work item is initialized within alps_reconnect() and scheduled upon receipt of the first bare PS/2 packet from an external PS/2 device connected to the ALPS touchpad. During device detachment, the original implementation calls flush_workqueue() in psmouse_disconnect() to ensure completion of dev3_register_work. However, the flush_workqueue() in psmouse_disconnect() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after flush_workqueue() has finished executing, the dev3_register_work could still be scheduled. Although the psmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(), the scheduling of dev3_register_work remains unaffected.

The race condition can occur as follows:

Add disable_delayed_work_sync() in alps_disconnect() to ensure that dev3_register_work is properly canceled and prevented from executing after the alps_data structure has been deallocated.

This bug is identified by static analysis.(CVE-2025-68822)

In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid potential deadlock

As Jiaming Zhang and syzbot reported, there is potential deadlock in f2fs as below:

Chain exists of: &sbi->cp_rwsem --> fs_reclaim --> sb_internal#2

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

rlock(sb_internal#2); lock(fs_reclaim); lock(sb_internal#2); rlock(&sbi->cp_rwsem);

*** DEADLOCK ***

3 locks held by kswapd0/73: #0: ffffffff8e247a40 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat mm/vmscan.c:7015 [inline] #0: ffffffff8e247a40 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x951/0x2800 mm/vmscan.c:7389 #1: ffff8880118400e0 (&type->s_umount_key#50){.+.+}-{4:4}, at: super_trylock_shared fs/super.c:562 [inline] #1: ffff8880118400e0 (&type->s_umount_key#50){.+.+}-{4:4}, at: super_cache_scan+0x91/0x4b0 fs/super.c:197 #2: ffff888011840610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x8d9/0x1b60 fs/f2fs/inode.c:890

stack backtrace: CPU: 0 UID: 0 PID: 73 Comm: kswapd0 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_circular_bug+0x2ee/0x310 kernel/locking/lockdep.c:2043 check_noncircular+0x134/0x160 kernel/locking/lockdep.c:2175 check_prev_add kernel/locking/lockdep.c:3165 [inline] check_prevs_add kernel/locking/lockdep.c:3284 [inline] validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3908 __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5237 lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868 down_read+0x46/0x2e0 kernel/locking/rwsem.c:1537 f2fs_down_read fs/f2fs/f2fs.h:2278 [inline] f2fs_lock_op fs/f2fs/f2fs.h:2357 [inline] f2fs_do_truncate_blocks+0x21c/0x10c0 fs/f2fs/file.c:791 f2fs_truncate_blocks+0x10a/0x300 fs/f2fs/file.c:867 f2fs_truncate+0x489/0x7c0 fs/f2fs/file.c:925 f2fs_evict_inode+0x9f2/0x1b60 fs/f2fs/inode.c:897 evict+0x504/0x9c0 fs/inode.c:810 f2fs_evict_inode+0x1dc/0x1b60 fs/f2fs/inode.c:853 evict+0x504/0x9c0 fs/inode.c:810 dispose_list fs/inode.c:852 [inline] prune_icache_sb+0x21b/0x2c0 fs/inode.c:1000 super_cache_scan+0x39b/0x4b0 fs/super.c:224 do_shrink_slab+0x6ef/0x1110 mm/shrinker.c:437 shrink_slab_memcg mm/shrinker.c:550 [inline] shrink_slab+0x7ef/0x10d0 mm/shrinker.c:628 shrink_one+0x28a/0x7c0 mm/vmscan.c:4955 shrink_many mm/vmscan.c:5016 [inline] lru_gen_shrink_node mm/vmscan.c:5094 [inline] shrink_node+0x315d/0x3780 mm/vmscan.c:6081 kswapd_shrink_node mm/vmscan.c:6941 [inline] balance_pgdat mm/vmscan.c:7124 [inline] kswapd+0x147c/0x2800 mm/vmscan.c:7389 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>

The root cause is deadlock among four locks as below:

kswapd - fs_reclaim --- Lock A - shrink_one - evict - f2fs_evict_inode - sb_start_intwrite --- Lock B

iput
evict
f2fs_evict_inode
sb_start_intwrite --- Lock B
f2fs_truncate
- f2fs_truncate_blocks
- f2fs_do_truncate_blocks
- f2fs_lock_op --- Lock C

ioctl - f2fs_ioc_commit_atomic_write - f2fs_lock_op --- Lock C - __f2fs_commit_atomic_write - __replace_atomic_write_block - f2fs_get_dnode_of_data - __get_node_folio - f2fs_check_nid_range - f2fs_handle_error - f2fs_record_errors - f2fs_down_write --- Lock D

open - do_open - do_truncate - security_inode_need_killpriv - f2fs_getxattr - lookup_all_xattrs - f2fs_handle_error - f2fs_record_errors - f2fs_down_write --- Lock D - f2fs_commit_super - read_mapping_folio - filemap_alloc_folio_noprof - prepare_alloc_pages - fs_reclaim_acquire --- Lock A

In order to a ---truncated---(CVE-2025-71065)

In the Linux kernel, the following vulnerability has been resolved:

svcrdma: bound check rq_pages index in inline path

svc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] without verifying rc_curpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.(CVE-2025-71068)

In the Linux kernel, the following vulnerability has been resolved:

drm/ttm: Avoid NULL pointer deref for evicted BOs

It is possible for a BO to exist that is not currently associated with a resource, e.g. because it has been evicted.

When devcoredump tries to read the contents of all BOs for dumping, we need to expect this as well -- in this case, ENODATA is recorded instead of the buffer contents.(CVE-2025-71083)

In the Linux kernel, the following vulnerability has been resolved:

RDMA/cm: Fix leaking the multicast GID table reference

If the CM ID is destroyed while the CM event for multicast creating is still queued the cancel_work_sync() will prevent the work from running which also prevents destroying the ah_attr. This leaks a refcount and triggers a WARN:

GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886

Destroy the ah_attr after canceling the work, it is safe to call this twice.(CVE-2025-71084)

In the Linux kernel, the following vulnerability has been resolved:

team: fix check for port enabled in team_queue_override_port_prio_changed()

There has been a syzkaller bug reported recently with the following trace:

list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:59! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59 Code: 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 RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286 RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000 RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005 RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230 R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480 FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0 Call Trace: <TASK> __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] _syssendmsg+0xa98/0xc70 net/socket.c:2630 _sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The problem is in this flow: 1) Port is enabled, queue_id != 0, in qom_list 2) Port gets disabled -> team_port_disable() -> team_queue_override_port_del() -> del (removed from list) 3) Port is disabled, queue_id != 0, not in any list 4) Priority changes -> team_queue_override_port_prio_changed() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed already

To fix this, change the check in team_queue_override_port_prio_changed() so it returns early if port is not enabled.(CVE-2025-71091)

In the Linux kernel, the following vulnerability has been resolved:

RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctly

The netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have a LS_NLA_TYPE_DGID attribute, it is invalid if it does not.

Use the nl parsing logic properly and call nla_parse_deprecated() to fill the nlattrs array and then directly index that array to get the data for the DGID. Just fail if it is NULL.

Remove the for loop searching for the nla, and squash the validation and parsing into one function.

Fixes an uninitialized read from the stack triggered by userspace if it does not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVE query.

BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline]
BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490
 hex_byte_pack include/linux/hex.h:13 [inline]
 ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490
 ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509
 ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633
 pointer+0xc09/0x1bd0 lib/vsprintf.c:2542
 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930
 vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279
 vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426
 vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465
 vprintk+0x36/0x50 kernel/printk/printk_safe.c:82
 _printk+0x17e/0x1b0 kernel/printk/printk.c:2475
 ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline]
 ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141
 rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline]
 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
 rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259
 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
 netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346
 netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896
 sock_sendmsg_nosec net/socket.c:714 [inline]
 __sock_sendmsg+0x333/0x3d0 net/socket.c:729
 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617
 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671
 __sys_sendmsg+0x1aa/0x300 net/socket.c:2703
 __compat_sys_sendmsg net/compat.c:346 [inline]
 __do_compat_sys_sendmsg net/compat.c:353 [inline]
 __se_compat_sys_sendmsg net/compat.c:350 [inline]
 __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350
 ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371
 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
 __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306
 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331
 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3(CVE-2025-71096)

In the Linux kernel, the following vulnerability has been resolved:

ipv4: Fix reference count leak when using error routes with nexthop objects

When a nexthop object is deleted, it is marked as dead and then fib_table_flush() is called to flush all the routes that are using the dead nexthop.

The current logic in fib_table_flush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flush_all=true). Therefore, error routes are not flushed when their nexthop object is deleted:

# ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1

As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak:

# ip link del dev dummy1 [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2

Fix by flushing error routes when their nexthop is marked as dead.

IPv6 does not suffer from this problem.(CVE-2025-71097)

In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Avoid walking the Namespace if start_node is NULL

Although commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespace if it is not there") fixed the situation when both start_node and acpi_gbl_root_node are NULL, the Linux kernel mainline now still crashed on Honor Magicbook 14 Pro [1].

That happens due to the access to the member of parent_node in acpi_ns_get_next_node(). The NULL pointer dereference will always happen, no matter whether or not the start_node is equal to ACPI_ROOT_OBJECT, so move the check of start_node being NULL out of the if block.

Unfortunately, all the attempts to contact Honor have failed, they refused to provide any technical support for Linux.

The bad DSDT table's dump could be found on GitHub [2].

DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025

rjw: Subject adjustment, changelog edits

In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf

A zero length gss_token results in pages == 0 and in_token->pages[0] is NULL. The code unconditionally evaluates page_address(in_token->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.(CVE-2025-71120)

In the Linux kernel, the following vulnerability has been resolved:

LoongArch: BPF: Sign extend kfunc call arguments

The kfunc calls are native calls so they should follow LoongArch calling conventions. Sign extend its arguments properly to avoid kernel panic. This is done by adding a new emit_abi_ext() helper. The emit_abi_ext() helper performs extension in place meaning a value already store in the target register (Note: this is different from the existing sign_extend() helper and thus we can't reuse it).(CVE-2025-71129)

In the Linux kernel, the following vulnerability has been resolved:

drm/tilcdc: Fix removal actions in case of failed probe

The drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdc_fini(), which causes warnings during probe deferral scenarios.

[ 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 ... [ 8.005820] drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108 [ 8.005858] drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8 [ 8.005885] drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144 [ 8.005911] drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc]

Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary is_registered flag.(CVE-2025-71141)

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: stm32: dmamux: fix device leak on route allocation

Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.

Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.(CVE-2025-71186)

In the Linux kernel, the following vulnerability has been resolved:

smb/server: call ksmbd_session_rpc_close() on error path in create_smb2_pipe()

When ksmbd_iov_pin_rsp() fails, we should call ksmbd_session_rpc_close().(CVE-2025-71220)

In 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.

The 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).

The fix involves protecting the chain_running list iteration and descriptor access with the chan->desc_lock spinlock.(CVE-2025-71221)

In the Linux kernel, the following vulnerability has been resolved:

smb/server: fix refcount leak in smb2_open()

When ksmbd_vfs_getattr() fails, the reference count of ksmbd_file must be released.(CVE-2025-71223)

In the Linux kernel, the following vulnerability has been resolved:

md: suspend array while updating raid_disks via sysfs

In raid1_reshape(), freeze_array() is called before modifying the r1bio memory pool (conf->r1bio_pool) and conf->raid_disks, and unfreeze_array() is called after the update is completed.

However, freeze_array() only waits until nr_sync_pending and (nr_pending - nr_queued) of all buckets reaches zero. When an I/O error occurs, nr_queued is increased and the corresponding r1bio is queued to either retry_list or bio_end_io_list. As a result, freeze_array() may unblock before these r1bios are released.

This can lead to a situation where conf->raid_disks and the mempool have already been updated while queued r1bios, allocated with the old raid_disks value, are later released. Consequently, free_r1bio() may access memory out of bounds in put_all_bios() and release r1bios of the wrong size to the new mempool, potentially causing issues with the mempool as well.

Since only normal I/O might increase nr_queued while an I/O error occurs, suspending the array avoids this issue.

Note: Updating raid_disks via ioctl SET_ARRAY_INFO already suspends the array. Therefore, we suspend the array when updating raid_disks via sysfs to avoid this issue too.(CVE-2025-71225)

In 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

In 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)

A 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)

In the Linux kernel, the following vulnerability has been resolved:

net: sock: fix hardened usercopy panic in sock_recv_errqueue

skbuff_fclone_cache was created without defining a usercopy region, [1] unlike skbuff_head_cache which properly whitelists the cb[] field. [2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY is enabled and the kernel attempts to copy sk_buff.cb data to userspace via sock_recv_errqueue() -> put_cmsg().

The crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone() (from skbuff_fclone_cache) [1] 2. The skb is cloned via skb_clone() using the pre-allocated fclone [3] 3. The cloned skb is queued to sk_error_queue for timestamp reporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE) 5. sock_recv_errqueue() calls put_cmsg() to copy serr->ee from skb->cb [4] 6. __check_heap_object() fails because skbuff_fclone_cache has no usercopy whitelist [5]

When cloned skbs allocated from skbuff_fclone_cache are used in the socket error queue, accessing the sock_exterr_skb structure in skb->cb via put_cmsg() triggers a usercopy hardening violation:

[ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)! [ 5.382796] kernel BUG at mm/usercopy.c:102! [ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI [ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7 [ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 5.384903] RIP: 0010:usercopy_abort+0x6c/0x80 [ 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 [ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246 [ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74 [ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0 [ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74 [ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001 [ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00 [ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000 [ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0 [ 5.384903] PKRU: 55555554 [ 5.384903] Call Trace: [ 5.384903] <TASK> [ 5.384903] __check_heap_object+0x9a/0xd0 [ 5.384903] __check_object_size+0x46c/0x690 [ 5.384903] put_cmsg+0x129/0x5e0 [ 5.384903] sock_recv_errqueue+0x22f/0x380 [ 5.384903] tls_sw_recvmsg+0x7ed/0x1960 [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5.384903] ? schedule+0x6d/0x270 [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5 [ 5.384903] ? mutex_unlock+0x81/0xd0 [ 5.384903] ? __pfx_mutex_unlock+0x10/0x10 [ 5.384903] ? __pfx_tls_sw_recvmsg+0x10/0x10 [ 5.384903] ? _raw_spin_lock_irqsave+0x8f/0xf0 [ 5.384903] ? _raw_read_unlock_irqrestore+0x20/0x40 [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5

The crash offset 296 corresponds to skb2->cb within skbuff_fclones: - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 - offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 = 272 + 24 (inside sock_exterr_skb.ee)

This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.

[1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885 [2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104 [3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566 [4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491 [5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719(CVE-2026-22977)

In the Linux kernel, the following vulnerability has been resolved:

net: fix memory leak in skb_segment_list for GRO packets

When skb_segment_list() is called during packet forwarding, it handles packets that were aggregated by the GRO engine.

Historically, the segmentation logic in skb_segment_list assumes that individual segments are split from a parent SKB and may need to carry their own socket memory accounting. Accordingly, the code transfers truesize from the parent to the newly created segments.

Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), this truesize subtraction in skb_segment_list() was valid because fragments still carry a reference to the original socket.

However, commit ed4cccef64c1 ("gro: fix ownership transfer") changed this behavior by ensuring that fraglist entries are explicitly orphaned (skb->sk = NULL) to prevent illegal orphaning later in the stack. This change meant that the entire socket memory charge remained with the head SKB, but the corresponding accounting logic in skb_segment_list() was never updated.

As a result, the current code unconditionally adds each fragment's truesize to delta_truesize and subtracts it from the parent SKB. Since the fragments are no longer charged to the socket, this subtraction results in an effective under-count of memory when the head is freed. This causes sk_wmem_alloc to remain non-zero, preventing socket destruction and leading to a persistent memory leak.

The leak can be observed via KMEMLEAK when tearing down the networking environment:

unreferenced object 0xffff8881e6eb9100 (size 2048): comm "ping", pid 6720, jiffies 4295492526 backtrace: kmem_cache_alloc_noprof+0x5c6/0x800 sk_prot_alloc+0x5b/0x220 sk_alloc+0x35/0xa00 inet6_create.part.0+0x303/0x10d0 __sock_create+0x248/0x640 __sys_socket+0x11b/0x1d0

Since skb_segment_list() is exclusively used for SKB_GSO_FRAGLIST packets constructed by GRO, the truesize adjustment is removed.

The call to skb_release_head_state() must be preserved. As documented in commit cf673ed0e057 ("net: fix fraglist segmentation reference count leak"), it is still required to correctly drop references to SKB extensions that may be overwritten during __copy_skb_header().(CVE-2026-22979)

In the Linux kernel, the following vulnerability has been resolved:

libceph: prevent potential out-of-bounds reads in handle_auth_done()

Perform an explicit bounds check on payload_len to avoid a possible out-of-bounds access in the callout.

idryomov: changelog

In the Linux kernel, the following vulnerability has been resolved:

libceph: make free_choose_arg_map() resilient to partial allocation

free_choose_arg_map() may dereference a NULL pointer if its caller fails after a partial allocation.

For example, in decode_choose_args(), if allocation of arg_map->args fails, execution jumps to the fail label and free_choose_arg_map() is called. Since arg_map->size is updated to a non-zero value before memory allocation, free_choose_arg_map() will iterate over arg_map->args and dereference a NULL pointer.

To prevent this potential NULL pointer dereference and make free_choose_arg_map() more resilient, add checks for pointers before iterating.(CVE-2026-22991)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: sch_qfq: do not free existing class in qfq_change_class()

Fixes qfq_change_class() error case.

cl->qdisc and cl should only be freed if a new class and qdisc were allocated, or we risk various UAF.(CVE-2026-22999)

In the Linux kernel, the following vulnerability has been resolved:

ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()

Blamed commit did not take care of VLAN encapsulations as spotted by syzbot [1].

Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().

[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729 __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860 ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1 ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438 ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489 NF_HOOK include/linux/netfilter.h:318 [inline] ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500 ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590 dst_input include/net/dst.h:474 [inline] ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:318 [inline] ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311 __netif_receive_skb_one_core net/core/dev.c:6139 [inline] __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252 netif_receive_skb_internal net/core/dev.c:6338 [inline] netif_receive_skb+0x57/0x630 net/core/dev.c:6397 tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485 tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at: slab_post_alloc_hook mm/slub.c:4960 [inline] slab_alloc_node mm/slub.c:5263 [inline] kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586 __alloc_skb+0x805/0x1040 net/core/skbuff.c:690 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712 sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995 tun_alloc_skb drivers/net/tun.c:1461 [inline] tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794 tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0xbe2/0x15d0 fs/read_write.c:686 ksys_write fs/read_write.c:738 [inline] __do_sys_write fs/read_write.c:749 [inline] __se_sys_write fs/read_write.c:746 [inline] __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746 x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025(CVE-2026-23003)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: Fix use-after-free in inet6_addr_del().

syzbot reported use-after-free of inet6_ifaddr in inet6_addr_del(). [0]

The cited commit accidentally moved ipv6_del_addr() for mngtmpaddr before reading its ifp->flags for temporary addresses in inet6_addr_del().

Let's move ipv6_del_addr() down to fix the UAF.

[0]: BUG: KASAN: slab-use-after-free in inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593

CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 addrconf_del_ifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181 inet6_ioctl+0x1e5/0x2b0 net/ipv6/af_inet6.c:582 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f164cf8f749 Code: 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 RSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749 RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003 RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288 </TASK>

Allocated by task 9593: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:397 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] ipv6_add_addr+0x4e3/0x2010 net/ipv6/addrconf.c:1120 inet6_addr_add+0x256/0x9b0 net/ipv6/addrconf.c:3050 addrconf_add_ifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160 inet6_ioctl+0x103/0x2b0 net/ipv6/af_inet6.c:580 sock_do_ioctl+0x118/0x280 net/socket.c:1254 sock_ioctl+0x227/0x6b0 net/socket.c:1375 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 6099: kasan_save_stack+0x33/0x60 mm/kasan/common.c:56 kasan_save_track+0x14/0x30 mm/kasan/common.c:77 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2540 [inline] slab_free_freelist_hook mm/slub.c:2569 [inline] slab_free_bulk mm/slub.c:6696 [inline] kmem_cache_free_bulk mm/slub.c:7383 [inline] kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362 kfree_bulk include/linux/slab.h:830 [inline] kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523 kvfree_rcu_drain_ready mm/slab_common.c:1728 [inline] kfree_rcu_monitor+0x1d0/0x2f0 mm/slab_common.c:1801 process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257 process_scheduled_works kernel/workqu ---truncated---(CVE-2026-23010)

In the Linux kernel, the following vulnerability has been resolved:

ipv4: ip_gre: make ipgre_header() robust

Analog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust")

Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1].

This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len

In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was called, syzbot managed to attach an ipgre device.

[1] skbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mld_ifc_work RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213 Call Trace: <TASK> skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693 process_one_work kernel/workqueue.c:3257 [inline] process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246(CVE-2026-23011)

In the Linux kernel, the following vulnerability has been resolved:

net: usb: pegasus: fix memory leak in update_eth_regs_async()

When asynchronously writing to the device registers and if usb_submit_urb() fail, the code fail to release allocated to this point resources.(CVE-2026-23021)

In the Linux kernel, the following vulnerability has been resolved:

mm/page_alloc: prevent pcp corruption with SMP=n

The kernel test robot has reported:

BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28 lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0 CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470 Call Trace: <IRQ> __dump_stack (lib/dump_stack.c:95) dump_stack_lvl (lib/dump_stack.c:123) dump_stack (lib/dump_stack.c:130) spin_dump (kernel/locking/spinlock_debug.c:71) do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?) _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138) __free_frozen_pages (mm/page_alloc.c:2973) freepages (mm/page_alloc.c:5295) free_pages (mm/page_alloc.c:5334) 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) ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289) ? rcu_core (kernel/rcu/tree.c:?) rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861) rcu_core_si (kernel/rcu/tree.c:2879) handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623) __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725) irq_exit_rcu (kernel/softirq.c:741) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052) </IRQ> <TASK> 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) free_pcppages_bulk (mm/page_alloc.c:1494) drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632) __drain_all_pages (mm/page_alloc.c:2731) drain_all_pages (mm/page_alloc.c:2747) kcompactd (mm/compaction.c:3115) kthread (kernel/kthread.c:465) ? __cfi_kcompactd (mm/compaction.c:3166) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork (arch/x86/kernel/process.c:164) ? __cfi_kthread (kernel/kthread.c:412) ret_from_fork_asm (arch/x86/entry/entry_64.S:255) </TASK>

Matthew has analyzed the report and identified that in drain_page_zone() we are in a section protected by spin_lock(&pcp->lock) and then get an interrupt that attempts spin_trylock() on the same lock. The code is designed to work this way without disabling IRQs and occasionally fail the trylock with a fallback. However, the SMP=n spinlock implementation assumes spin_trylock() will always succeed, and thus it's normally a no-op. Here the enabled lock debugging catches the problem, but otherwise it could cause a corruption of the pcp structure.

The problem has been introduced by commit 574907741599 ("mm/page_alloc: leave IRQs enabled for per-cpu page allocations"). The pcp locking scheme recognizes the need for disabling IRQs to prevent nesting spin_trylock() sections on SMP=n, but the need to prevent the nesting in spin_lock() has not been recognized. Fix it by introducing local wrappers that change the spin_lock() to spin_lock_iqsave() with SMP=n and use them in all places that do spin_lock(&pcp->lock).

[(CVE-2026-23025)

In the Linux kernel, the following vulnerability has been resolved:

null_blk: fix kmemleak by releasing references to fault configfs items

When CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blk driver sets up fault injection support by creating the timeout_inject, requeue_inject, and init_hctx_fault_inject configfs items as children of the top-level nullbX configfs group.

However, when the nullbX device is removed, the references taken to these fault-config configfs items are not released. As a result, kmemleak reports a memory leak, for example:

unreferenced object 0xc00000021ff25c40 (size 32): comm "mkdir", pid 10665, jiffies 4322121578 hex dump (first 32 bytes): 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_ 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject.......... backtrace (crc 1a018c86): __kmalloc_node_track_caller_noprof+0x494/0xbd8 kvasprintf+0x74/0xf4 config_item_set_name+0xf0/0x104 config_group_init_type_name+0x48/0xfc fault_config_init+0x48/0xf0 0xc0080000180559e4 configfs_mkdir+0x304/0x814 vfs_mkdir+0x49c/0x604 do_mkdirat+0x314/0x3d0 sys_mkdir+0xa0/0xd8 system_call_exception+0x1b0/0x4f0 system_call_vectored_common+0x15c/0x2ec

Fix this by explicitly releasing the references to the fault-config configfs items when dropping the reference to the top-level nullbX configfs group.(CVE-2026-23032)

In the Linux kernel, the following vulnerability has been resolved:

pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()

In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak.

Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.(CVE-2026-23038)

In the Linux kernel, the following vulnerability has been resolved:

libceph: make calc_target() set t->paused, not just clear it

Currently calc_target() clears t->paused if the request shouldn't be paused anymore, but doesn't ever set t->paused even though it's able to determine when the request should be paused. Setting t->paused is left to __submit_request() which is fine for regular requests but doesn't work for linger requests -- since __submit_request() doesn't operate on linger requests, there is nowhere for lreq->t.paused to be set. One consequence of this is that watches don't get reestablished on paused -> unpaused transitions in cases where requests have been paused long enough for the (paused) unwatch request to time out and for the subsequent (re)watch request to enter the paused state. On top of the watch not getting reestablished, rbd_reregister_watch() gets stuck with rbd_dev->watch_mutex held:

rbd_register_watch __rbd_register_watch ceph_osdc_watch linger_reg_commit_wait

It's waiting for lreq->reg_commit_wait to be completed, but for that to happen the respective request needs to end up on need_resend_linger list and be kicked when requests are unpaused. There is no chance for that if the request in question is never marked paused in the first place.

The fact that rbd_dev->watch_mutex remains taken out forever then prevents the image from getting unmapped -- "rbd unmap" would inevitably hang in D state on an attempt to grab the mutex.(CVE-2026-23047)

In the Linux kernel, the following vulnerability has been resolved:

pNFS: Fix a deadlock when returning a delegation during open()

Ben Coddington reports seeing a hang in the following stack trace: 0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415 1 [ffffd0b50e177548] schedule at ffffffff9ca05717 2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1 3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb 4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5 5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4] 6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4] 7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4] 8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4] 9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4] 10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4] 11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4] 12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4] 13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4] 14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4] 15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4] 16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4] 17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea 18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e 19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935

The issue is that the delegreturn is being asked to wait for a layout return that cannot complete because a state recovery was initiated. The state recovery cannot complete until the open() finishes processing the delegations it was given.

The solution is to propagate the existing flags that indicate a non-blocking call to the function pnfs_roc(), so that it knows not to wait in this situation.(CVE-2026-23050)

In the Linux kernel, the following vulnerability has been resolved:

net: hv_netvsc: reject RSS hash key programming without RX indirection table

RSS configuration requires a valid RX indirection table. When the device reports a single receive queue, rndis_filter_device_add() does not allocate an indirection table, accepting RSS hash key updates in this state leads to a hang.

Fix this by gating netvsc_set_rxfh() on ndc->rx_table_sz and return -EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device capabilities and prevents incorrect behavior.(CVE-2026-23054)

A 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)

A 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)

A 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)

In the Linux kernel, the following vulnerability has been resolved:

uacce: fix isolate sysfs check condition

uacce supports the device isolation feature. If the driver implements the isolate_err_threshold_read and isolate_err_threshold_write callback functions, uacce will create sysfs files now. Users can read and configure the isolation policy through sysfs. Currently, sysfs files are created as long as either isolate_err_threshold_read or isolate_err_threshold_write callback functions are present.

However, accessing a non-existent callback function may cause the system to crash. Therefore, intercept the creation of sysfs if neither read nor write exists; create sysfs if either is supported, but intercept unsupported operations at the call site.(CVE-2026-23094)

A 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)

In 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)

In the Linux kernel, the following vulnerability has been resolved:

nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovec

nvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDU length or offset exceeds sg_cnt and then use bogus sg->length/offset values, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining entries, and sg->length/offset before building the bvec.(CVE-2026-23112)

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove

On APUs such as Raven and Renoir (GC 9.1.0, 9.2.2, 9.3.0), the ih1 and ih2 interrupt ring buffers are not initialized. This is by design, as these secondary IH rings are only available on discrete GPUs. See vega10_ih_sw_init() which explicitly skips ih1/ih2 initialization when AMD_IS_APU is set.

However, amdgpu_gmc_filter_faults_remove() unconditionally uses ih1 to get the timestamp of the last interrupt entry. When retry faults are enabled on APUs (noretry=0), this function is called from the SVM page fault recovery path, resulting in a NULL pointer dereference when amdgpu_ih_decode_iv_ts_helper() attempts to access ih->ring[].

The crash manifests as:

BUG: kernel NULL pointer dereference, address: 0000000000000004 RIP: 0010:amdgpu_ih_decode_iv_ts_helper+0x22/0x40 [amdgpu] Call Trace: amdgpu_gmc_filter_faults_remove+0x60/0x130 [amdgpu] svm_range_restore_pages+0xae5/0x11c0 [amdgpu] amdgpu_vm_handle_fault+0xc8/0x340 [amdgpu] gmc_v9_0_process_interrupt+0x191/0x220 [amdgpu] amdgpu_irq_dispatch+0xed/0x2c0 [amdgpu] amdgpu_ih_process+0x84/0x100 [amdgpu]

This issue was exposed by commit 1446226d32a4 ("drm/amdgpu: Remove GC HW IP 9.3.0 from noretry=1") which changed the default for Renoir APU from noretry=1 to noretry=0, enabling retry fault handling and thus exercising the buggy code path.

Fix this by adding a check for ih1.ring_size before attempting to use it. Also restore the soft_ih support from commit dd299441654f ("drm/amdgpu: Rework retry fault removal"). This is needed if the hardware doesn't support secondary HW IH rings.

v2: additional updates (Alex)

(cherry picked from commit 6ce8d536c80aa1f059e82184f0d1994436b1d526)(CVE-2026-23163)

In the Linux kernel, the following vulnerability has been resolved:

nvmet-tcp: fixup hang in nvmet_tcp_listen_data_ready()

When the socket is closed while in TCP_LISTEN a callback is run to flush all outstanding packets, which in turns calls nvmet_tcp_listen_data_ready() with the sk_callback_lock held. So we need to check if we are in TCP_LISTEN before attempting to get the sk_callback_lock() to avoid a deadlock.(CVE-2026-23179)

In the Linux kernel, the following vulnerability has been resolved:

ASoC: amd: fix memory leak in acp3x pdm dma ops(CVE-2026-23190)

In the Linux kernel, the following vulnerability has been resolved:

scsi: target: iscsi: Fix use-after-free in iscsit_dec_session_usage_count()

In iscsit_dec_session_usage_count(), the function calls complete() while holding the sess->session_usage_lock. Similar to the connection usage count logic, the waiter signaled by complete() (e.g., in the session release path) may wake up and free the iscsit_session structure immediately.

This creates a race condition where the current thread may attempt to execute spin_unlock_bh() on a session structure that has already been deallocated, resulting in a KASAN slab-use-after-free.

To resolve this, release the session_usage_lock before calling complete() to ensure all dereferences of the sess pointer are finished before the waiter is allowed to proceed with deallocation.(CVE-2026-23193)

In the Linux kernel, the following vulnerability has been resolved:

smb/client: fix memory leak in smb2_open_file()

Reproducer:

server: directories are exported read-only
client: mount -t cifs //${server_ip}/export /mnt
client: dd if=/dev/zero of=/mnt/file bs=512 count=1000 oflag=direct
client: umount /mnt
client: sleep 1
client: modprobe -r cifs

The error message is as follows:

============================================================================= BUG cifs_small_rq (Not tainted): Objects remaining on __kmem_cache_shutdown()

Object 0x00000000d47521be @offset=14336 ... WARNING: mm/slub.c:1251 at __kmem_cache_shutdown+0x34e/0x440, CPU#0: modprobe/1577 ... Call Trace: <TASK> kmem_cache_destroy+0x94/0x190 cifs_destroy_request_bufs+0x3e/0x50 [cifs] cleanup_module+0x4e/0x540 [cifs] __se_sys_delete_module+0x278/0x400 __x64_sys_delete_module+0x5f/0x70 x64_sys_call+0x2299/0x2ff0 do_syscall_64+0x89/0x350 entry_SYSCALL_64_after_hwframe+0x76/0x7e ... kmem_cache_destroy cifs_small_rq: Slab cache still has objects when called from cifs_destroy_request_bufs+0x3e/0x50 [cifs] WARNING: mm/slab_common.c:532 at kmem_cache_destroy+0x16b/0x190, CPU#0: modprobe/1577(CVE-2026-23205)

In the Linux kernel, the following vulnerability has been resolved:

scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count()

In iscsit_dec_conn_usage_count(), the function calls complete() while holding the conn->conn_usage_lock. As soon as complete() is invoked, the waiter (such as iscsit_close_connection()) may wake up and proceed to free the iscsit_conn structure.

If the waiter frees the memory before the current thread reaches spin_unlock_bh(), it results in a KASAN slab-use-after-free as the function attempts to release a lock within the already-freed connection structure.

Fix this by releasing the spinlock before calling complete().(CVE-2026-23216)

In 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)

In 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)

Severity

7.8 (High)


                    
                      CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-57974	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-22090	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38491	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38627	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38660	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39764	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39902	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39948	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40323	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40329	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68192	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68194	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68204	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68209	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68211	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68231	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68237	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68282	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68293	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68313	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68768	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68785	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68819	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68822	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71065	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71068	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71083	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71084	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71091	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71096	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71097	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71118	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71120	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71129	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71141	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71186	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71220	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71221	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71223	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71225	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71232	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71235	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71236	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-22977	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-22979	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-22984	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-22991	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-22999	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23003	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23010	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23011	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23021	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23025	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23032	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23038	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23047	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23050	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23054	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23059	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23084	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23085	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23094	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23097	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23110	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23112	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23163	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23179	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23190	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23193	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23205	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23216	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23220	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23228	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "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"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-142.0.0.136.oe2403sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\u0026apos;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 (\u0026quot;udp:\nbind() optimisation\u0026quot;) 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 (\u0026quot;udp: add\nrehash on connect()\u0026quot;) which isn\u0026apos;t however a complete fix: the\nsocket will be found once the rehashing completes, but not while\nit\u0026apos;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\u0026apos;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 \u0026amp;\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\u0026apos;s tests\nchecking UDP functionality while using pasta(1) to connect the\ncontainer\u0026apos;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=\u0026quot;$(ip -j -4 addr show|jq -rM \u0026apos;.[] | .addr_info[0] | select(.scope == \u0026quot;global\u0026quot;).local\u0026apos;)\u0026quot;\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 \u0026amp;\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\u0026apos;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\u0026apos;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 \u0026quot;simply\u0026quot;\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\u0026apos;ll\nsimply clear the VM_PAT flag, not properly undoing the reservation ...\nwhich is also wrong.\n\nSo let\u0026apos;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\u0026apos;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   \u0026lt;TASK\u0026gt;\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 (\u0026quot;x86/mm/pat: clear VM_PAT if copy_p4d_range failed\u0026quot;)\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 \u0026lt;0f\u0026gt; 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   \u0026lt;IRQ\u0026gt;\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   \u0026lt;/IRQ\u0026gt;\n   \u0026lt;TASK\u0026gt;\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-\u0026gt;inode)-\u0026gt;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\u0026apos;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(\u0026amp;exp-\u0026gt;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\u0026apos;t get added\nas fragments in ice_add_xdp_frag. Since the buffer isn\u0026apos;t counted as a\nfragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don\u0026apos;t\ncall ice_put_rx_buf().\n\nBecause we don\u0026apos;t call ice_put_rx_buf(), we don\u0026apos;t attempt to re-use the\npage or free it. This leaves a stale page in the ring, as we don\u0026apos;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\u0026apos;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 \u0026quot;jumbo frames\u0026quot; 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]-\u0026gt;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 \u0026lt;TASK\u0026gt;\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-\u0026gt;modelist is freed, without setting the\ncorresponding fb_display[i]-\u0026gt;mode to NULL for the freed modes. This leads\nto UAF issues during subsequent accesses. Here\u0026apos;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\u0026apos;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\u0026apos;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(\u0026amp;xa-\u0026gt;xa_lock#17);\n[ 1231.611038]                                local_irq_disable();\n[ 1231.611039]                                lock(\u0026amp;fence-\u0026gt;lock);\n[ 1231.611041]                                lock(\u0026amp;xa-\u0026gt;xa_lock#17);\n[ 1231.611044]   \u0026lt;Interrupt\u0026gt;\n[ 1231.611045]     lock(\u0026amp;fence-\u0026gt;lock);\n[ 1231.611047]\n                *** DEADLOCK ***\n\nIn this example, CPU0 would be any function accessing job-\u0026gt;dependencies\nthrough the xa_* functions that don\u0026apos;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  -\u0026gt; drm_sched_entity_kill_jobs_cb()\n  -\u0026gt; foreach dependencies\n     -\u0026gt; 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-\u0026gt;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-\u0026gt;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\u0026apos;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\u0026apos;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\u0026apos;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\u0026apos;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-\u0026gt;dev_present_intf0 becomes true, usb_rx_callback_intf0() always\nresubmits urb due to commit 8791d63af0cf (\u0026quot;[media] imon: don\u0026apos;t wedge\nhardware after early callbacks\u0026quot;). Move the ictx-\u0026gt;dev_present_intf0 test\nintroduced by commit 6f6b90c9231a (\u0026quot;[media] imon: don\u0026apos;t parse scancodes\nuntil intf configured\u0026quot;) 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\u0026apos;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 \u0026lt;unistd.h\u0026gt;\n#include \u0026lt;stdio.h\u0026gt;\n#include \u0026lt;sys/mman.h\u0026gt;\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(\u0026quot;mmap() failed\\n\u0026quot;);\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  \u0026amp;\n$ echo 1 \u0026gt; /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\u0026gt;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 \u0026lt;f3\u0026gt; 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\u0026apos;s straightforward to fix this\nwith a loop that\u0026apos;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 \u0026quot;req.start\u0026quot; and \u0026quot;req.len\u0026quot; variables are u64 values that come from the\nuser at the start of the function.  We mask away the high 32 bits of\n\u0026quot;req.len\u0026quot; so that\u0026apos;s capped at U32_MAX but the \u0026quot;req.start\u0026quot; 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-\u0026gt;work\nat any time during the cleanup process in usb_del_gadget().\n\nCommit 399a45e5237c (\u0026quot;usb: gadget: core: flush gadget workqueue after\ndevice removal\u0026quot;) 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\u0026apos;s memory is freed, leading to the same use-after-free.\n\nThis patch fixes the race condition robustly by introducing a \u0026apos;teardown\u0026apos;\nflag and a \u0026apos;state_lock\u0026apos; 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 (\u0026quot;mm: thp: split huge page to any lower order pages\u0026quot;)\nintroduced an early check on the folio\u0026apos;s order via mapping-\u0026gt;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-\u0026gt;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-\u0026gt;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\u0026apos;s an issue with RDSEED\u0026apos;s 16-bit and 32-bit register output\nvariants on Zen5 which return a random value of 0 \u0026quot;at a rate inconsistent\nwith randomness while incorrectly signaling success (CF=1)\u0026quot;. 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\u0026apos;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\u0026apos;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-\u0026gt;dead\nis set, in case packet sneaks in while we\u0026apos;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\u0026apos;ed by the\nnla_for_each_nested() inside __ovs_nla_copy_actions().  The innermost\nOVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK\u0026apos;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\u0026apos;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\u0026apos;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  \u0026lt;TASK\u0026gt;\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  \u0026lt;/TASK\u0026gt;\n\nLet\u0026apos;s add some checks that the attribute is properly sized and it\u0026apos;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\u0026apos;re\npushing an NSH header already, it just creates extra nesting, but\nthat\u0026apos;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-\u0026gt;data), an out-of-bounds vuln occurs for st-\u0026gt;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-\u0026gt;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  \u0026amp;sbi-\u0026gt;cp_rwsem --\u0026gt; fs_reclaim --\u0026gt; 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(\u0026amp;sbi-\u0026gt;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 (\u0026amp;type-\u0026gt;s_umount_key#50){.+.+}-{4:4}, at: super_trylock_shared fs/super.c:562 [inline]\n #1: ffff8880118400e0 (\u0026amp;type-\u0026gt;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 \u0026lt;TASK\u0026gt;\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 \u0026lt;/TASK\u0026gt;\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-\u0026gt;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-\u0026gt;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 \u0026lt;0f\u0026gt; 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 \u0026lt;TASK\u0026gt;\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        -\u0026gt; team_port_disable()\n        -\u0026gt; team_queue_override_port_del()\n        -\u0026gt; del (removed from list)\n3) Port is disabled, queue_id != 0, not in any list\n4) Priority changes\n        -\u0026gt; team_queue_override_port_prio_changed()\n        -\u0026gt; checks: port disabled \u0026amp;\u0026amp; queue_id != 0\n        -\u0026gt; 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 (\u0026quot;ACPICA: Avoid walking the ACPI Namespace\nif it is not there\u0026quot;) 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\u0026apos;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-\u0026gt;pages[0]\nis NULL. The code unconditionally evaluates\npage_address(in_token-\u0026gt;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 \u0026gt; 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\u0026apos;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 \u0026gt; 1).\n\nThe fix involves protecting the chain_running list iteration and descriptor access with the chan-\u0026gt;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-\u0026gt;r1bio_pool) and conf-\u0026gt;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-\u0026gt;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() -\u0026gt; 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-\u0026gt;ee from skb-\u0026gt;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-\u0026gt;cb\nvia put_cmsg() triggers a usercopy hardening violation:\n\n[    5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object \u0026apos;skbuff_fclone_cache\u0026apos; (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 \u0026lt;0f\u0026gt; 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]  \u0026lt;TASK\u0026gt;\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-\u0026gt;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 (\u0026quot;gro: fix ownership transfer\u0026quot;), this\ntruesize subtraction in skb_segment_list() was valid because fragments\nstill carry a reference to the original socket.\n\nHowever, commit ed4cccef64c1 (\u0026quot;gro: fix ownership transfer\u0026quot;) changed\nthis behavior by ensuring that fraglist entries are explicitly\norphaned (skb-\u0026gt;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\u0026apos;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 \u0026quot;ping\u0026quot;, 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 (\u0026quot;net: fix fraglist segmentation reference count\nleak\u0026quot;), 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-\u0026gt;args\nfails, execution jumps to the fail label and free_choose_arg_map() is\ncalled. Since arg_map-\u0026gt;size is updated to a non-zero value before memory\nallocation, free_choose_arg_map() will iterate over arg_map-\u0026gt;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-\u0026gt;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-\u0026gt;flags for temporary\naddresses in inet6_addr_del().\n\nLet\u0026apos;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 \u0026lt;TASK\u0026gt;\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 \u0026lt;48\u0026gt; 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 \u0026lt;/TASK\u0026gt;\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 (\u0026quot;ip6_gre: make ip6gre_header() robust\u0026quot;)\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-\u0026gt;needed_headroom and/or dev-\u0026gt;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 \u0026lt;TASK\u0026gt;\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  \u0026lt;IRQ\u0026gt;\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  \u0026lt;/IRQ\u0026gt;\n  \u0026lt;TASK\u0026gt;\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  \u0026lt;/TASK\u0026gt;\n\nMatthew has analyzed the report and identified that in drain_page_zone()\nwe are in a section protected by spin_lock(\u0026amp;pcp-\u0026gt;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\u0026apos;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 (\u0026quot;mm/page_alloc:\nleave IRQs enabled for per-cpu page allocations\u0026quot;).  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(\u0026amp;pcp-\u0026gt;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 \u0026quot;mkdir\u0026quot;, 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-\u0026gt;paused, not just clear it\n\nCurrently calc_target() clears t-\u0026gt;paused if the request shouldn\u0026apos;t be\npaused anymore, but doesn\u0026apos;t ever set t-\u0026gt;paused even though it\u0026apos;s able to\ndetermine when the request should be paused.  Setting t-\u0026gt;paused is left\nto __submit_request() which is fine for regular requests but doesn\u0026apos;t\nwork for linger requests -- since __submit_request() doesn\u0026apos;t operate\non linger requests, there is nowhere for lreq-\u0026gt;t.paused to be set.\nOne consequence of this is that watches don\u0026apos;t get reestablished on\npaused -\u0026gt; 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-\u0026gt;watch_mutex held:\n\n  rbd_register_watch\n    __rbd_register_watch\n      ceph_osdc_watch\n        linger_reg_commit_wait\n\nIt\u0026apos;s waiting for lreq-\u0026gt;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-\u0026gt;watch_mutex remains taken out forever then\nprevents the image from getting unmapped -- \u0026quot;rbd unmap\u0026quot; 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-\u0026gt;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-\u0026gt;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\u0026apos;s contract, when the parameter pmac_id_valid is set to false, the driver may request a PMAC_ID from the network card\u0026apos;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 \u0026apos;itt\u0026apos; 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 \u0026apos;unsigned long\u0026apos; 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-\u0026gt;req.sg when a PDU\nlength or offset exceeds sg_cnt and then use bogus sg-\u0026gt;length/offset\nvalues, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remaining\nentries, and sg-\u0026gt;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-\u0026gt;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 (\u0026quot;drm/amdgpu: Remove GC HW\nIP 9.3.0 from noretry=1\u0026quot;) 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 (\u0026quot;drm/amdgpu:\nRework retry fault removal\u0026quot;).  This is needed if the hardware doesn\u0026apos;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-\u0026gt;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   \u0026lt;TASK\u0026gt;\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-\u0026gt;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-\u0026gt;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\u0026apos;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 \u0026quot;bad smb2 signature\u0026quot; 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)",
  "id": "OESA-2026-1566",
  "modified": "2026-08-06T11:10:34Z",
  "published": "2026-03-15T11:10:34Z",
  "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "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"
  ]
}

oesa-2026-1567