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. xioopenipdgram_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:

LOCALADDR="$(ip -j -4 addr show|jq -rM '.[] | .addrinfo[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 VMPAT handling when fork() fails in copypage_range()

If trackpfncopy() 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 untrackpfn() will see VMPAT 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 VMPAT flag of the dst VMA if trackpfncopy() fails. However, the whole thing is about "simply" clearing the VMPAT flag is shaky as well: if we passed trackpfncopy() 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 VMPAT 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 VMPAT flag after undoing the reservation.

Note that any copied page table entries will get zapped when the VMA will get removed later, after copypagerange() succeeded; as VMPAT is not set then, we won't try cleaning VMPAT 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 getpatinfo+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:getpatinfo+0xf6/0x110 ... Call Trace: <TASK> ... untrackpfn+0x52/0x110 unmapsinglevma+0xa6/0xe0 unmapvmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copyprocess+0x1bf6/0x2aa0 kernelclone+0xab/0x440 __dosysclone+0x66/0x90 dosyscall64+0x95/0x180

Likely this case was missed in:

d155df53f310 ("x86/mm/pat: clear VMPAT if copyp4d_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 trackpfnremap/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 __mptcpdofallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 checkfullyestablished net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpincomingoptions+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:__mptcpdofallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:checkfullyestablished net/mptcp/options.c:982 [inline] RIP: 0010:mptcpincomingoptions+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> tcpreset+0x26f/0x2b0 net/ipv4/tcpinput.c:4432 tcpvalidateincoming+0x1057/0x1b60 net/ipv4/tcpinput.c:5975 tcprcvestablished+0x5b5/0x21f0 net/ipv4/tcpinput.c:6166 tcpv4dorcv+0x5dc/0xa70 net/ipv4/tcpipv4.c:1925 tcpv4rcv+0x3473/0x44a0 net/ipv4/tcpipv4.c:2363 ipprotocoldeliverrcu+0xba/0x480 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2f1/0x500 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iplocaldeliver+0x1be/0x560 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:469 [inline] iprcvfinish net/ipv4/ipinput.c:447 [inline] NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iprcv+0x514/0x810 net/ipv4/ipinput.c:567 __netifreceiveskbonecore+0x197/0x1e0 net/core/dev.c:5975 __netifreceiveskb+0x1f/0x120 net/core/dev.c:6088 process_backlog+0x301/0x1360 net/core/dev.c:6440 __napipoll.constprop.0+0xba/0x550 net/core/dev.c:7453 napipoll net/core/dev.c:7517 [inline] netrxaction+0xb44/0x1010 net/core/dev.c:7644 handlesoftirqs+0x1d0/0x770 kernel/softirq.c:579 dosoftirq+0x3f/0x90 kernel/softirq.c:480 </IRQ> <TASK> __localbhenable_ip+0xed/0x110 kernel/softirq.c:407 localbhenable include/linux/bottomhalf.h:33 [inline] inetcsklistenstop+0x2c5/0x1070 net/ipv4/inetconnectionsock.c:1524 mptcpchecklistenstop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcpchecklistenstop net/mptcp/mib.h:118 [inline] __mptcpclose+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcpclose+0x2f/0x140 net/mptcp/protocol.c:3066 inetrelease+0xed/0x200 net/ipv4/afinet.c:435 inet6release+0x4f/0x70 net/ipv6/afinet6.c:487 __sockrelease+0xb3/0x270 net/socket.c:649 sockclose+0x1c/0x30 net/socket.c:1439 _fput+0x402/0xb70 fs/filetable.c:465 taskworkrun+0x150/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xd4 ---truncated---(CVE-2025-38491)

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

f2fs: compress: fix UAF of f2fsinodeinfo in f2fsfreedic

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

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->inode)->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 parselongname() is not guaranteed that. That's the reason why it uses kmemdupnul() 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 (!refcountincnot_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 allocconsistencychecks() 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 checkvalidpointer() 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 iceputrxmbuf() function handles calling iceputrxbuf() 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 iceputrxmbuf() breaks. Such descriptors get skipped and don't get added as fragments in iceaddxdpfrag. Since the buffer isn't counted as a fragment, we do not iterate over it in iceputrxmbuf(), and thus we don't call iceputrxbuf().

Because we don't call iceputrxbuf(), 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 nextto_alloc.

The icereuserxpage() assumes that the nexttoalloc 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 nextto_alloc buffer, losing track of the old page.

Note that this leak only occurs for multi-buffer frames. The iceputrx_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 iceputrxmbuf(), we need to make sure to call iceputrxbuf() on all buffers between firstdesc and nexttoclean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in iceget_pgcnts().

Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the nexttoclean element just past the current frame. Unlike i40e, the iceputrxmbuf() function does call iceputrxbuf() 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 pagecntbias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecntbias 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 xdpxmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdpxmit pointer argument from iceputrxmbuf(). Instead, set xdpxmit in the icecleanrx_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 icegetpgcnts() or iceputrx_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 fbmodeisequal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: <TASK> dumpstacklvl+0xab/0xe0 printaddressdescription.constprop.0+0x2c/0x390 printreport+0xb9/0x280 kasanreport+0xb8/0xf0 fbmodeisequal+0x285/0x2f0 fbconmodedeleted+0x129/0x180 fbsetvar+0xe7f/0x11d0 dofbioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64sysioctl+0x193/0x210 dosyscall64+0x5f/0x9c0 entrySYSCALL64afterhwframe+0x76/0x7e

Based on experimentation and analysis, during framebuffer unregistration, only the memory of fbinfo->modelist is freed, without setting the corresponding fbdisplay[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 fbdisplay[] array (via FBIOPUTCON2FBMAP); 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 dounregisterframebuffer(): 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 drmschedentitykilljobs_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->xalock#17); [ 1231.611038] localirqdisable(); [ 1231.611039] lock(&fence->lock); [ 1231.611041] lock(&xa->xalock#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: drmschedjobadddependency(), drmschedentitykilljobs_cb()).

CPU1 is executing drmschedentitykilljobscb() as a fence signalling callback so in an interrupt context. It will deadlock when trying to grab the xalock 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: dmafencesignal takes fence.lock and so does dmafenceaddcallback.

dmafencesignal() // locks f1.lock -> drmschedentitykilljobscb() -> foreach dependencies -> dmafenceaddcallback() // 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 drmschedentitykilljobs_work().

phasta: commit message nits

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

net: usb: qmiwwan: initialize MAC header offset in qmimuxrx_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 usbrxcallbackintf0() once got -EPROTO error after ictx->devpresentintf0 became true, usbrxcallbackintf0() resubmits urb after printk(), and resubmitted urb causes usbrxcallback_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 usbrxcallbackintf0() once got -EPROTO error before ictx->devpresentintf0 becomes true, usbrxcallbackintf0() always resubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedge hardware after early callbacks"). Move the ictx->devpresentintf0 test introduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodes until intf configured") to immediately before imonincomingpacket(), or the first problem explained above happens without printk() flooding (i.e. hung task).

Third problem is that when usbrxcallbackintf0() is not called for some reason (e.g. flaky hardware; the reproducer for this problem sometimes prevents usbrxcallbackintf0() from being called), waitforcompletioninterruptible() in sendpacket() 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 ofgenpdaddprovideronecell() fails during probe, the previously created generic power domains are not removed, leading to a memory leak and potential kernel crash later in genpddebugadd().

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:

| Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpddebugadd+0x2c/0x160 | lr : genpddebuginit+0x74/0x98 | Call trace: | genpddebugadd+0x2c/0x160 (P) | genpddebuginit+0x74/0x98 | dooneinitcall+0xd0/0x2d8 | doinitcalllevel+0xa0/0x140 | doinitcalls+0x60/0xa8 | dobasicsetup+0x28/0x40 | kernelinitfreeable+0xe8/0x170 | kernelinit+0x2c/0x140 | retfromfork+0x10/0x20(CVE-2025-68204)

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 mlx5addcqtotasklet 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 mlx5cqarm. 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 mlx5corecreate_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 scangetnextrmapitem

Currently, scangetnextrmapitem() 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 walkpagerange(). 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, PROTREAD | PROTWRITE, MAPNORESERVE | MAPPRIVATE | MAP_ANON, -1, 0);

    if (area == MAP_FAILED) {
            perror("mmap() failed\n");
            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: errorcode(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/string32.h:168 arch/x86/lib/memcpy32.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: poisonelement (mm/mempool.c:83 mm/mempool.c:102) mempoolinitnode (mm/mempool.c:142 mm/mempool.c:226) mempoolinitnoprof (mm/mempool.c:250 (discriminator 1)) ? mempoolallocpages (mm/mempool.c:640) biointegrityinitfn (block/bio-integrity.c:483 (discriminator 8)) ? mempoolallocpages (mm/mempool.c:640) dooneinitcall (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 U32MAX but the "req.start" variable can go up to U64MAX which means that the addition can still integer overflow.

Use checkaddoverflow() 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 usbgadgetstate_work

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

BUG: KASAN: invalid-access in sysfsnotify+0x2c/0xd0 Workqueue: events usbgadgetstatework

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

Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after device removal") attempted to fix this by moving flushwork() to after devicedel(). 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 'statelock' spinlock to the usbgadget struct. The flag is set during cleanup in usbdelgadget() before calling flushwork() to prevent any new work from being scheduled once cleanup has commenced. The scheduling site, usbgadgetsetstate(), 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 fqdirpreexit()

We have been seeing occasional deadlocks on pernetopsrwsem 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 nfconntrackcleanupnetlist(). 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 nfdefragipv6, nfdefragipv6 will load first. Since nfdefragipv6 loads first its netns exit hooks run after conntrack's netns exit hook.

Flush all fragment queue SKBs during fqdirpreexit() 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:

OVSACTIONATTRPUSHNSH(OVSKEYATTRNSH(OVSNSHKEYATTR_BASE,...))

The outermost OVSACTIONATTRPUSHNSH attribute is OK'ed by the nlaforeach_nested() inside _ovsnlacopyactions(). The innermost OVSNSHKEYATTRBASE/MD1/MD2 are OK'ed by the nlaforeachnested() inside nshkeyputfromnlattr(). But nothing checks if the attribute in the middle is OK. We don't even check that this attribute is the OVSKEYATTRNSH. We just do a double unwrap with a pair of nladata() calls - first time directly while calling validatepushnsh() and the second time as part of the nlaforeachnested() 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 nshhdrfrom_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> dumpstacklvl+0x51/0x70 printaddressdescription.constprop.0+0x2c/0x390 kasanreport+0xdd/0x110 kasancheck_range+0x35/0x1b0 __asanmemcpy+0x20/0x60 nshhdrfromnlattr+0x1dd/0x6a0 [openvswitch] pushnsh+0x82/0x120 [openvswitch] doexecuteactions+0x1405/0x2840 [openvswitch] ovsexecuteactions+0xd5/0x3b0 [openvswitch] ovspacketcmdexecute+0x949/0xdb0 [openvswitch] genlfamilyrcvmsgdoit+0x1d6/0x2b0 genlfamilyrcvmsg+0x336/0x580 genlrcvmsg+0x9f/0x130 netlinkrcvskb+0x11f/0x370 genlrcv+0x24/0x40 netlinkunicast+0x73e/0xaa0 netlinksendmsg+0x744/0xbf0 _syssendto+0x3d6/0x450 dosyscall64+0x79/0x2c0 entrySYSCALL64afterhwframe+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 OVSKEYATTR_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 dtv5100i2cmsg()

rlen value is a user-controlled value, but dtv5100i2cmsg() 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 dev3registerwork

The dev3registerwork delayed work item is initialized within alpsreconnect() 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 flushworkqueue() in psmousedisconnect() to ensure completion of dev3registerwork. However, the flushworkqueue() in psmousedisconnect() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flushworkqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after flushworkqueue() has finished executing, the dev3registerwork could still be scheduled. Although the psmouse state is set to PSMOUSECMDMODE in psmousedisconnect(), the scheduling of dev3registerwork remains unaffected.

The race condition can occur as follows:

CPU 0 (cleanup path) | CPU 1 (delayed work) psmousedisconnect() | psmousesetstate() | flushworkqueue() | alpsreportbareps2packet() alpsdisconnect() | psmousequeuework() kfree(priv); // FREE | alpsregisterbareps2mouse() | priv = containerof(work...); // USE | priv->dev3 // USE

Add disabledelayedworksync() in alpsdisconnect() to ensure that dev3registerwork 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->cprwsem --> fsreclaim --> sb_internal#2

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

rlock(sbinternal#2); lock(fsreclaim); lock(sbinternal#2); rlock(&sbi->cprwsem);

*** DEADLOCK ***

3 locks held by kswapd0/73: #0: ffffffff8e247a40 (fsreclaim){+.+.}-{0:0}, at: balancepgdat mm/vmscan.c:7015 [inline] #0: ffffffff8e247a40 (fsreclaim){+.+.}-{0:0}, at: kswapd+0x951/0x2800 mm/vmscan.c:7389 #1: ffff8880118400e0 (&type->sumountkey#50){.+.+}-{4:4}, at: supertrylockshared fs/super.c:562 [inline] #1: ffff8880118400e0 (&type->sumountkey#50){.+.+}-{4:4}, at: supercachescan+0x91/0x4b0 fs/super.c:197 #2: ffff888011840610 (sbinternal#2){.+.+}-{0:0}, at: f2fsevictinode+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> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printcircularbug+0x2ee/0x310 kernel/locking/lockdep.c:2043 checknoncircular+0x134/0x160 kernel/locking/lockdep.c:2175 checkprevadd kernel/locking/lockdep.c:3165 [inline] checkprevsadd kernel/locking/lockdep.c:3284 [inline] validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3908 __lockacquire+0xab9/0xd20 kernel/locking/lockdep.c:5237 lockacquire+0x120/0x360 kernel/locking/lockdep.c:5868 downread+0x46/0x2e0 kernel/locking/rwsem.c:1537 f2fsdownread fs/f2fs/f2fs.h:2278 [inline] f2fslockop fs/f2fs/f2fs.h:2357 [inline] f2fsdotruncateblocks+0x21c/0x10c0 fs/f2fs/file.c:791 f2fstruncateblocks+0x10a/0x300 fs/f2fs/file.c:867 f2fstruncate+0x489/0x7c0 fs/f2fs/file.c:925 f2fsevictinode+0x9f2/0x1b60 fs/f2fs/inode.c:897 evict+0x504/0x9c0 fs/inode.c:810 f2fsevictinode+0x1dc/0x1b60 fs/f2fs/inode.c:853 evict+0x504/0x9c0 fs/inode.c:810 disposelist fs/inode.c:852 [inline] pruneicachesb+0x21b/0x2c0 fs/inode.c:1000 supercachescan+0x39b/0x4b0 fs/super.c:224 doshrinkslab+0x6ef/0x1110 mm/shrinker.c:437 shrinkslabmemcg mm/shrinker.c:550 [inline] shrinkslab+0x7ef/0x10d0 mm/shrinker.c:628 shrinkone+0x28a/0x7c0 mm/vmscan.c:4955 shrinkmany mm/vmscan.c:5016 [inline] lrugenshrinknode mm/vmscan.c:5094 [inline] shrinknode+0x315d/0x3780 mm/vmscan.c:6081 kswapdshrinknode mm/vmscan.c:6941 [inline] balancepgdat mm/vmscan.c:7124 [inline] kswapd+0x147c/0x2800 mm/vmscan.c:7389 kthread+0x70e/0x8a0 kernel/kthread.c:463 retfromfork+0x4bc/0x870 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

The root cause is deadlock among four locks as below:

kswapd - fsreclaim --- Lock A - shrinkone - evict - f2fsevictinode - sbstartintwrite --- Lock B

• iput
  • evict
    • f2fsevictinode
      • sbstartintwrite --- Lock B
      • f2fstruncate
        • f2fstruncateblocks
          • f2fsdotruncateblocks
            • f2fslockop --- Lock C

ioctl - f2fsioccommitatomicwrite - f2fslockop --- Lock C - __f2fscommitatomic_write - __replaceatomicwrite_block - f2fsgetdnodeofdata - _getnodefolio - f2fschecknidrange - f2fshandleerror - f2fsrecorderrors - f2fsdownwrite --- Lock D

open - doopen - dotruncate - securityinodeneedkillpriv - f2fsgetxattr - lookupallxattrs - f2fshandleerror - f2fsrecorderrors - f2fsdownwrite --- Lock D - f2fscommitsuper - readmappingfolio - filemapallocfolionoprof - prepareallocpages - fsreclaim_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

svcrdmacopyinlinerange indexed rqstp->rqpages[rccurpage] 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 cancelworksync() 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 releasegidtable drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gidtablerelease_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 teamqueueoverrideportprio_changed()

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

listdel corruption, ffff888058bea080->prev is LISTPOISON2 (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:__listdelentryvalidorreport+0x13e/0x200 lib/listdebug.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> __listdelentry_valid include/linux/list.h:132 [inline] __listdelentry include/linux/list.h:223 [inline] listdelrcu include/linux/rculist.h:178 [inline] __teamqueueoverrideportdel drivers/net/team/team_core.c:826 [inline] __teamqueueoverrideportdel drivers/net/team/teamcore.c:821 [inline] teamqueueoverrideportpriochanged drivers/net/team/teamcore.c:883 [inline] teampriorityoptionset+0x171/0x2f0 drivers/net/team/teamcore.c:1534 teamoptionset drivers/net/team/teamcore.c:376 [inline] teamnloptionssetdoit+0x8ae/0xe60 drivers/net/team/teamcore.c:2653 genlfamilyrcvmsgdoit+0x209/0x2f0 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x55c/0x800 net/netlink/genetlink.c:1210 netlinkrcvskb+0x158/0x420 net/netlink/afnetlink.c:2552 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1320 [inline] netlinkunicast+0x5aa/0x870 net/netlink/afnetlink.c:1346 netlinksendmsg+0x8c8/0xdd0 net/netlink/afnetlink.c:1896 socksendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684 _syssendmsg+0x16d/0x220 net/socket.c:2716 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xfa0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

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

To fix this, change the check in teamqueueoverrideportprio_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 LSNLATYPE_DGID correctly

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

Use the nl parsing logic properly and call nlaparsedeprecated() 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 RDMANLLSOPIP_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 fibtableflush() is called to flush all the routes that are using the dead nexthop.

The current logic in fibtableflush() 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 startnode and acpigblrootnode 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 parentnode in acpinsgetnextnode(). The NULL pointer dereference will always happen, no matter whether or not the startnode is equal to ACPIROOTOBJECT, 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: svcauthgss: avoid NULL deref on zero length gsstoken in gssreadproxy_verf

A zero length gsstoken results in pages == 0 and intoken->pages[0] is NULL. The code unconditionally evaluates pageaddress(intoken->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 emitabiext() helper. The emitabiext() 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 drmkmshelperpollfini() and drmatomichelpershutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdcfini(), which causes warnings during probe deferral scenarios.

[ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drmatomicstatehelper.c:175 drmatomichelpercrtcduplicatestate+0x60/0x68 ... [ 8.005820] drmatomichelpercrtcduplicatestate from drmatomicgetcrtcstate+0x68/0x108 [ 8.005858] drmatomicgetcrtcstate from drmatomichelperdisableall+0x90/0x1c8 [ 8.005885] drmatomichelperdisableall from drmatomichelpershutdown+0x90/0x144 [ 8.005911] drmatomichelpershutdown from tilcdcfini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdcfini [tilcdc] from tilcdcpdev_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 ksmbdsessionrpcclose() on error path in createsmb2_pipe()

When ksmbdiovpinrsp() fails, we should call ksmbdsessionrpcclose().(CVE-2025-71220)

In the Linux kernel, a race condition vulnerability exists in the mmppdma driver. The vulnerability occurs in the mmppdma_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 txstatus() 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 (threadsper_chan > 1).

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

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

smb/server: fix refcount leak in smb2_open()

When ksmbdvfsgetattr() 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 raid1reshape(), freezearray() is called before modifying the r1bio memory pool (conf->r1biopool) and conf->raiddisks, and unfreeze_array() is called after the update is completed.

However, freezearray() only waits until nrsyncpending and (nrpending - nrqueued) of all buckets reaches zero. When an I/O error occurs, nrqueued is increased and the corresponding r1bio is queued to either retrylist or bioendiolist. As a result, freeze_array() may unblock before these r1bios are released.

This can lead to a situation where conf->raiddisks and the mempool have already been updated while queued r1bios, allocated with the old raiddisks value, are later released. Consequently, freer1bio() may access memory out of bounds in putall_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 raiddisks via ioctl SETARRAYINFO already suspends the array. Therefore, we suspend the array when updating raiddisks 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 qlafabasync_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 sockrecverrqueue

skbufffclonecache was created without defining a usercopy region, [1] unlike skbuffheadcache which properly whitelists the cb[] field. [2] This causes a usercopy BUG() when CONFIGHARDENEDUSERCOPY is enabled and the kernel attempts to copy skbuff.cb data to userspace via sockrecverrqueue() -> putcmsg().

The crash occurs when: 1. TCP allocates an skb using allocskbfclone() (from skbufffclonecache) [1] 2. The skb is cloned via skbclone() using the pre-allocated fclone [3] 3. The cloned skb is queued to skerrorqueue for timestamp reporting 4. Userspace reads the error queue via recvmsg(MSGERRQUEUE) 5. sockrecverrqueue() calls put_cmsg() to copy serr->ee from skb->cb [4] 6. __checkheapobject() fails because skbufffclonecache has no usercopy whitelist [5]

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

[ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbufffclonecache' (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: pocputcmsg 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] __checkheapobject+0x9a/0xd0 [ 5.384903] __checkobjectsize+0x46c/0x690 [ 5.384903] putcmsg+0x129/0x5e0 [ 5.384903] sockrecverrqueue+0x22f/0x380 [ 5.384903] tlsswrecvmsg+0x7ed/0x1960 [ 5.384903] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5.384903] ? schedule+0x6d/0x270 [ 5.384903] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5.384903] ? mutexunlock+0x81/0xd0 [ 5.384903] ? __pfxmutexunlock+0x10/0x10 [ 5.384903] ? __pfxtlsswrecvmsg+0x10/0x10 [ 5.384903] ? rawspinlockirqsave+0x8f/0xf0 [ 5.384903] ? rawreadunlockirqrestore+0x20/0x40 [ 5.384903] ? srsoaliasreturnthunk+0x5/0xfbef5

The crash offset 296 corresponds to skb2->cb within skbufffclones: - sizeof(struct skbuff) = 232 - offsetof(struct skbuff, cb) = 40 - offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 = 272 + 24 (inside sockexterr_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 skbsegmentlist for GRO packets

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

Historically, the segmentation logic in skbsegmentlist 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 skbsegmentlist() 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 skbsegmentlist() was never updated.

As a result, the current code unconditionally adds each fragment's truesize to deltatruesize 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 skwmem_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: kmemcacheallocnoprof+0x5c6/0x800 skprotalloc+0x5b/0x220 skalloc+0x35/0xa00 inet6_create.part.0+0x303/0x10d0 __sock_create+0x248/0x640 _syssocket+0x11b/0x1d0

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

The call to skbreleasehead_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 __copyskbheader().(CVE-2026-22979)

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

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

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 freechoosearg_map() resilient to partial allocation

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

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

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

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

net/sched: schqfq: do not free existing class in qfqchange_class()

Fixes qfqchangeclass() 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:

ip6tunnel: use skbvlaninetprepare() in __ip6tnlrcv()

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

Use skbvlaninetprepare() instead of pskbinetmaypull().

[1] BUG: KMSAN: uninit-value in __INETECNdecapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INETECNdecapsulate include/net/inetecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6ECNdecapsulate+0x7a8/0x1fa0 include/net/inetecn.h:321 __INETECNdecapsulate include/net/inet_ecn.h:253 [inline] INETECNdecapsulate include/net/inetecn.h:275 [inline] IP6ECNdecapsulate+0x7a8/0x1fa0 include/net/inetecn.h:321 ip6ip6dscpecndecapsulate+0x16f/0x1b0 net/ipv6/ip6tunnel.c:729 __ip6tnlrcv+0xed9/0x1b50 net/ipv6/ip6tunnel.c:860 ip6tnlrcv+0xc3/0x100 net/ipv6/ip6tunnel.c:903 grercv+0x1529/0x1b90 net/ipv6/ip6gre.c:-1 ip6protocoldeliverrcu+0x1c89/0x2c60 net/ipv6/ip6input.c:438 ip6inputfinish+0x1f4/0x4a0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] ip6input+0x9c/0x330 net/ipv6/ip6input.c:500 ip6mcinput+0x7ca/0xc10 net/ipv6/ip6input.c:590 dstinput include/net/dst.h:474 [inline] ip6rcvfinish+0x958/0x990 net/ipv6/ip6input.c:79 NFHOOK include/linux/netfilter.h:318 [inline] ipv6rcv+0xf1/0x3c0 net/ipv6/ip6input.c:311 __netifreceiveskbonecore net/core/dev.c:6139 [inline] __netifreceiveskb+0x1df/0xac0 net/core/dev.c:6252 netif_receiveskbinternal net/core/dev.c:6338 [inline] netifreceiveskb+0x57/0x630 net/core/dev.c:6397 tunrxbatched+0x1df/0x980 drivers/net/tun.c:1485 tungetuser+0x5c0e/0x6c60 drivers/net/tun.c:1953 tunchrwriteiter+0x3e9/0x5c0 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0xbe2/0x15d0 fs/readwrite.c:686 ksyswrite fs/readwrite.c:738 [inline] __dosyswrite fs/read_write.c:749 [inline] __sesyswrite fs/read_write.c:746 [inline] __x64syswrite+0x1fb/0x4d0 fs/readwrite.c:746 x64syscall+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls64.h:2 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd3/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:4960 [inline] slaballocnode mm/slub.c:5263 [inline] kmemcacheallocnodenoprof+0x9e7/0x17a0 mm/slub.c:5315 kmallocreserve+0x13c/0x4b0 net/core/skbuff.c:586 __allocskb+0x805/0x1040 net/core/skbuff.c:690 allocskb include/linux/skbuff.h:1383 [inline] allocskbwithfrags+0xc5/0xa60 net/core/skbuff.c:6712 sockallocsendpskb+0xacc/0xc60 net/core/sock.c:2995 tunallocskb drivers/net/tun.c:1461 [inline] tungetuser+0x1142/0x6c60 drivers/net/tun.c:1794 tunchrwriteiter+0x3e9/0x5c0 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0xbe2/0x15d0 fs/readwrite.c:686 ksyswrite fs/readwrite.c:738 [inline] __dosyswrite fs/read_write.c:749 [inline] __sesyswrite fs/read_write.c:746 [inline] __x64syswrite+0x1fb/0x4d0 fs/readwrite.c:746 x64syscall+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls64.h:2 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd3/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+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 inet6addrdel().

syzbot reported use-after-free of inet6ifaddr in inet6addr_del(). [0]

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

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

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> __dumpstack lib/dumpstack.c:94 [inline] dump_stacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 inet6addrdel.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 addrconfdelifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181 inet6ioctl+0x1e5/0x2b0 net/ipv6/afinet6.c:582 sockdoioctl+0x118/0x280 net/socket.c:1254 sockioctl+0x227/0x6b0 net/socket.c:1375 vfsioctl fs/ioctl.c:51 [inline] __dosysioctl fs/ioctl.c:597 [inline] __sesysioctl fs/ioctl.c:583 [inline] _x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+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 ORIGRAX: 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: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 poisonkmallocredzone mm/kasan/common.c:397 [inline] __kasankmalloc+0xaa/0xb0 mm/kasan/common.c:414 kmallocnoprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] ipv6addaddr+0x4e3/0x2010 net/ipv6/addrconf.c:1120 inet6addradd+0x256/0x9b0 net/ipv6/addrconf.c:3050 addrconfaddifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160 inet6ioctl+0x103/0x2b0 net/ipv6/afinet6.c:580 sockdoioctl+0x118/0x280 net/socket.c:1254 sockioctl+0x227/0x6b0 net/socket.c:1375 vfsioctl fs/ioctl.c:51 [inline] __dosysioctl fs/ioctl.c:597 [inline] __sesysioctl fs/ioctl.c:583 [inline] __x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 6099: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:584 poisonslab_object mm/kasan/common.c:252 [inline] __kasanslabfree+0x5f/0x80 mm/kasan/common.c:284 kasanslabfree include/linux/kasan.h:234 [inline] slabfreehook mm/slub.c:2540 [inline] slabfreefreelisthook mm/slub.c:2569 [inline] slabfreebulk mm/slub.c:6696 [inline] kmemcachefreebulk mm/slub.c:7383 [inline] kmemcachefreebulk+0x2bf/0x680 mm/slub.c:7362 kfreebulk include/linux/slab.h:830 [inline] kvfreercubulk+0x1b7/0x1e0 mm/slabcommon.c:1523 kvfreercudrainready mm/slabcommon.c:1728 [inline] kfreercumonitor+0x1d0/0x2f0 mm/slabcommon.c:1801 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqu ---truncated---(CVE-2026-23010)

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

ipv4: ipgre: make ipgreheader() robust

Analog to commit db5b4e39c4e6 ("ip6gre: make ip6greheader() 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->neededheadroom and/or dev->hardheader_len

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

[1] skbuff: skbunderpanic: 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 mldifcwork RIP: 0010:skbpanic+0x157/0x160 net/core/skbuff.c:213 Call Trace: <TASK> skbunderpanic net/core/skbuff.c:223 [inline] skbpush+0xc3/0xe0 net/core/skbuff.c:2641 ipgreheader+0x67/0x290 net/ipv4/ipgre.c:897 devhardheader include/linux/netdevice.h:3436 [inline] neighconnectedoutput+0x286/0x460 net/core/neighbour.c:1618 NFHOOKCOND include/linux/netfilter.h:307 [inline] ip6output+0x340/0x550 net/ipv6/ip6output.c:247 NFHOOK+0x9e/0x380 include/linux/netfilter.h:318 mldsendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mldsendcr net/ipv6/mcast.c:2154 [inline] mldifcwork+0x83e/0xd60 net/ipv6/mcast.c:2693 processonework kernel/workqueue.c:3257 [inline] processscheduledworks+0xad1/0x1770 kernel/workqueue.c:3340 workerthread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 retfromfork+0x510/0xa50 arch/x86/kernel/process.c:158 retfromforkasm+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 updateethregs_async()

When asynchronously writing to the device registers and if usbsubmiturb() 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> __dumpstack (lib/dumpstack.c:95) dumpstacklvl (lib/dumpstack.c:123) dumpstack (lib/dumpstack.c:130) spindump (kernel/locking/spinlockdebug.c:71) dorawspintrylock (kernel/locking/spinlockdebug.c:?) rawspintrylock (include/linux/spinlockapismp.h:89 kernel/locking/spinlock.c:138) __freefrozenpages (mm/page_alloc.c:2973) ___freepages (mm/pagealloc.c:5295) __freepages (mm/pagealloc.c:5334) tlbremovetablercu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmugather.c:227 mm/mmu_gather.c:290) ? __cfitlbremovetablercu (mm/mmugather.c:289) ? rcucore (kernel/rcu/tree.c:?) rcucore (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861) rcucoresi (kernel/rcu/tree.c:2879) handlesoftirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623) __irqexitrcu (arch/x86/include/asm/jumplabel.h:36 kernel/softirq.c:725) irqexitrcu (kernel/softirq.c:741) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1052) </IRQ> <TASK> RIP: 0010:rawspinunlockirqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlockapismp.h:152 kernel/locking/spinlock.c:194) freepcppagesbulk (mm/pagealloc.c:1494) drainpageszone (include/linux/spinlock.h:391 mm/pagealloc.c:2632) __drainallpages (mm/pagealloc.c:2731) drainallpages (mm/pagealloc.c:2747) kcompactd (mm/compaction.c:3115) kthread (kernel/kthread.c:465) ? __cfi_kcompactd (mm/compaction.c:3166) ? __cfikthread (kernel/kthread.c:412) retfrom_fork (arch/x86/kernel/process.c:164) ? _cfikthread (kernel/kthread.c:412) retfromforkasm (arch/x86/entry/entry64.S:255) </TASK>

Matthew has analyzed the report and identified that in drainpagezone() we are in a section protected by spinlock(&pcp->lock) and then get an interrupt that attempts spintrylock() 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/pagealloc: leave IRQs enabled for per-cpu page allocations"). The pcp locking scheme recognizes the need for disabling IRQs to prevent nesting spintrylock() sections on SMP=n, but the need to prevent the nesting in spinlock() has not been recognized. Fix it by introducing local wrappers that change the spinlock() to spinlockiqsave() 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 CONFIGBLKDEVNULLBLKFAULTINJECTION is enabled, the null-blk driver sets up fault injection support by creating the timeoutinject, requeueinject, and inithctxfault_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 inithctxfault_ 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject.......... backtrace (crc 1a018c86): __kmallocnodetrackcallernoprof+0x494/0xbd8 kvasprintf+0x74/0xf4 configitemsetname+0xf0/0x104 configgroupinittypename+0x48/0xfc faultconfiginit+0x48/0xf0 0xc0080000180559e4 configfsmkdir+0x304/0x814 vfsmkdir+0x49c/0x604 domkdirat+0x314/0x3d0 sysmkdir+0xa0/0xd8 systemcallexception+0x1b0/0x4f0 systemcallvectoredcommon+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 nfs4ffallocdeviceidnode()

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

Fix this by jumping to the outerrdrain_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 _submitrequest() 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, rbdreregisterwatch() gets stuck with rbddev->watchmutex held:

rbdregisterwatch _rbdregisterwatch cephosdcwatch lingerregcommitwait

It's waiting for lreq->regcommitwait to be completed, but for that to happen the respective request needs to end up on needresendlinger 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 rbddev->watchmutex 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] __waitonbit at ffffffff9ca05cfb 4 [ffffd0b50e1775c8] outoflinewaitonbit at ffffffff9ca05ea5 5 [ffffd0b50e177618] pnfsroc at ffffffffc154207b [nfsv4] 6 [ffffd0b50e1776b8] nfs4procdelegreturn at ffffffffc1506586 [nfsv4] 7 [ffffd0b50e177788] nfs4procdelegreturn at ffffffffc1507480 [nfsv4] 8 [ffffd0b50e1777f8] nfsdoreturndelegation at ffffffffc1523e41 [nfsv4] 9 [ffffd0b50e177838] nfsinodesetdelegation at ffffffffc1524a75 [nfsv4] 10 [ffffd0b50e177888] nfs4processdelegation at ffffffffc14f41dd [nfsv4] 11 [ffffd0b50e1778a0] nfs4opendatatonfs4state at ffffffffc1503edf [nfsv4] 12 [ffffd0b50e1778c0] nfs4openandgetstate at ffffffffc1504e56 [nfsv4] 13 [ffffd0b50e177978] nfs4doopen at ffffffffc15051b8 [nfsv4] 14 [ffffd0b50e1779f8] nfs4doopen at ffffffffc150559c [nfsv4] 15 [ffffd0b50e177a80] nfs4atomicopen at ffffffffc15057fb [nfsv4] 16 [ffffd0b50e177ad0] nfs4fileopen at ffffffffc15219be [nfsv4] 17 [ffffd0b50e177b78] dodentryopen at ffffffff9c09e6ea 18 [ffffd0b50e177ba8] vfsopen at ffffffff9c0a082e 19 [ffffd0b50e177bd0] dentryopen 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, rndisfilterdevice_add() does not allocate an indirection table, accepting RSS hash key updates in this state leads to a hang.

Fix this by gating netvscsetrxfh() on ndc->rxtablesz 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 becmdgetmacfromlist() function. According to the function's contract, when the parameter pmacidvalid is set to false, the driver may request a PMACID from the network card's firmware and store it at the provided address pmacid. However, there is a location within the driver where both conditions pmacidvalid == false and pmacid == 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 CONFIGARMLPAE 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 GFPKERNEL. Since all memory below the 4GB physical address limit is in ZONEDMA 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 isolateerrthresholdread and isolateerrthresholdwrite 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 isolateerrthresholdread or isolateerrthresholdwrite 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 nvmettcpbuildpduiovec

nvmettcpbuildpduiovec() could walk past cmd->req.sg when a PDU length or offset exceeds sgcnt and then use bogus sg->length/offset values, leading to copytoiter() 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 amdgpugmcfilterfaultsremove

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 vega10ihswinit() which explicitly skips ih1/ih2 initialization when AMDIS_APU is set.

However, amdgpugmcfilterfaultsremove() 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 amdgpuihdecodeivts_helper() attempts to access ih->ring[].

The crash manifests as:

BUG: kernel NULL pointer dereference, address: 0000000000000004 RIP: 0010:amdgpuihdecodeivtshelper+0x22/0x40 [amdgpu] Call Trace: amdgpugmcfilterfaultsremove+0x60/0x130 [amdgpu] svmrangerestorepages+0xae5/0x11c0 [amdgpu] amdgpuvmhandlefault+0xc8/0x340 [amdgpu] gmcv90processinterrupt+0x191/0x220 [amdgpu] amdgpuirqdispatch+0xed/0x2c0 [amdgpu] amdgpuih_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.ringsize before attempting to use it. Also restore the softih 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 nvmettcplistendataready()

When the socket is closed while in TCPLISTEN a callback is run to flush all outstanding packets, which in turns calls nvmettcplistendataready() with the skcallbacklock held. So we need to check if we are in TCPLISTEN before attempting to get the skcallbacklock() 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 iscsitdecsessionusagecount()

In iscsitdecsessionusagecount(), the function calls complete() while holding the sess->sessionusagelock. 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 spinunlockbh() on a session structure that has already been deallocated, resulting in a KASAN slab-use-after-free.

To resolve this, release the sessionusagelock 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 smb2openfile()

Reproducer:

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

The error message is as follows:

============================================================================= BUG cifssmallrq (Not tainted): Objects remaining on __kmemcacheshutdown()

Object 0x00000000d47521be @offset=14336 ... WARNING: mm/slub.c:1251 at __kmemcacheshutdown+0x34e/0x440, CPU#0: modprobe/1577 ... Call Trace: <TASK> kmemcachedestroy+0x94/0x190 cifsdestroyrequestbufs+0x3e/0x50 [cifs] cleanupmodule+0x4e/0x540 [cifs] __sesysdelete_module+0x278/0x400 _x64sysdeletemodule+0x5f/0x70 x64syscall+0x2299/0x2ff0 dosyscall64+0x89/0x350 entrySYSCALL64afterhwframe+0x76/0x7e ... kmemcachedestroy cifssmallrq: Slab cache still has objects when called from cifsdestroyrequestbufs+0x3e/0x50 [cifs] WARNING: mm/slabcommon.c:532 at kmemcachedestroy+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 iscsitdecconnusagecount()

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

If the waiter frees the memory before the current thread reaches spinunlockbh(), 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 __processrequest(), if checksignreq() returns an error, setsmb2rspstatus(work, STATUSACCESSDENIED) is called. setsmb2rspstatus() sets work->nextsmb2rcvhdroff to zero. By resetting nextsmb2rcvhdroff to zero, the pointer to the next command in the chain is lost. Consequently, ischainedsmb2message() 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 __handleksmbdwork() 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 activenumconn in ksmbdtcpnewconnection() On kthreadrun() failure in ksmbdtcpnewconnection(), the transport is freed via freetransport(), which does not decrement activenumconn, leaking this counter. Replace freetransport() with ksmbdtcp_disconnect(). The Linux kernel CVE team has assigned CVE-2026-23228 to this issue.(CVE-2026-23228)