--- /dev/null
+From 62d9853aa4ce6e9797b6949804891be14b219752 Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Mon, 13 Jul 2026 16:22:55 +0100
+Subject: afs: Fix afs_edit_dir_remove() to get, not find, block 0
+
+From: David Howells <dhowells@redhat.com>
+
+commit 62d9853aa4ce6e9797b6949804891be14b219752 upstream.
+
+Fix afs_edit_dir_remove() to use afs_dir_get_block() to get block 0 rather
+than afs_dir_find_block() as the latter caches the found block in the
+afs_dir_iter and may[*] switch out the page it's on if another
+afs_dir_find_block() is done. This parallels what afs_edit_dir_add() does.
+
+[*] There's more than one block per page.
+
+Fixes: a5b5beebcf96 ("afs: Use the contained hashtable to search a directory")
+Closes: https://sashiko.dev/#/patchset/20260706153408.1231650-1-dhowells%40redhat.com
+Signed-off-by: David Howells <dhowells@redhat.com>
+Link: https://patch.msgid.link/2380759.1783956175@warthog.procyon.org.uk
+cc: Marc Dionne <marc.dionne@auristor.com>
+cc: linux-afs@lists.infradead.org
+cc: linux-fsdevel@vger.kernel.org
+cc: stable@vger.kernel.org
+Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/afs/dir_edit.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/afs/dir_edit.c
++++ b/fs/afs/dir_edit.c
+@@ -415,7 +415,7 @@ void afs_edit_dir_remove(struct afs_vnod
+ if (!afs_dir_init_iter(&iter, name))
+ return;
+
+- meta = afs_dir_find_block(&iter, 0);
++ meta = afs_dir_get_block(&iter, 0);
+ if (!meta)
+ return;
+
--- /dev/null
+From f73a8edc2ccc6ec72c37d5c578e7592d2e1f9922 Mon Sep 17 00:00:00 2001
+From: Dev Jain <dev.jain@arm.com>
+Date: Fri, 3 Jul 2026 11:41:54 +0000
+Subject: arm64: make huge_ptep_get handled unaligned addresses
+
+From: Dev Jain <dev.jain@arm.com>
+
+commit f73a8edc2ccc6ec72c37d5c578e7592d2e1f9922 upstream.
+
+huge_ptep_get() can be handed a virtual address pointing to the middle
+of a contpmd/contpte mapped hugetlb folio (examples of callers are
+pagemap_hugetlb_range, page_mapped_in_vma).
+
+The arm64 helper rewalks the pgtables in find_num_contig to answer
+whether the huge pte we have maps a contpmd or a contpte hugetlb folio,
+and returns CONT_PMDS or CONT_PTES, so that it can collect a/d bits over
+the contiguous ptes. We can falsely return CONT_PTES instead of
+CONT_PMDS if the addr is not aligned. On systems where CONT_PTES !=
+CONT_PMDS (meaning page size is 16K), we could collect excess A/D bit
+state, meaning extra work for the kernel. Even worse, we may iterate
+beyond the PTE table and dereference a garbage ptep pointer to access
+physical memory we don't own. Since the ptep pointer is a linear map
+address, we may run off the end of the linear map or into a hole,
+dereference a VA not mapped into the kernel pgtables and cause kernel
+panic.
+
+Fix this by aligning the pmdp pointer down to a contpmd base before
+checking equality with the passed huge pte pointer, to correctly answer
+whether the huge pte is the base of a contpmd block.
+
+Fixes: 29cb80519689 ("arm64: hugetlb: Cleanup huge_pte size discovery mechanisms")
+Cc: stable@vger.kernel.org
+Acked-by: David Hildenbrand (Arm) <david@kernel.org>
+Signed-off-by: Dev Jain <dev.jain@arm.com>
+Acked-by: Muchun Song <muchun.song@linux.dev>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/mm/hugetlbpage.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/mm/hugetlbpage.c
++++ b/arch/arm64/mm/hugetlbpage.c
+@@ -87,7 +87,7 @@ static int find_num_contig(struct mm_str
+ p4dp = p4d_offset(pgdp, addr);
+ pudp = pud_offset(p4dp, addr);
+ pmdp = pmd_offset(pudp, addr);
+- if ((pte_t *)pmdp == ptep) {
++ if ((pte_t *)PTR_ALIGN_DOWN(pmdp, sizeof(*pmdp) * CONT_PMDS) == ptep) {
+ *pgsize = PMD_SIZE;
+ return CONT_PMDS;
+ }
--- /dev/null
+From e057b94772328221405b067c3a85fe479b915dc8 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Thu, 16 Jul 2026 13:06:39 +0100
+Subject: arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates
+
+From: Will Deacon <will@kernel.org>
+
+commit e057b94772328221405b067c3a85fe479b915dc8 upstream.
+
+When seccomp support was originally added to arm64 in a1ae65b21941
+("arm64: add seccomp support"), seccomp was erroneously called _before_
+the ptrace syscall-enter-stop and therefore the tracer could trivially
+manipulate the syscall register state after the seccomp check had
+passed. This was subsequently fixed in a5cd110cb836 ("arm64/ptrace: run
+seccomp after ptrace") by moving the seccomp check after the tracer has
+run. Unfortunately, a decade later, that fix has been reported to be
+incomplete.
+
+On arm64, both the first argument to a syscall and its eventual return
+value are allocated to register x0. In order to facilitate syscall
+restarting and querying of syscall arguments on the syscall exit path,
+the original value of x0 is stashed in 'struct pt_regs::orig_x0' early
+during the syscall entry path and is returned for the first argument by
+syscall_get_arguments(). Unlike 32-bit Arm, this stashed value is not
+directly exposed via ptrace() and so changes to register x0 made by the
+tracer on a syscall-enter-stop are not reflected in 'orig_x0'. This
+means that seccomp, syscall tracepoints and audit can observe a stale
+value for the register compared to the argument that will be observed by
+the actual syscall.
+
+Re-sync 'orig_x0' from x0 on the syscall entry path following a
+potential ptrace stop (i.e. PTRACE_EVENTMSG_SYSCALL_ENTRY or
+SECCOMP_RET_TRACE). This behaviour is limited to native tasks (because
+compat tasks expose 'orig_r0' to ptrace) where the syscall is not being
+skipped (because x0 is updated to hold the return value of -ENOSYS in
+that case).
+
+Cc: Kees Cook <kees@kernel.org>
+Cc: Jinjie Ruan <ruanjinjie@huawei.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: stable@vger.kernel.org
+Reported-by: Yiqi Sun <sunyiqixm@gmail.com>
+Link: https://lore.kernel.org/all/20260529065444.1336608-1-sunyiqixm@gmail.com/
+Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
+Fixes: a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace")
+Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
+Tested-by: Jinjie Ruan <ruanjinjie@huawei.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kernel/ptrace.c | 29 +++++++++++++++++++++++++++++
+ 1 file changed, 29 insertions(+)
+
+--- a/arch/arm64/kernel/ptrace.c
++++ b/arch/arm64/kernel/ptrace.c
+@@ -2408,6 +2408,21 @@ static void report_syscall_exit(struct p
+ }
+ }
+
++static void update_syscall_orig_x0_after_ptrace(struct pt_regs *regs)
++{
++ /*
++ * Keep orig_x0 authoritative so that seccomp (via
++ * syscall_get_arguments()), audit and the restart path all see the same
++ * first argument the syscall is dispatched with, even if it has been
++ * updated by a tracer. Skip this for NO_SYSCALL (set either by the user
++ * or the tracer), as regs[0] holds the return value (see the comment in
++ * el0_svc_common()) and can be unwound using syscall_rollback().
++ * For compat tasks, orig_r0 is provided directly through GPR index 17.
++ */
++ if (!is_compat_task() && regs->syscallno != NO_SYSCALL)
++ regs->orig_x0 = regs->regs[0];
++}
++
+ int syscall_trace_enter(struct pt_regs *regs)
+ {
+ unsigned long flags = read_thread_flags();
+@@ -2417,12 +2432,26 @@ int syscall_trace_enter(struct pt_regs *
+ ret = report_syscall_entry(regs);
+ if (ret || (flags & _TIF_SYSCALL_EMU))
+ return NO_SYSCALL;
++
++ /*
++ * Ensure ptrace changes to x0 during a regular
++ * syscall-enter-stop (PTRACE_SYSCALL) are visible to
++ * subsequent seccomp checks, tracepoints and audit.
++ */
++ update_syscall_orig_x0_after_ptrace(regs);
+ }
+
+ /* Do the secure computing after ptrace; failures should be fast. */
+ if (secure_computing() == -1)
+ return NO_SYSCALL;
+
++ /*
++ * Ensure tracer changes to x0 during seccomp ptrace exit
++ * processing (SECCOMP_RET_TRACE) are visible to tracepoints and
++ * audit.
++ */
++ update_syscall_orig_x0_after_ptrace(regs);
++
+ if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
+ trace_sys_enter(regs, regs->syscallno);
+
--- /dev/null
+From ae4316f332e03e628712e9dfb89f2b7d3c70c21a Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Tue, 23 Jun 2026 21:07:14 +0930
+Subject: btrfs: do not try compression for data reloc inodes
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit ae4316f332e03e628712e9dfb89f2b7d3c70c21a upstream.
+
+[BUG]
+There is a syzbot report that the check inside get_new_location()
+triggered:
+
+ BTRFS info (device loop0): found 31 extents, stage: move data extents
+ BTRFS info (device loop0): leaf 8908800 gen 16 total ptrs 28 free space 1676 owner 18446744073709551607
+ item 0 key (256 INODE_ITEM 0) itemoff 3835 itemsize 160
+ inode generation 5 transid 0 size 0 nbytes 0
+ block group 0 mode 40755 links 1 uid 0 gid 0
+ rdev 0 sequence 0 flags 0x0
+ atime 1669132761.0
+ ctime 1669132761.0
+ mtime 1669132761.0
+ otime 0.0
+ item 1 key (256 INODE_REF 256) itemoff 3823 itemsize 12
+ index 0 name_len 2
+ item 2 key (258 INODE_ITEM 0) itemoff 3663 itemsize 160
+ inode generation 1 transid 16 size 733184 nbytes 106496
+ block group 0 mode 100600 links 0 uid 0 gid 0
+ rdev 0 sequence 24 flags 0x18
+ item 3 key (258 EXTENT_DATA 0) itemoff 3595 itemsize 68
+ generation 16 type 0
+ inline extent data size 47 ram_bytes 4096 compression 1
+ [...]
+ item 27 key (18446744073709551611 ORPHAN_ITEM 258) itemoff 2376 itemsize 0
+ BTRFS error (device loop0): unexpected non-zero offset in file extent item for data reloc inode 258 key offset 0 offset 9277520992061368337
+ ------------[ cut here ]------------
+ btrfs_abort_should_print_stack(__error)
+
+[CAUSE]
+The above dump tree shows the first file extent item is inlined, which
+should make no sense for data reloc inodes, as such inodes just
+represent where the data extents are in the relocation destination chunk.
+
+However the relocation path preallocates space for each block,
+then dirties them, cluster by cluster.
+It's possible to have a single block at the beginning of the block
+group, and no other block in the same cluster.
+
+So relocation will preallocate a file extent for that block and dirty
+the first block. Then memory pressure forces the data reloc inode to be
+written back, before any other blocks are dirtied/allocated.
+
+Finally commit 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated
+delalloc helper") changed the sequence of delalloc. Before that commit we
+always tried NOCOW first, so that dirtied block would be written back into
+the preallocated space, and appear as a regular extent.
+
+But with that commit, we always try inline first, and since compression
+is forced, we try compressing the first block, and then inline the
+compressed data, resulting in the above inlined file extent in the data
+reloc tree.
+
+Then the check in get_new_location() will check the file offset, without
+checking if the file extent is inlined or not, resulting in the above
+failure.
+
+[FIX]
+Do not allow compression for data reloc inodes.
+
+Since data reloc inode sizes are always block aligned, as long as we do
+not compress, @data_len will always be at least one block, and
+that will cause can_cow_file_range_inline() to return false, thus no
+inlined extent will be created.
+
+Reported-by: syzbot+d950c6ba09b79f6e1864@syzkaller.appspotmail.com
+Link: https://lore.kernel.org/linux-btrfs/6a373dc5.764cf64f.168fbe.0001.GAE@google.com/
+Fixes: 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated delalloc helper")
+CC: stable@vger.kernel.org
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/btrfs_inode.h | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/btrfs/btrfs_inode.h
++++ b/fs/btrfs/btrfs_inode.h
+@@ -507,6 +507,8 @@ static inline bool btrfs_inode_can_compr
+ if (inode->flags & BTRFS_INODE_NODATACOW ||
+ inode->flags & BTRFS_INODE_NODATASUM)
+ return false;
++ if (btrfs_is_data_reloc_root(inode->root))
++ return false;
+ return true;
+ }
+
--- /dev/null
+From b27e195d4db8dea263050bdbeb11881b2999c9c6 Mon Sep 17 00:00:00 2001
+From: Xu Rao <raoxu@uniontech.com>
+Date: Mon, 20 Jul 2026 20:44:21 +0100
+Subject: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL
+
+From: Xu Rao <raoxu@uniontech.com>
+
+commit b27e195d4db8dea263050bdbeb11881b2999c9c6 upstream.
+
+mmc_ioctl_cdrom_volume() first reads the audio control mode page into a
+32-byte stack buffer with cgc->buflen set to 24. If the device reports a
+block descriptor, the function increases cgc->buflen to include that
+descriptor and reads the page again.
+
+For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list
+by moving cgc->buffer forward by offset - 8 bytes. This drops the block
+descriptor from the outgoing payload and leaves a new 8-byte mode
+parameter header in front of the audio control page. However, cgc->buflen
+is left unchanged.
+
+With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8
+but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low
+level packet path to write 32 bytes from that adjusted pointer, reading 8
+bytes past the end of the 32-byte stack buffer.
+
+This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on
+drives that return a non-zero block descriptor length, which helps explain
+why it has gone unnoticed. The overread is also sent to the device as
+extra MODE SELECT payload, so it may not produce an obvious local failure.
+
+Reduce cgc->buflen by the same amount as the buffer pointer adjustment so
+the MODE SELECT transfer covers only the intended parameter list.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Signed-off-by: Xu Rao <raoxu@uniontech.com>
+Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
+Link: https://patch.msgid.link/20260720194421.1497-2-phil@philpotter.co.uk
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cdrom/cdrom.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/cdrom/cdrom.c
++++ b/drivers/cdrom/cdrom.c
+@@ -3187,6 +3187,7 @@ static noinline int mmc_ioctl_cdrom_volu
+
+ /* set volume */
+ cgc->buffer = buffer + offset - 8;
++ cgc->buflen -= offset - 8;
+ memset(cgc->buffer, 0, 8);
+ return cdrom_mode_select(cdi, cgc);
+ }
--- /dev/null
+From 17221216ae8ce6a24e8a4e787382e3ebc81b88a8 Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Wed, 27 May 2026 13:51:03 +0100
+Subject: comedi: comedi_parport: deal with premature interrupt
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 17221216ae8ce6a24e8a4e787382e3ebc81b88a8 upstream.
+
+Syzbot reported a general protection fault in
+`comedi_get_is_subdevice_running()`, which was called from the interrupt
+handler `parport_interrupt()` in the "comedi_parport" driver, but it
+does not currently have a C reproducer for the problem. It's
+probably due to a premature interrupt for one of two reasons:
+
+1. The driver sets up the interrupt handler before the comedi subdevices
+ used by the interrupt handler have been allocated, but does not
+ disable the interrupt in the parallel port's CTRL register first.
+2. The driver uses a user-supplied I/O port base address which Syzbot
+ would have supplied, but it might not be backed by real parallel port
+ hardware.
+
+Change the initialization order in the driver's comedi "attach" handler
+(`parport_attach()`) so that the hardware registers are initialized
+before the interrupt handler is requested. This should prevent
+premature interrupts occurring for real hardware.
+
+Also add a test to the interrupt handler to ensure the comedi device is
+fully attached and return early if it isn't.
+
+Fixes: 241ab6ad7108e ("Staging: comedi: add comedi_parport driver")
+Reported-by: syzbot+f24c3d5d316011bacc70@syzkaller.appspotmail.com
+Cc: stable <stable@kernel.org>
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://patch.msgid.link/20260527125104.96596-1-abbotti@mev.co.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/comedi/drivers/comedi_parport.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/drivers/comedi/drivers/comedi_parport.c
++++ b/drivers/comedi/drivers/comedi_parport.c
+@@ -211,6 +211,13 @@ static irqreturn_t parport_interrupt(int
+ unsigned int ctrl;
+ unsigned short val = 0;
+
++ /*
++ * Check device is fully attached. Device interrupts should have
++ * been disabled, but do this in case of bad hardware.
++ */
++ if (!dev->attached)
++ return IRQ_NONE;
++
+ ctrl = inb(dev->iobase + PARPORT_CTRL_REG);
+ if (!(ctrl & PARPORT_CTRL_IRQ_ENA))
+ return IRQ_NONE;
+@@ -233,6 +240,9 @@ static int parport_attach(struct comedi_
+ if (ret)
+ return ret;
+
++ outb(0, dev->iobase + PARPORT_DATA_REG);
++ outb(0, dev->iobase + PARPORT_CTRL_REG);
++
+ if (it->options[1]) {
+ ret = request_irq(it->options[1], parport_interrupt, 0,
+ dev->board_name, dev);
+@@ -288,9 +298,6 @@ static int parport_attach(struct comedi_
+ s->cancel = parport_intr_cancel;
+ }
+
+- outb(0, dev->iobase + PARPORT_DATA_REG);
+- outb(0, dev->iobase + PARPORT_CTRL_REG);
+-
+ return 0;
+ }
+
--- /dev/null
+From 9119ceb76e987c2ec2b549ea100e3268ce3a1c7c Mon Sep 17 00:00:00 2001
+From: Tze Yee Ng <tze.yee.ng@altera.com>
+Date: Wed, 24 Jun 2026 03:06:35 -0700
+Subject: firmware: stratix10-svc: fix memory leaks and list corruption bugs
+
+From: Tze Yee Ng <tze.yee.ng@altera.com>
+
+commit 9119ceb76e987c2ec2b549ea100e3268ce3a1c7c upstream.
+
+Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error
+path. Switch pmem allocation from devm_kzalloc() to kzalloc() with
+explicit kfree() in the free path to match its list-managed lifetime.
+Remove the erroneous list_del(&svc_data_mem) which corrupted the list head
+on failed lookups.
+
+Fixes: 7ca5ce896524 ("firmware: add Intel Stratix10 service layer driver")
+Cc: stable@vger.kernel.org # 5.0+
+Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com>
+Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/stratix10-svc.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/firmware/stratix10-svc.c
++++ b/drivers/firmware/stratix10-svc.c
+@@ -1845,14 +1845,16 @@ void *stratix10_svc_allocate_memory(stru
+ struct gen_pool *genpool = chan->ctrl->genpool;
+ size_t s = roundup(size, 1 << genpool->min_alloc_order);
+
+- pmem = devm_kzalloc(chan->ctrl->dev, sizeof(*pmem), GFP_KERNEL);
++ pmem = kzalloc_obj(*pmem);
+ if (!pmem)
+ return ERR_PTR(-ENOMEM);
+
+ guard(mutex)(&svc_mem_lock);
+ va = gen_pool_alloc(genpool, s);
+- if (!va)
++ if (!va) {
++ kfree(pmem);
+ return ERR_PTR(-ENOMEM);
++ }
+
+ memset((void *)va, 0, s);
+ pa = gen_pool_virt_to_phys(genpool, va);
+@@ -1878,6 +1880,7 @@ EXPORT_SYMBOL_GPL(stratix10_svc_allocate
+ void stratix10_svc_free_memory(struct stratix10_svc_chan *chan, void *kaddr)
+ {
+ struct stratix10_svc_data_mem *pmem;
++
+ guard(mutex)(&svc_mem_lock);
+
+ list_for_each_entry(pmem, &svc_data_mem, node)
+@@ -1886,10 +1889,9 @@ void stratix10_svc_free_memory(struct st
+ (unsigned long)kaddr, pmem->size);
+ pmem->vaddr = NULL;
+ list_del(&pmem->node);
++ kfree(pmem);
+ return;
+ }
+-
+- list_del(&svc_data_mem);
+ }
+ EXPORT_SYMBOL_GPL(stratix10_svc_free_memory);
+
--- /dev/null
+From bba85375f8751d6c949036269b529cdcb2a2ed8f Mon Sep 17 00:00:00 2001
+From: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
+Date: Tue, 14 Jul 2026 13:37:47 +0800
+Subject: firmware: stratix10-svc: fix teardown order in remove to prevent race
+
+From: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
+
+commit bba85375f8751d6c949036269b529cdcb2a2ed8f upstream.
+
+In stratix10_svc_drv_remove(), stratix10_svc_async_exit() was called
+before client devices were unregistered. This created a race window
+where child devices could still be issuing service requests through
+the async channels after the async infrastructure had already been
+torn down.
+
+Unregister client devices before tearing down the async threads and
+channels to ensure all in-flight service calls drain before the
+underlying infrastructure is destroyed.
+
+Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication")
+Cc: stable@vger.kernel.org
+Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
+Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/stratix10-svc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/firmware/stratix10-svc.c
++++ b/drivers/firmware/stratix10-svc.c
+@@ -2044,12 +2044,12 @@ static void stratix10_svc_drv_remove(str
+ struct stratix10_svc_controller *ctrl = platform_get_drvdata(pdev);
+ struct stratix10_svc *svc = ctrl->svc;
+
++ platform_device_unregister(svc->stratix10_svc_rsu);
++
+ stratix10_svc_async_exit(ctrl);
+
+ of_platform_depopulate(ctrl->dev);
+
+- platform_device_unregister(svc->stratix10_svc_rsu);
+-
+ for (i = 0; i < SVC_NUM_CHANNEL; i++) {
+ if (ctrl->chans[i].task) {
+ kthread_stop(ctrl->chans[i].task);
--- /dev/null
+From 9e1dc434ca708e1134332e45918935752f4410cd Mon Sep 17 00:00:00 2001
+From: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
+Date: Tue, 14 Jul 2026 13:37:46 +0800
+Subject: firmware: stratix10-svc: handle NO_RESPONSE in async poll
+
+From: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
+
+commit 9e1dc434ca708e1134332e45918935752f4410cd upstream.
+
+Define INTEL_SIP_SMC_STATUS_NO_RESPONSE (0x3) and handle it in
+stratix10_svc_async_poll() the same way as INTEL_SIP_SMC_STATUS_BUSY,
+returning -EAGAIN so callers can retry instead of treating the poll as
+a hard failure.
+
+When the Secure Device Manager has not yet produced a response for an
+asynchronous transaction, ATF is expected to return
+INTEL_SIP_SMC_STATUS_NO_RESPONSE. Without this handling, the service
+layer maps the status to -EINVAL and async clients cannot distinguish
+"not ready yet" from a real error.
+
+Fixes: bcb9f4f07061 ("firmware: stratix10-svc: Add support for async communication")
+Cc: stable@vger.kernel.org
+Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
+Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/stratix10-svc.c | 5 +++--
+ include/linux/firmware/intel/stratix10-smc.h | 4 ++++
+ 2 files changed, 7 insertions(+), 2 deletions(-)
+
+--- a/drivers/firmware/stratix10-svc.c
++++ b/drivers/firmware/stratix10-svc.c
+@@ -1487,8 +1487,9 @@ int stratix10_svc_async_poll(struct stra
+ WARN_ON_ONCE(1);
+ }
+ return 0;
+- } else if (handle->res.a0 == INTEL_SIP_SMC_STATUS_BUSY) {
+- dev_dbg(ctrl->dev, "async message is still in progress\n");
++ } else if (handle->res.a0 == INTEL_SIP_SMC_STATUS_BUSY ||
++ handle->res.a0 == INTEL_SIP_SMC_STATUS_NO_RESPONSE) {
++ dev_dbg(ctrl->dev, "async message is not ready yet\n");
+ return -EAGAIN;
+ }
+
+--- a/include/linux/firmware/intel/stratix10-smc.h
++++ b/include/linux/firmware/intel/stratix10-smc.h
+@@ -67,6 +67,9 @@
+ * INTEL_SIP_SMC_STATUS_REJECTED:
+ * Secure monitor software reject the service client's request.
+ *
++ * INTEL_SIP_SMC_STATUS_NO_RESPONSE:
++ * Secure monitor software has no response for the request yet.
++ *
+ * INTEL_SIP_SMC_STATUS_ERROR:
+ * There is error during the process of service request.
+ *
+@@ -77,6 +80,7 @@
+ #define INTEL_SIP_SMC_STATUS_OK 0x0
+ #define INTEL_SIP_SMC_STATUS_BUSY 0x1
+ #define INTEL_SIP_SMC_STATUS_REJECTED 0x2
++#define INTEL_SIP_SMC_STATUS_NO_RESPONSE 0x3
+ #define INTEL_SIP_SMC_STATUS_ERROR 0x4
+ #define INTEL_SIP_SMC_RSU_ERROR 0x7
+
--- /dev/null
+From 761b785a0cfbce43761227bc42a7f984f31f8921 Mon Sep 17 00:00:00 2001
+From: Guangshuo Li <lgs201920130244@gmail.com>
+Date: Wed, 15 Jul 2026 15:08:51 +0800
+Subject: intel_th: fix MSC output device reference leak
+
+From: Guangshuo Li <lgs201920130244@gmail.com>
+
+commit 761b785a0cfbce43761227bc42a7f984f31f8921 upstream.
+
+intel_th_output_open() looks up the output device with
+bus_find_device_by_devt(), which returns the device with a reference that
+must be dropped after use.
+
+commit 95fc36a234da ("intel_th: fix device leak on output open()")
+attempted to drop the reference from intel_th_output_release(). However,
+a successful open replaces file->f_op with the output driver file
+operations before returning, so close runs the output driver release
+callback instead.
+
+For MSC outputs, close runs intel_th_msc_release(), which only removes
+the per-file iterator and does not drop the device reference taken by
+intel_th_output_open(). Consequently, every successful MSC output open
+leaks one device reference.
+
+Drop the device reference from intel_th_msc_release(), which is the
+release path actually used for MSC output files. Remove the now-unused
+intel_th_output_release() callback from intel_th_output_fops.
+
+Fixes: 95fc36a234da ("intel_th: fix device leak on output open()")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
+Reviewed-by: Johan Hovold <johan@kernel.org>
+Link: https://patch.msgid.link/20260715070851.2077965-1-lgs201920130244@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/hwtracing/intel_th/core.c | 10 ----------
+ drivers/hwtracing/intel_th/msu.c | 2 ++
+ 2 files changed, 2 insertions(+), 10 deletions(-)
+
+--- a/drivers/hwtracing/intel_th/core.c
++++ b/drivers/hwtracing/intel_th/core.c
+@@ -843,18 +843,8 @@ err_put_dev:
+ return err;
+ }
+
+-static int intel_th_output_release(struct inode *inode, struct file *file)
+-{
+- struct intel_th_device *thdev = file->private_data;
+-
+- put_device(&thdev->dev);
+-
+- return 0;
+-}
+-
+ static const struct file_operations intel_th_output_fops = {
+ .open = intel_th_output_open,
+- .release = intel_th_output_release,
+ .llseek = noop_llseek,
+ };
+
+--- a/drivers/hwtracing/intel_th/msu.c
++++ b/drivers/hwtracing/intel_th/msu.c
+@@ -1490,8 +1490,10 @@ static int intel_th_msc_release(struct i
+ {
+ struct msc_iter *iter = file->private_data;
+ struct msc *msc = iter->msc;
++ struct intel_th_device *thdev = msc->thdev;
+
+ msc_iter_remove(iter, msc);
++ put_device(&thdev->dev);
+
+ return 0;
+ }
--- /dev/null
+From 485ed44db5694d8d2e5027f63ad608e705286f30 Mon Sep 17 00:00:00 2001
+From: George Guo <guodongtai@kylinos.cn>
+Date: Thu, 23 Jul 2026 22:27:30 +0800
+Subject: LoongArch: Fix address space mismatch in kexec command line lookup
+
+From: George Guo <guodongtai@kylinos.cn>
+
+commit 485ed44db5694d8d2e5027f63ad608e705286f30 upstream.
+
+When searching the loaded segments for the "kexec" command line marker,
+the kexec_load(2) path (file_mode == 0) passes the user-space segment
+buffer straight to strncmp() through a bogus (char __user *) cast. This
+dereferences a user pointer in kernel context, which is wrong and is
+flagged by sparse:
+
+ arch/loongarch/kernel/machine_kexec.c:84:51: sparse: incorrect type in
+ argument 2 (different address spaces) @@ expected char const * @@ got
+ char [noderef] __user *
+
+Here copy the marker-sized prefix of each segment into a small on-stack
+buffer with copy_from_user() before comparing, and skip segments that
+fault. The subsequent copy_from_user() that stages the full command line
+into the safe area is left unchanged.
+
+Cc: stable@vger.kernel.org
+Fixes: 4a03b2ac06a5 ("LoongArch: Add kexec support")
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202605051639.aEPioXdD-lkp@intel.com/
+Co-developed-by: Kexin Liu <liukexin@kylinos.cn>
+Signed-off-by: Kexin Liu <liukexin@kylinos.cn>
+Signed-off-by: George Guo <guodongtai@kylinos.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kernel/machine_kexec.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/arch/loongarch/kernel/machine_kexec.c
++++ b/arch/loongarch/kernel/machine_kexec.c
+@@ -42,6 +42,7 @@ static unsigned long first_ind_entry;
+ int machine_kexec_prepare(struct kimage *kimage)
+ {
+ int i;
++ char head[8];
+ char *bootloader = "kexec";
+ void *cmdline_ptr = (void *)KEXEC_CMDLINE_ADDR;
+
+@@ -59,7 +60,9 @@ int machine_kexec_prepare(struct kimage
+ } else {
+ /* Find the command line */
+ for (i = 0; i < kimage->nr_segments; i++) {
+- if (!strncmp(bootloader, (char __user *)kimage->segment[i].buf, strlen(bootloader))) {
++ if (copy_from_user(head, kimage->segment[i].buf, strlen(bootloader)))
++ continue;
++ if (!strncmp(bootloader, head, strlen(bootloader))) {
+ if (!copy_from_user(cmdline_ptr, kimage->segment[i].buf, COMMAND_LINE_SIZE))
+ kimage->arch.cmdline_ptr = (unsigned long)cmdline_ptr;
+ break;
--- /dev/null
+From 7ea74820edcb22ffa3fb068076d73c6821d7e6d2 Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Thu, 23 Jul 2026 22:27:16 +0800
+Subject: LoongArch: Fix build errors due to wrong instructions for 32BIT
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit 7ea74820edcb22ffa3fb068076d73c6821d7e6d2 upstream.
+
+In some assembly files there are some instructions that only valid for
+64BIT, but those files can be compiled for 32BIT and cause build errors.
+
+So, replace those instructions with macros:
+li.d --> LONG_LI (li.w or li.d), addi.d --> PTR_ADDI (addi.w or addi.d).
+
+BTW, Re-tab the indention in the assembly files for alignment.
+
+Cc: stable@vger.kernel.org # 6.19+
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kernel/rethook_trampoline.S | 18 +++++++++---------
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+--- a/arch/loongarch/kernel/rethook_trampoline.S
++++ b/arch/loongarch/kernel/rethook_trampoline.S
+@@ -71,27 +71,27 @@
+ cfi_ld s7, PT_R30
+ cfi_ld s8, PT_R31
+ LONG_L t0, sp, PT_CRMD
+- li.d t1, 0x7 /* mask bit[1:0] PLV, bit[2] IE */
++ LONG_LI t1, 0x7 /* mask bit[1:0] PLV, bit[2] IE */
+ csrxchg t0, t1, LOONGARCH_CSR_CRMD
+ .endm
+
+ SYM_CODE_START(arch_rethook_trampoline)
+ UNWIND_HINT_UNDEFINED
+- addi.d sp, sp, -PT_SIZE
++ PTR_ADDI sp, sp, -PT_SIZE
+ save_all_base_regs
+
+- addi.d t0, sp, PT_SIZE
+- LONG_S t0, sp, PT_R3
++ PTR_ADDI t0, sp, PT_SIZE
++ LONG_S t0, sp, PT_R3
+
+- move a0, sp /* pt_regs */
++ move a0, sp /* pt_regs */
+
+- bl arch_rethook_trampoline_callback
++ bl arch_rethook_trampoline_callback
+
+ /* use the result as the return-address */
+- move ra, a0
++ move ra, a0
+
+ restore_all_base_regs
+- addi.d sp, sp, PT_SIZE
++ PTR_ADDI sp, sp, PT_SIZE
+
+- jr ra
++ jr ra
+ SYM_CODE_END(arch_rethook_trampoline)
--- /dev/null
+From 73555fdab5e1e4f24ca000c41a616b34edf4b55d Mon Sep 17 00:00:00 2001
+From: Haoran Jiang <jianghaoran@kylinos.cn>
+Date: Thu, 23 Jul 2026 22:27:30 +0800
+Subject: LoongArch: Fix oops during single-step debugging
+
+From: Haoran Jiang <jianghaoran@kylinos.cn>
+
+commit 73555fdab5e1e4f24ca000c41a616b34edf4b55d upstream.
+
+When entering KDB via a breakpoint and then performing single-step
+debugging, an oops is triggered. Now during single-step debugging,
+kdb_local() expects the reason to be KDB_REASON_SSTEP, but it is
+actually KDB_REASON_OOPS. In kdb_stub(), when determining the reason,
+the ex_vector for single-step should be 0, as already implemented on
+other architectures such as arm64 and riscv.
+
+Before the patch:
+[112]kdb> ss
+
+Entering kdb (current=0x900020009f520000, pid 10661) on
+processor 112 Oops: (null)
+due to oops @ 0x90000000005b57a4
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Haoran Jiang <jianghaoran@kylinos.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kernel/kgdb.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/loongarch/kernel/kgdb.c
++++ b/arch/loongarch/kernel/kgdb.c
+@@ -252,7 +252,8 @@ static int kgdb_loongarch_notify(struct
+ if (atomic_read(&kgdb_active) != -1)
+ kgdb_nmicallback(smp_processor_id(), regs);
+
+- if (kgdb_handle_exception(args->trapnr, args->signr, cmd, regs))
++ if (kgdb_handle_exception(regs->csr_era == stepped_address ? 0 : args->trapnr,
++ args->signr, cmd, regs))
+ return NOTIFY_DONE;
+
+ if (atomic_read(&kgdb_setting_breakpoint))
--- /dev/null
+From 7917d16d14fb512f8ffe3815b7940b6c93ff4fde Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Thu, 23 Jul 2026 22:27:15 +0800
+Subject: LoongArch: Increase TASK_STRUCT_OFFSET up to 2040 for 32BIT
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+commit 7917d16d14fb512f8ffe3815b7940b6c93ff4fde upstream.
+
+THREAD_INFO_IN_TASK increase the size of task_struct, which casuses a
+build error for the 32BIT kernel if RANDSTRUCT is enabled. So increase
+TASK_STRUCT_OFFSET as big as possible (2040), but can still be aligned
+and be fit in the addi.w instruction.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/include/asm/asmmacro.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/loongarch/include/asm/asmmacro.h
++++ b/arch/loongarch/include/asm/asmmacro.h
+@@ -14,7 +14,7 @@
+ #ifdef CONFIG_64BIT
+ #define TASK_STRUCT_OFFSET 0
+ #else
+-#define TASK_STRUCT_OFFSET 2000
++#define TASK_STRUCT_OFFSET 2040
+ #endif
+
+ .macro cpu_save_nonscratch thread
--- /dev/null
+From ea68d444a658783234a06f05414e41cf93a18fb2 Mon Sep 17 00:00:00 2001
+From: Kanglong Wang <wangkanglong@loongson.cn>
+Date: Thu, 23 Jul 2026 22:27:29 +0800
+Subject: LoongArch: Move jump_label_init() before parse_early_param()
+
+From: Kanglong Wang <wangkanglong@loongson.cn>
+
+commit ea68d444a658783234a06f05414e41cf93a18fb2 upstream.
+
+When enabling both CONFIG_MEM_ALLOC_PROFILING=y and
+CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y, then diabling memory
+profiling by adding the boot parameter 'sysctl.vm.mem_profiling=0' will
+cause the kernel failed to boot.
+
+After analysis, this is because jump_label_init() must be called before
+parse_early_param(), the early param handlers may modify static keys by
+static_branch_enable/disable().
+
+Fix this by moving jump_label_init() to before parse_early_param(). The
+solution is similar to other architectures.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Kanglong Wang <wangkanglong@loongson.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kernel/setup.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/arch/loongarch/kernel/setup.c
++++ b/arch/loongarch/kernel/setup.c
+@@ -602,6 +602,7 @@ void __init setup_arch(char **cmdline_p)
+ memblock_init();
+ pagetable_init();
+ bootcmdline_init(cmdline_p);
++ jump_label_init(); /* Initialise the static keys for early params */
+ parse_early_param();
+ reserve_initrd_mem();
+
+@@ -609,8 +610,6 @@ void __init setup_arch(char **cmdline_p)
+ arch_mem_init(cmdline_p);
+
+ resource_init();
+- jump_label_init(); /* Initialise the static keys for paravirtualization */
+-
+ #ifdef CONFIG_SMP
+ plat_smp_setup();
+ prefill_possible_map();
--- /dev/null
+From 4e8f58620f6717f72f3d88a2c8f25c0c656d0ba7 Mon Sep 17 00:00:00 2001
+From: Rong Bao <rong.bao@csmantle.top>
+Date: Thu, 23 Jul 2026 22:27:29 +0800
+Subject: LoongArch: Retrieve CPU package ID from PPTT when available
+
+From: Rong Bao <rong.bao@csmantle.top>
+
+commit 4e8f58620f6717f72f3d88a2c8f25c0c656d0ba7 upstream.
+
+Currently, the LoongArch CPU topology initialization code calculates
+each core's package ID by dividing its physical ID by loongson_sysconf.
+cores_per_package. This relies on the assumption that cores_per_package
+counts in the same domain as physical IDs.
+
+On Loongson-3B6000 (XB612B0V_1.2), cores_per_package matches the visible
+core count -- 24 in this case. However, the physical IDs range from 0 to
+31 in a noncontinuous fashion:
+
+ $ cat /proc/cpuinfo | grep -i -F 'global_id'
+ global_id : 0
+ global_id : 1
+ global_id : 4
+ global_id : 5
+ global_id : 6
+ global_id : 7
+ global_id : 8
+ global_id : 9
+ global_id : 10
+ global_id : 11
+ global_id : 14
+ global_id : 15
+ global_id : 16
+ global_id : 17
+ global_id : 20
+ global_id : 21
+ global_id : 22
+ global_id : 23
+ global_id : 26
+ global_id : 27
+ global_id : 28
+ global_id : 29
+ global_id : 30
+ global_id : 31
+
+Retrieve the exact package ID from ACPI PPTT when available, in the same
+style as retrieving the core ID and thread ID in parse_acpi_topology().
+Use this information in loongson_init_secondary() when the PPTT readout
+is successful. The original division logic is kept as a fallback.
+
+Meanwhile, since some existing code paths like loongson3_cpufreq expect
+a continuous integer sequence of package IDs in [0, MAX_PACKAGES) when
+retrieving from cpu_data[], here we also canonicalize the package ID to
+be filled in parse_acpi_topology() to meet such an expectation.
+
+Cc: stable@vger.kernel.org
+Tested-by: Mingcong Bai <jeffbai@aosc.io>
+Co-developed-by: Xi Ruoyao <xry111@xry111.site>
+Signed-off-by: Xi Ruoyao <xry111@xry111.site>
+Signed-off-by: Rong Bao <rong.bao@csmantle.top>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/kernel/acpi.c | 27 ++++++++++++++++++++++++++-
+ arch/loongarch/kernel/smp.c | 4 ++--
+ 2 files changed, 28 insertions(+), 3 deletions(-)
+
+--- a/arch/loongarch/kernel/acpi.c
++++ b/arch/loongarch/kernel/acpi.c
+@@ -201,10 +201,12 @@ static void __init acpi_process_madt(voi
+ }
+
+ int pptt_enabled;
++static int acpi_nr_packages;
++static int acpi_package_ids[MAX_PACKAGES];
+
+ int __init parse_acpi_topology(void)
+ {
+- int cpu, topology_id;
++ int i, cpu, topology_id;
+
+ for_each_possible_cpu(cpu) {
+ topology_id = find_acpi_cpu_topology(cpu, 0);
+@@ -222,6 +224,29 @@ int __init parse_acpi_topology(void)
+
+ cpu_data[cpu].core = topology_id;
+ }
++
++ topology_id = find_acpi_cpu_topology_package(cpu);
++ if (topology_id < 0) {
++ pr_warn("Invalid BIOS PPTT\n");
++ return -ENOENT;
++ }
++
++ for (i = 0; i < acpi_nr_packages; i++)
++ if (acpi_package_ids[i] == topology_id)
++ break;
++
++ if (i == acpi_nr_packages)
++ acpi_package_ids[acpi_nr_packages++] = topology_id;
++
++ cpu_data[cpu].package = topology_id;
++ }
++
++ for_each_possible_cpu(cpu) {
++ for (i = 0; i < acpi_nr_packages; i++)
++ if (cpu_data[cpu].package == acpi_package_ids[i]) {
++ cpu_data[cpu].package = i; /* Canonicalize */
++ break;
++ }
+ }
+
+ pptt_enabled = 1;
+--- a/arch/loongarch/kernel/smp.c
++++ b/arch/loongarch/kernel/smp.c
+@@ -425,10 +425,10 @@ void loongson_init_secondary(void)
+ numa_add_cpu(cpu);
+ #endif
+ per_cpu(cpu_state, cpu) = CPU_ONLINE;
+- cpu_data[cpu].package =
+- cpu_logical_map(cpu) / loongson_sysconf.cores_per_package;
+ cpu_data[cpu].core = pptt_enabled ? cpu_data[cpu].core :
+ cpu_logical_map(cpu) % loongson_sysconf.cores_per_package;
++ cpu_data[cpu].package = pptt_enabled ? cpu_data[cpu].package :
++ cpu_logical_map(cpu) / loongson_sysconf.cores_per_package;
+ cpu_data[cpu].global_id = cpu_logical_map(cpu);
+ }
+
--- /dev/null
+From f112ea910e554d58b4b39a4492b7d302f0f4204f Mon Sep 17 00:00:00 2001
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+Date: Sun, 5 Jul 2026 18:12:59 +0300
+Subject: mei: bus: access mei_device under device_lock on cleanup
+
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+
+commit f112ea910e554d58b4b39a4492b7d302f0f4204f upstream.
+
+Fix couple of problems in mei_cl_bus_dev_release():
+
+mei_cl_flush_queues() is running without lock.
+bus->file_list access after mei_dev_bus_put(bus) can become a
+use-after-free if this was the last reference to bus.
+
+Protect queues cleanup and WARN traversal by device lock there
+to avoid the concurrent access problems.
+Move WARN traversal before mei_dev_bus_put(bus).
+
+This file uses bus variable name for mei_device, adjust
+code of mei_cl_bus_dev_release() to use bus variable too.
+
+Cc: stable <stable@kernel.org>
+Fixes: 35e8a426b16a ("mei: bus: Check for still connected devices in mei_cl_bus_dev_release()")
+Reviewed-by: Menachem Adin <menachem.adin@intel.com>
+Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
+Link: https://patch.msgid.link/20260705151259.3054795-1-alexander.usyskin@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/mei/bus.c | 16 +++++++++-------
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/drivers/misc/mei/bus.c
++++ b/drivers/misc/mei/bus.c
+@@ -4,6 +4,7 @@
+ * Intel Management Engine Interface (Intel MEI) Linux driver
+ */
+
++#include <linux/cleanup.h>
+ #include <linux/module.h>
+ #include <linux/device.h>
+ #include <linux/kernel.h>
+@@ -1330,15 +1331,16 @@ static void mei_dev_bus_put(struct mei_d
+ static void mei_cl_bus_dev_release(struct device *dev)
+ {
+ struct mei_cl_device *cldev = to_mei_cl_device(dev);
+- struct mei_device *mdev = cldev->cl->dev;
++ struct mei_device *bus = cldev->bus;
+ struct mei_cl *cl;
+
+- mei_cl_flush_queues(cldev->cl, NULL);
+- mei_me_cl_put(cldev->me_cl);
+- mei_dev_bus_put(cldev->bus);
+-
+- list_for_each_entry(cl, &mdev->file_list, link)
+- WARN_ON(cl == cldev->cl);
++ scoped_guard(mutex, &bus->device_lock) {
++ mei_cl_flush_queues(cldev->cl, NULL);
++ mei_me_cl_put(cldev->me_cl);
++ list_for_each_entry(cl, &bus->file_list, link)
++ WARN_ON(cl == cldev->cl);
++ }
++ mei_dev_bus_put(bus);
+
+ kfree(cldev->cl);
+ kfree(cldev);
--- /dev/null
+From ce1fed11d18e163baf7f875152a33bf80f625c1a Mon Sep 17 00:00:00 2001
+From: Runyu Xiao <runyu.xiao@seu.edu.cn>
+Date: Wed, 17 Jun 2026 22:53:50 +0800
+Subject: misc: nsm: only unlock nsm_dev on post-lock error paths
+
+From: Runyu Xiao <runyu.xiao@seu.edu.cn>
+
+commit ce1fed11d18e163baf7f875152a33bf80f625c1a upstream.
+
+nsm_dev_ioctl() jumps to the common out label even when the initial
+copy_from_user() fails before nsm->lock has been taken. The error path
+then blindly unlocks a mutex that was never acquired.
+
+This issue was found by our static analysis tool and then manually
+reviewed against the current tree.
+
+The grounded PoC kept the miscdevice ioctl entry and the pre-lock
+copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing
+NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the
+shared out label before mutex_lock(&nsm->lock). Lockdep reported:
+
+ WARNING: bad unlock balance detected!
+ exploit/193 is trying to release lock (&global_nsm.lock) at:
+ nsm_dev_ioctl+0x5f/0xcf [vuln_msv]
+ but there are no more locks to release!
+ no locks held by exploit/193.
+
+Return immediately on the pre-lock copy_from_user() failure and keep the
+common unlock label for the post-lock paths only.
+
+Fixes: b9873755a6c8 ("misc: Add Nitro Secure Module driver")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
+Reviewed-by: Alexander Graf <graf@amazon.com>
+Link: https://patch.msgid.link/20260617145350.513875-1-runyu.xiao@seu.edu.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/nsm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/misc/nsm.c
++++ b/drivers/misc/nsm.c
+@@ -367,7 +367,7 @@ static long nsm_dev_ioctl(struct file *f
+ /* Copy user argument struct to kernel argument struct */
+ r = -EFAULT;
+ if (copy_from_user(&raw, argp, _IOC_SIZE(cmd)))
+- goto out;
++ return r;
+
+ mutex_lock(&nsm->lock);
+
--- /dev/null
+From 3b231f1e9990f4c21220d0a69733ce2105891ff9 Mon Sep 17 00:00:00 2001
+From: Xu Rao <raoxu@uniontech.com>
+Date: Mon, 13 Jul 2026 13:55:23 +0800
+Subject: misc: nsm: pin the module while the device is open
+
+From: Xu Rao <raoxu@uniontech.com>
+
+commit 3b231f1e9990f4c21220d0a69733ce2105891ff9 upstream.
+
+misc_open() installs a misc driver's file operations with fops_get(),
+which pins file_operations::owner before replacing the file's f_op. The
+NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does
+not take a module reference on the nsm driver.
+
+If the driver is built as a module, an open file descriptor can therefore
+survive rmmod of the module that provides its ioctl callbacks. A later
+ioctl through that descriptor can call into unloaded module text.
+
+Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module
+while any /dev/nsm file descriptor is open, matching the lifetime
+expectation for the installed file operations.
+
+Fixes: b9873755a6c8 ("misc: Add Nitro Secure Module driver")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Xu Rao <raoxu@uniontech.com>
+Link: https://patch.msgid.link/BE6951D13B5E5513+20260713055523.3193089-1-raoxu@uniontech.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/misc/nsm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/misc/nsm.c
++++ b/drivers/misc/nsm.c
+@@ -413,6 +413,7 @@ static int nsm_device_init_vq(struct vir
+ }
+
+ static const struct file_operations nsm_dev_fops = {
++ .owner = THIS_MODULE,
+ .unlocked_ioctl = nsm_dev_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
+ };
--- /dev/null
+From f3ca0ee2cc308e33896536789cbc5f3a12ca7b30 Mon Sep 17 00:00:00 2001
+From: Chenguang Zhao <zhaochenguang@kylinos.cn>
+Date: Wed, 22 Jul 2026 00:14:38 +0200
+Subject: mptcp: decrement subflows counter on failed passive join
+
+From: Chenguang Zhao <zhaochenguang@kylinos.cn>
+
+commit f3ca0ee2cc308e33896536789cbc5f3a12ca7b30 upstream.
+
+mptcp_pm_allow_new_subflow() increments extra_subflows before
+__mptcp_finish_join() on the passive MP_JOIN path.
+
+In case of race conditions, the subflow is dropped without calling
+mptcp_close_ssk(), so the counter is not rolled back.
+
+Call mptcp_pm_close_subflow() when the join completion fails to
+decrement the subflows counter.
+
+Fixes: 10f6d46c943d ("mptcp: fix race between MP_JOIN and close")
+Cc: stable@vger.kernel.org
+Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-1-6fb595bc86ef@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/protocol.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/mptcp/protocol.c
++++ b/net/mptcp/protocol.c
+@@ -3907,6 +3907,7 @@ bool mptcp_finish_join(struct sock *ssk)
+ mptcp_data_unlock(parent);
+
+ if (!ret) {
++ mptcp_pm_close_subflow(msk);
+ err_prohibited:
+ subflow->reset_reason = MPTCP_RST_EPROHIBIT;
+ return false;
--- /dev/null
+From 133cca19d75b9264bc2bbcdf2c3b80e3da207649 Mon Sep 17 00:00:00 2001
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+Date: Wed, 22 Jul 2026 00:14:42 +0200
+Subject: mptcp: fix BUILD_BUG_ON on legacy ARM config
+
+From: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+
+commit 133cca19d75b9264bc2bbcdf2c3b80e3da207649 upstream.
+
+The 0-day bot managed to find kernel configs that cause build failures,
+e.g. when using the StrongARM SA1100 target (ARMv4).
+
+On such legacy ARM architecture, all structures are apparently aligned
+to 32 bits, causing build issue here. Indeed, on such architecture,
+'flags' size is not equivalent to sizeof(u16) as expected, but to
+sizeof(u32).
+
+Instead, use memset(). It was not used before to ensure a simple clear
+operation was used by the compiler. But at the end, it shouldn't matter,
+and the compiler should optimise this to the same operation with or
+without memset() when -O above 0 is used. So let's switch to memset() to
+fix this issue, and reduce this complexity.
+
+Fixes: 5e939544f9d2 ("mptcp: fix uninit-value in mptcp_established_options")
+Cc: stable@vger.kernel.org
+Suggested-by: Frank Ranner <frank.ranner@intel.com>
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202605312026.Srgsz7Tp-lkp@intel.com/
+Closes: https://lore.kernel.org/oe-kbuild-all/202607031100.upQfRZTM-lkp@intel.com/
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-5-6fb595bc86ef@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/options.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+--- a/net/mptcp/options.c
++++ b/net/mptcp/options.c
+@@ -573,10 +573,7 @@ static bool mptcp_established_options_ds
+ bool ret = false;
+
+ /* Zero `use_ack` and `use_map` flags with one shot. */
+- BUILD_BUG_ON(sizeof_field(struct mptcp_ext, flags) != sizeof(u16));
+- BUILD_BUG_ON(!IS_ALIGNED(offsetof(struct mptcp_ext, flags),
+- sizeof(u16)));
+- *(u16 *)&opts->ext_copy.flags = 0;
++ memset(&opts->ext_copy.flags, 0, sizeof(opts->ext_copy.flags));
+ opts->csum_reqd = READ_ONCE(msk->csum_enabled);
+ mpext = skb ? mptcp_get_ext(skb) : NULL;
+
--- /dev/null
+From bd7aae448f6ee9d82599a4474664de1e6e91a535 Mon Sep 17 00:00:00 2001
+From: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
+Date: Wed, 22 Jul 2026 00:14:40 +0200
+Subject: mptcp: fix stale skb->sk reference on subflow close
+
+From: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
+
+commit bd7aae448f6ee9d82599a4474664de1e6e91a535 upstream.
+
+The backlog list is updated by mptcp_data_ready() under
+mptcp_data_lock(). The cleanup of backlog references to a closing
+subflow, however, was performed in mptcp_close_ssk(), before
+__mptcp_close_ssk() acquires the ssk lock, and while holding neither
+the ssk lock nor mptcp_data_lock().
+
+Because that traversal ran without mptcp_data_lock(), concurrent softirq
+RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready()
+-> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog
+entry referencing the ssk while the cleanup loop was in progress. Such
+an entry could be missed by the cleanup, or the concurrent list update
+could corrupt the traversal, leaving skb->sk pointing at the ssk after
+it is freed.
+
+A later mptcp_backlog_purge() then dereferences the stale pointer,
+triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0)
+followed by a use-after-free in mptcp_backlog_purge().
+
+Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after
+subflow->closing is set to 1 and while the ssk lock is still held,
+serialized under mptcp_data_lock(). The cleanup runs only on the push
+path (MPTCP_CF_PUSH), where backlog references accumulate; on other
+teardown paths the caller already handles cleanup.
+
+With subflow->closing set and mptcp_data_lock() held across the purge,
+any concurrent mptcp_data_ready() either completes its enqueue before
+the purge runs and is caught, or observes closing=1 and bails out. Once
+mptcp_data_unlock() is reached, no new skb referencing the ssk can be
+enqueued, so the cleanup is exhaustive.
+
+Remove the unprotected traversal from mptcp_close_ssk() entirely.
+
+Fixes: ee458a3f314e ("mptcp: introduce mptcp-level backlog")
+Cc: stable@vger.kernel.org
+Suggested-by: Paolo Abeni <pabeni@redhat.com>
+Reported-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/621
+Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
+Acked-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-3-6fb595bc86ef@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/protocol.c | 33 +++++++++++++++++++--------------
+ 1 file changed, 19 insertions(+), 14 deletions(-)
+
+--- a/net/mptcp/protocol.c
++++ b/net/mptcp/protocol.c
+@@ -2545,6 +2545,22 @@ static void __mptcp_subflow_disconnect(s
+ }
+ }
+
++static void mptcp_cleanup_ssk_backlog(struct sock *sk, struct sock *ssk)
++{
++ struct mptcp_sock *msk = mptcp_sk(sk);
++ struct sk_buff *skb;
++
++ mptcp_data_lock(sk);
++ list_for_each_entry(skb, &msk->backlog_list, list) {
++ if (skb->sk != ssk)
++ continue;
++
++ atomic_sub(skb->truesize, &skb->sk->sk_rmem_alloc);
++ skb->sk = NULL;
++ }
++ mptcp_data_unlock(sk);
++}
++
+ /* subflow sockets can be either outgoing (connect) or incoming
+ * (accept).
+ *
+@@ -2568,6 +2584,9 @@ static void __mptcp_close_ssk(struct soc
+ lock_sock_nested(ssk, SINGLE_DEPTH_NESTING);
+ subflow->closing = 1;
+
++ if (flags & MPTCP_CF_PUSH)
++ mptcp_cleanup_ssk_backlog(sk, ssk);
++
+ /* Borrow the fwd allocated page left-over; fwd memory for the subflow
+ * could be negative at this point, but will be reach zero soon - when
+ * the data allocated using such fragment will be freed.
+@@ -2659,9 +2678,6 @@ out:
+ void mptcp_close_ssk(struct sock *sk, struct sock *ssk,
+ struct mptcp_subflow_context *subflow)
+ {
+- struct mptcp_sock *msk = mptcp_sk(sk);
+- struct sk_buff *skb;
+-
+ /* The first subflow can already be closed or disconnected */
+ if (subflow->close_event_done || READ_ONCE(subflow->local_id) < 0)
+ return;
+@@ -2671,17 +2687,6 @@ void mptcp_close_ssk(struct sock *sk, st
+ if (sk->sk_state == TCP_ESTABLISHED)
+ mptcp_event(MPTCP_EVENT_SUB_CLOSED, mptcp_sk(sk), ssk, GFP_KERNEL);
+
+- /* Remove any reference from the backlog to this ssk; backlog skbs consume
+- * space in the msk receive queue, no need to touch sk->sk_rmem_alloc
+- */
+- list_for_each_entry(skb, &msk->backlog_list, list) {
+- if (skb->sk != ssk)
+- continue;
+-
+- atomic_sub(skb->truesize, &skb->sk->sk_rmem_alloc);
+- skb->sk = NULL;
+- }
+-
+ /* subflow aborted before reaching the fully_established status
+ * attempt the creation of the next subflow
+ */
--- /dev/null
+From b2ff91b752b0d85e8815e7f44fd85205c4268094 Mon Sep 17 00:00:00 2001
+From: Michael Bommarito <michael.bommarito@gmail.com>
+Date: Thu, 9 Jul 2026 15:19:25 -0400
+Subject: mptcp: only set DATA_FIN when a mapping is present
+
+From: Michael Bommarito <michael.bommarito@gmail.com>
+
+commit b2ff91b752b0d85e8815e7f44fd85205c4268094 upstream.
+
+mptcp_get_options() clears only the status group of struct
+mptcp_options_received; data_seq, subflow_seq and data_len are filled in
+by mptcp_parse_option() exclusively inside the DSS mapping block, which
+runs only when the DSS M (mapping present) bit is set.
+
+A peer can send a DSS option with the DATA_FIN flag set but the mapping
+bit clear. The parser then records mp_opt->data_fin while leaving
+data_len and data_seq uninitialized. For a zero-length segment
+mptcp_incoming_options() evaluates
+
+ if (mp_opt.data_fin && mp_opt.data_len == 1 &&
+ mptcp_update_rcv_data_fin(msk, mp_opt.data_seq, mp_opt.dsn64))
+
+which reads the uninitialized data_len and data_seq; KMSAN reports an
+uninit-value in mptcp_incoming_options(). The stale data_seq can also be
+fed into the receive-side DATA_FIN sequence tracking.
+
+Record the DATA_FIN flag only when the DSS option carries a mapping, so
+data_fin is never set without data_seq and data_len also being present.
+data_fin is part of the status group that mptcp_get_options() clears up
+front, so on the no-map path it stays zero and the zero-length DATA_FIN
+branch is simply skipped. A DATA_FIN is always transmitted together with
+a mapping (mptcp_write_data_fin() sets use_map along with data_seq and
+data_len), so legitimate DATA_FIN handling is unaffected.
+
+Move the pr_debug() that logs the parsed DSS flags below the mapping
+block, so it reports the final data_fin value instead of the stale one
+it would otherwise print before the assignment.
+
+Fixes: 43b54c6ee382 ("mptcp: Use full MPTCP-level disconnect state machine")
+Suggested-by: Paolo Abeni <pabeni@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260709191925.2811195-1-michael.bommarito@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/options.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/net/mptcp/options.c
++++ b/net/mptcp/options.c
+@@ -157,17 +157,11 @@ static void mptcp_parse_option(const str
+ ptr++;
+
+ flags = (*ptr++) & MPTCP_DSS_FLAG_MASK;
+- mp_opt->data_fin = (flags & MPTCP_DSS_DATA_FIN) != 0;
+ mp_opt->dsn64 = (flags & MPTCP_DSS_DSN64) != 0;
+ mp_opt->use_map = (flags & MPTCP_DSS_HAS_MAP) != 0;
+ mp_opt->ack64 = (flags & MPTCP_DSS_ACK64) != 0;
+ mp_opt->use_ack = (flags & MPTCP_DSS_HAS_ACK);
+
+- pr_debug("data_fin=%d dsn64=%d use_map=%d ack64=%d use_ack=%d\n",
+- mp_opt->data_fin, mp_opt->dsn64,
+- mp_opt->use_map, mp_opt->ack64,
+- mp_opt->use_ack);
+-
+ expected_opsize = TCPOLEN_MPTCP_DSS_BASE;
+
+ if (mp_opt->use_ack) {
+@@ -178,12 +172,18 @@ static void mptcp_parse_option(const str
+ }
+
+ if (mp_opt->use_map) {
++ mp_opt->data_fin = (flags & MPTCP_DSS_DATA_FIN) != 0;
+ if (mp_opt->dsn64)
+ expected_opsize += TCPOLEN_MPTCP_DSS_MAP64;
+ else
+ expected_opsize += TCPOLEN_MPTCP_DSS_MAP32;
+ }
+
++ pr_debug("data_fin=%d dsn64=%d use_map=%d ack64=%d use_ack=%d\n",
++ mp_opt->data_fin, mp_opt->dsn64,
++ mp_opt->use_map, mp_opt->ack64,
++ mp_opt->use_ack);
++
+ /* Always parse any csum presence combination, we will enforce
+ * RFC 8684 Section 3.3.0 checks later in subflow_data_ready
+ */
--- /dev/null
+From 9bc6d5e4ca9f3cbb41d43400b3a31cb0403796c9 Mon Sep 17 00:00:00 2001
+From: Geliang Tang <tanggeliang@kylinos.cn>
+Date: Wed, 22 Jul 2026 00:14:39 +0200
+Subject: mptcp: pm: userspace: fix use-after-free in get_local_id
+
+From: Geliang Tang <tanggeliang@kylinos.cn>
+
+commit 9bc6d5e4ca9f3cbb41d43400b3a31cb0403796c9 upstream.
+
+In mptcp_pm_userspace_get_local_id(), the address entry is looked up under
+spinlock, but its id is read after dropping the lock. A concurrent deletion
+can free the entry between the unlock and the read, leading to UAF.
+
+The race window is narrow. It was reproduced only with a locally
+constructed stress test that repeatedly overlaps an MP_JOIN SYN with a
+MPTCP_PM_CMD_SUBFLOW_DESTROY request.
+
+However, the KASAN report below confirms that the race is reachable:
+
+ [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0
+ [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0
+ ...
+ [ 666.319401] Call Trace:
+ [ 666.319405] <IRQ>
+ [ 666.319408] dump_stack_lvl+0x53/0x70
+ [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0
+ [ 666.319418] print_report+0xbe/0x2b0
+ [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0
+ [ 666.319423] kasan_report+0xce/0x100
+ [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0
+ [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0
+ [ 666.319433] mptcp_pm_get_local_id+0x371/0x440
+ ...
+ [ 666.319821] Allocated by task 45539:
+ [ 666.319844] kasan_save_stack+0x33/0x60
+ [ 666.319855] kasan_save_track+0x14/0x30
+ [ 666.319858] __kasan_kmalloc+0x8f/0xa0
+ [ 666.319863] __kmalloc_noprof+0x1e7/0x520
+ [ 666.319867] sock_kmalloc+0xdf/0x130
+ [ 666.319885] sock_kmemdup+0x1b/0x40
+ [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500
+ [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610
+ ...
+ [ 666.319967] Freed by task 45560:
+ [ 666.319988] kasan_save_stack+0x33/0x60
+ [ 666.319991] kasan_save_track+0x14/0x30
+ [ 666.319994] kasan_save_free_info+0x3b/0x60
+ [ 666.319998] __kasan_slab_free+0x43/0x70
+ [ 666.320000] kfree+0x166/0x440
+ [ 666.320003] sock_kfree_s+0x1d/0x50
+ [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200
+ [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0
+
+Fix by copying the id into a local variable while still holding the lock,
+and use -1 as a "not found" sentinel.
+
+Fixes: f012d796a6de ("mptcp: check addrs list in userspace_pm_get_local_id")
+Cc: stable@vger.kernel.org
+Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
+Tested-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-2-6fb595bc86ef@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/pm_userspace.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/net/mptcp/pm_userspace.c
++++ b/net/mptcp/pm_userspace.c
+@@ -132,12 +132,15 @@ int mptcp_userspace_pm_get_local_id(stru
+ __be16 msk_sport = ((struct inet_sock *)
+ inet_sk((struct sock *)msk))->inet_sport;
+ struct mptcp_pm_addr_entry *entry;
++ int id;
+
+ spin_lock_bh(&msk->pm.lock);
+ entry = mptcp_userspace_pm_lookup_addr(msk, &skc->addr);
++ id = entry ? entry->addr.id : -1;
+ spin_unlock_bh(&msk->pm.lock);
+- if (entry)
+- return entry->addr.id;
++
++ if (id != -1)
++ return id;
+
+ if (skc->addr.port == msk_sport)
+ skc->addr.port = 0;
--- /dev/null
+From 5a81c35c3b18cd59ded56171a6a9f643b92a6759 Mon Sep 17 00:00:00 2001
+From: Miguel Ojeda <ojeda@kernel.org>
+Date: Fri, 10 Jul 2026 19:32:52 +0200
+Subject: objtool/rust: add one more `noreturn` Rust function for Rust 1.99.0
+
+From: Miguel Ojeda <ojeda@kernel.org>
+
+commit 5a81c35c3b18cd59ded56171a6a9f643b92a6759 upstream.
+
+Starting with Rust 1.99.0 (expected 2026-10-01), under
+`CONFIG_RUST_DEBUG_ASSERTIONS=y`, `objtool` may report:
+
+ rust/kernel.o: warning: objtool: _R..._6kernel12module_param9set_paramaEB4_()
+ falls through to next function _R..._6kernel12module_param9set_paramhEB4_()
+
+(and many others) due to calls to the `noreturn` symbol [1]:
+
+ core::panicking::panic_null_reference_constructed
+
+Thus add the mangled one to the list so that `objtool` knows it is
+actually `noreturn`.
+
+See commit 56d680dd23c3 ("objtool/rust: list `noreturn` Rust functions")
+for more details.
+
+Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
+Cc: Josh Poimboeuf <jpoimboe@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Petr Pavlu <petr.pavlu@suse.com>
+Link: https://github.com/rust-lang/rust/pull/158796 [1]
+Reported-by: Alice Ryhl <aliceryhl@google.com>
+Closes: https://lore.kernel.org/rust-for-linux/alEBInX9gD1M5NAr@google.com/
+Reviewed-by: Alice Ryhl <aliceryhl@google.com>
+Tested-by: Alice Ryhl <aliceryhl@google.com>
+Link: https://patch.msgid.link/20260710173252.191781-1-ojeda@kernel.org
+Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/objtool/check.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/tools/objtool/check.c
++++ b/tools/objtool/check.c
+@@ -211,6 +211,7 @@ static bool is_rust_noreturn(const struc
+ str_ends_with(func->name, "_4core9panicking18panic_nounwind_fmt") ||
+ str_ends_with(func->name, "_4core9panicking19assert_failed_inner") ||
+ str_ends_with(func->name, "_4core9panicking30panic_null_pointer_dereference") ||
++ str_ends_with(func->name, "_4core9panicking32panic_null_reference_constructed") ||
+ str_ends_with(func->name, "_4core9panicking36panic_misaligned_pointer_dereference") ||
+ str_ends_with(func->name, "_7___rustc17rust_begin_unwind") ||
+ strstr(func->name, "_4core9panicking13assert_failed") ||
--- /dev/null
+From 26b483d52417253d88a3a01262ac85914a7aec8e Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Fri, 17 Jul 2026 17:25:58 +0100
+Subject: Revert "arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates"
+
+From: Will Deacon <will@kernel.org>
+
+commit 26b483d52417253d88a3a01262ac85914a7aec8e upstream.
+
+This reverts commit e057b94772328221405b067c3a85fe479b915dc8.
+
+Sashiko points out that updating 'orig_x0' after secure_computing()
+has returned is too late to handle the case where a seccomp filter is
+re-evaluated after initially returning SECCOMP_RET_TRACE. This means
+that a tracer can manipulate the first argument of the syscall behind
+seccomp's back.
+
+For now, revert the initial fix and we'll have another crack at it soon.
+Since the incorrect fix was cc'd to stable, do the same here with an
+appropriate fixes tag.
+
+Cc: stable@vger.kernel.org
+Fixes: e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates")
+Link: https://sashiko.dev/#/patchset/20260716120640.6590-1-will@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kernel/ptrace.c | 29 -----------------------------
+ 1 file changed, 29 deletions(-)
+
+--- a/arch/arm64/kernel/ptrace.c
++++ b/arch/arm64/kernel/ptrace.c
+@@ -2408,21 +2408,6 @@ static void report_syscall_exit(struct p
+ }
+ }
+
+-static void update_syscall_orig_x0_after_ptrace(struct pt_regs *regs)
+-{
+- /*
+- * Keep orig_x0 authoritative so that seccomp (via
+- * syscall_get_arguments()), audit and the restart path all see the same
+- * first argument the syscall is dispatched with, even if it has been
+- * updated by a tracer. Skip this for NO_SYSCALL (set either by the user
+- * or the tracer), as regs[0] holds the return value (see the comment in
+- * el0_svc_common()) and can be unwound using syscall_rollback().
+- * For compat tasks, orig_r0 is provided directly through GPR index 17.
+- */
+- if (!is_compat_task() && regs->syscallno != NO_SYSCALL)
+- regs->orig_x0 = regs->regs[0];
+-}
+-
+ int syscall_trace_enter(struct pt_regs *regs)
+ {
+ unsigned long flags = read_thread_flags();
+@@ -2432,26 +2417,12 @@ int syscall_trace_enter(struct pt_regs *
+ ret = report_syscall_entry(regs);
+ if (ret || (flags & _TIF_SYSCALL_EMU))
+ return NO_SYSCALL;
+-
+- /*
+- * Ensure ptrace changes to x0 during a regular
+- * syscall-enter-stop (PTRACE_SYSCALL) are visible to
+- * subsequent seccomp checks, tracepoints and audit.
+- */
+- update_syscall_orig_x0_after_ptrace(regs);
+ }
+
+ /* Do the secure computing after ptrace; failures should be fast. */
+ if (secure_computing() == -1)
+ return NO_SYSCALL;
+
+- /*
+- * Ensure tracer changes to x0 during seccomp ptrace exit
+- * processing (SECCOMP_RET_TRACE) are visible to tracepoints and
+- * audit.
+- */
+- update_syscall_orig_x0_after_ptrace(regs);
+-
+ if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
+ trace_sys_enter(regs, regs->syscallno);
+
--- /dev/null
+From 8173f7e2ce67e6ca1d4763f3da14e5b01ce77456 Mon Sep 17 00:00:00 2001
+From: "Cen Zhang (Microsoft)" <blbllhy@gmail.com>
+Date: Tue, 7 Jul 2026 12:41:15 -0400
+Subject: rhashtable: clear stale iter->p on table restart
+
+From: Cen Zhang (Microsoft) <blbllhy@gmail.com>
+
+commit 8173f7e2ce67e6ca1d4763f3da14e5b01ce77456 upstream.
+
+rhashtable_walk_start_check() has two restart paths when resuming a walk.
+When iter->walker.tbl is valid, it re-validates iter->p against the table
+and sets iter->p = NULL if the object is gone. When iter->walker.tbl is
+NULL (table was freed during resize), it resets slot and skip but forgets
+to clear iter->p.
+
+rhashtable_walk_next() then dereferences the stale iter->p, reading
+freed memory. This is a use-after-free.
+
+Any caller that does multi-fragment rhashtable walks across
+walk_stop/walk_start boundaries is affected. Concrete cases include
+netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC
+(tipc_nl_sk_walk in net/tipc/socket.c).
+
+Crash stack (netlink_diag):
+ BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0
+ Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080)
+ Call Trace:
+ rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016)
+ __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122)
+ netlink_diag_dump+0xc2/0x240
+ netlink_dump+0x5bc/0x1270
+ netlink_recvmsg+0x7a3/0x980
+ sock_recvmsg+0x1bc/0x200
+ __sys_recvfrom+0x1d4/0x2c0
+
+Fixes: 5d240a8936f6 ("rhashtable: improve rhashtable_walk stability when stop/start used.")
+Cc: <stable@vger.kernel.org>
+Reported-by: AutonomousCodeSecurity@microsoft.com
+Reported-by: Yuan Tan <yuantan098@gmail.com>
+Closes: https://lore.kernel.org/linux-crypto/CAB8m9Wh559e+=n8z51gB8DrbEyCc2mc0MgGjrRR6_VXBmU=2AQ@mail.gmail.com
+Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com>
+Reviewed-by: NeilBrown <neil@brown.name>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ lib/rhashtable.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/lib/rhashtable.c
++++ b/lib/rhashtable.c
+@@ -776,6 +776,7 @@ int rhashtable_walk_start_check(struct r
+ iter->walker.tbl = rht_dereference_rcu(ht->tbl, ht);
+ iter->slot = 0;
+ iter->skip = 0;
++ iter->p = NULL;
+ return -EAGAIN;
+ }
+
--- /dev/null
+From 4688cf884b3abcd12498e03b625d1916bf49a1e4 Mon Sep 17 00:00:00 2001
+From: Alexandre Courbot <acourbot@nvidia.com>
+Date: Wed, 8 Jul 2026 19:49:26 +0900
+Subject: rust: allow `clippy::unwrap_or_default` globally
+
+From: Alexandre Courbot <acourbot@nvidia.com>
+
+commit 4688cf884b3abcd12498e03b625d1916bf49a1e4 upstream.
+
+Starting with rustc 1.88, the `clippy::unwrap_or_default` lint triggers
+on `rust/kernel/soc.rs` if `CONFIG_CC_OPTIMIZE_FOR_SIZE=y`:
+
+ warning: use of `unwrap_or` to construct default value
+ --> ../rust/kernel/soc.rs:66:10
+ |
+ 66 | .unwrap_or(core::ptr::null())
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `unwrap_or_default()`
+
+This is a clippy bug [1]: the lint decides whether an expression is
+equivalent to `Default::default()` by inspecting the optimized MIR of
+`<*const T as Default>::default` exported by `core`, so its outcome
+depends on the optimization level `core` was built with. Moreover, its
+suggestion ignores our MSRV of 1.85 (`Default` for `*const T` is only
+stable since Rust 1.88), so we could not apply it anyway.
+
+Disable the lint globally rather than working around this single
+occurrence; it can be re-enabled conditionally using `rustc-min-version`
+once clippy is fixed.
+
+Link: https://github.com/rust-lang/rust-clippy/issues/17379 [1]
+Suggested-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
+Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
+Link: https://patch.msgid.link/20260708-soc_unwrap_or-v2-1-007ed724cc7b@nvidia.com
+[ Moved to non-versioned group. - Miguel ]
+Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Makefile | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/Makefile
++++ b/Makefile
+@@ -473,6 +473,10 @@ KBUILD_USERLDFLAGS := $(USERLDFLAGS)
+
+ # These flags apply to all Rust code in the tree, including the kernel and
+ # host programs.
++#
++# `-Aclippy::unwrap_or_default`: the lint is buggy [1] and ignores our
++# MSRV. It can trigger depending on the optimization level.
++# [1] https://github.com/rust-lang/rust-clippy/issues/17379
+ export rust_common_flags := --edition=2021 \
+ -Zbinary_dep_depinfo=y \
+ -Astable_features \
+@@ -501,6 +505,7 @@ export rust_common_flags := --edition=20
+ -Aclippy::uninlined_format_args \
+ -Wclippy::unnecessary_safety_comment \
+ -Wclippy::unnecessary_safety_doc \
++ -Aclippy::unwrap_or_default \
+ -Wrustdoc::missing_crate_level_docs \
+ -Wrustdoc::unescaped_backticks
+
--- /dev/null
+From 608045a91d9176d66b2114d0006bc8b57dff2ca9 Mon Sep 17 00:00:00 2001
+From: Miguel Ojeda <ojeda@kernel.org>
+Date: Mon, 15 Jun 2026 16:32:25 +0200
+Subject: rust: allow `suspicious_runtime_symbol_definitions` lint for Rust >= 1.98
+
+From: Miguel Ojeda <ojeda@kernel.org>
+
+commit 608045a91d9176d66b2114d0006bc8b57dff2ca9 upstream.
+
+Starting with Rust 1.98.0 (expected 2026-08-20), Rust is introducing a
+couple new lints, `invalid_runtime_symbol_definitions` (deny-by-default)
+and `suspicious_runtime_symbol_definitions` (warn-by-default), which check
+the signature of items whose symbol name is a runtime symbol expected by
+`core`.
+
+Our build hits the second one, i.e. the warning:
+
+ error: suspicious definition of the runtime `strlen` symbol used by the standard library
+ --> rust/bindings/bindings_generated.rs:20018:5
+ |
+ 20018 | pub fn strlen(s: *const ffi::c_char) -> usize;
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ |
+ = note: expected `unsafe extern "C" fn(*const i8) -> usize`
+ found `unsafe extern "C" fn(*const u8) -> usize`
+ = help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]`
+ = help: allow this lint if the signature is compatible
+ = note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings`
+ = help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]`
+
+ error: suspicious definition of the runtime `strlen` symbol used by the standard library
+ --> rust/uapi/uapi_generated.rs:14236:5
+ |
+ 14236 | pub fn strlen(s: *const ffi::c_char) -> usize;
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ |
+ = note: expected `unsafe extern "C" fn(*const i8) -> usize`
+ found `unsafe extern "C" fn(*const u8) -> usize`
+ = help: either fix the signature or remove any attributes like `#[unsafe(no_mangle)]`, `#[unsafe(export_name = "strlen")]`, or `#[link_name = "strlen"]`
+ = help: allow this lint if the signature is compatible
+ = note: `-D suspicious-runtime-symbol-definitions` implied by `-D warnings`
+ = help: to override `-D warnings` add `#[allow(suspicious_runtime_symbol_definitions)]`
+
+Thus `allow` the lint in `bindings` and `uapi`.
+
+A more targeted alternative to avoid `allow`ing it would be to pass
+`--blocklist-function strlen` to `bindgen`, but we would perhaps need
+to adjust if other C headers end up adding more (or Rust checking more).
+Since it is just the less critical one that we hit, and since eventually
+this should be properly fixed by getting upstream Rust to provide a flag
+like GCC/Clang's `-funsigned-char` [2][3], just `allow` it for now.
+
+Cc: Urgau <urgau@numericable.fr>
+Cc: stable@vger.kernel.org # Needed in 6.12.y and later (Rust is pinned in older LTSs).
+Link: https://github.com/rust-lang/rust/pull/155521 [1]
+Link: https://github.com/rust-lang/rust/issues/138446 [2]
+Link: https://github.com/Rust-for-Linux/linux/issues/355 [3]
+Reviewed-by: Gary Guo <gary@garyguo.net>
+Reviewed-by: Alice Ryhl <aliceryhl@google.com>
+Reviewed-by: Tamir Duberstein <tamird@kernel.org>
+Link: https://patch.msgid.link/20260615143225.471756-1-ojeda@kernel.org
+Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ init/Kconfig | 3 +++
+ rust/bindings/lib.rs | 4 ++++
+ rust/uapi/lib.rs | 4 ++++
+ 3 files changed, 11 insertions(+)
+
+--- a/init/Kconfig
++++ b/init/Kconfig
+@@ -190,6 +190,9 @@ config RUSTC_HAS_FILE_WITH_NUL
+ config RUSTC_HAS_FILE_AS_C_STR
+ def_bool RUSTC_VERSION >= 109100
+
++config RUSTC_HAS_SUSPICIOUS_RUNTIME_SYMBOL_DEFINITIONS
++ def_bool RUSTC_VERSION >= 109800
++
+ config PAHOLE_VERSION
+ int
+ default "$(PAHOLE_VERSION)"
+--- a/rust/bindings/lib.rs
++++ b/rust/bindings/lib.rs
+@@ -27,6 +27,10 @@
+ #[allow(clippy::ref_as_ptr)]
+ #[allow(clippy::undocumented_unsafe_blocks)]
+ #[cfg_attr(CONFIG_RUSTC_HAS_UNNECESSARY_TRANSMUTES, allow(unnecessary_transmutes))]
++#[cfg_attr(
++ CONFIG_RUSTC_HAS_SUSPICIOUS_RUNTIME_SYMBOL_DEFINITIONS,
++ allow(suspicious_runtime_symbol_definitions)
++)]
+ mod bindings_raw {
+ use pin_init::{MaybeZeroable, Zeroable};
+
+--- a/rust/uapi/lib.rs
++++ b/rust/uapi/lib.rs
+@@ -24,6 +24,10 @@
+ unsafe_op_in_unsafe_fn
+ )]
+ #![cfg_attr(CONFIG_RUSTC_HAS_UNNECESSARY_TRANSMUTES, allow(unnecessary_transmutes))]
++#![cfg_attr(
++ CONFIG_RUSTC_HAS_SUSPICIOUS_RUNTIME_SYMBOL_DEFINITIONS,
++ allow(suspicious_runtime_symbol_definitions)
++)]
+ #![feature(cfi_encoding)]
+
+ // Manual definition of blocklisted types.
--- /dev/null
+From a19bda861b3a79e25417462539df8b0d77c6b322 Mon Sep 17 00:00:00 2001
+From: Alice Ryhl <aliceryhl@google.com>
+Date: Thu, 16 Jul 2026 10:22:43 +0000
+Subject: rust: device: avoid trailing ; in printing macros
+
+From: Alice Ryhl <aliceryhl@google.com>
+
+commit a19bda861b3a79e25417462539df8b0d77c6b322 upstream.
+
+These macros are used like expressions, so they should not emit a
+semicolon. This is being turned into a hard error in a future release of
+Rust.
+
+ error: trailing semicolon in macro used in expression position
+ --> drivers/gpu/nova-core/firmware/fsp.rs:79:34
+ |
+ 79 | .inspect_err(|_| dev_err!(dev, "FMC firmware missing '{}' section\n", name))
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+ |
+ = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
+ = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
+ = note: this error originates in the macro `dev_err` (in Nightly builds, run with -Z macro-backtrace for more info)
+
+[ I was doubly surprised since upstream made it a deny-by-default lint
+ a year ago for Rust 1.91.0, and yet we didn't see it; plus I hadn't
+ seen this in my CI even yesterday.
+
+ It turns out this just landed into today's nightly (nightly-2026-07-16,
+ using upstream commit d0babd8b6):
+
+ Link: https://github.com/rust-lang/rust/pull/159222
+
+ which says:
+
+ "The `semicolon_in_expressions_from_macros` lint previously
+ suppressed warnings about non-local macros. This masks
+ a lint that will subsequently become a hard error."
+
+ So that explains it. And this is the PR that will make it a hard error
+ at some point in the future:
+
+ Link: https://github.com/rust-lang/rust/pull/159218
+
+ Thus starting with Rust 1.99.0 (expected 2026-10-01), we will be
+ seeing the deny-by-default lint above, so clean it up already.
+
+ - Miguel ]
+
+Cc: stable@vger.kernel.org # Needed in 6.18.y and later.
+Link: https://github.com/rust-lang/rust/issues/79813
+Signed-off-by: Alice Ryhl <aliceryhl@google.com>
+Reviewed-by: Gary Guo <gary@garyguo.net>
+Acked-by: Danilo Krummrich <dakr@kernel.org>
+Link: https://github.com/rust-lang/rust/pull/159218
+Link: https://github.com/rust-lang/rust/pull/159222
+Link: https://patch.msgid.link/20260716-device-trail-semicolon-v1-1-f48e9dcfae15@google.com
+[ Fixed typo. ]
+Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ rust/kernel/device.rs | 20 +++++++++-----------
+ 1 file changed, 9 insertions(+), 11 deletions(-)
+
+--- a/rust/kernel/device.rs
++++ b/rust/kernel/device.rs
+@@ -737,9 +737,7 @@ macro_rules! impl_device_context_into_ar
+ #[macro_export]
+ macro_rules! dev_printk {
+ ($method:ident, $dev:expr, $($f:tt)*) => {
+- {
+- $crate::device::Device::$method($dev.as_ref(), $crate::prelude::fmt!($($f)*))
+- }
++ $crate::device::Device::$method($dev.as_ref(), $crate::prelude::fmt!($($f)*))
+ }
+ }
+
+@@ -766,7 +764,7 @@ macro_rules! dev_printk {
+ /// ```
+ #[macro_export]
+ macro_rules! dev_emerg {
+- ($($f:tt)*) => { $crate::dev_printk!(pr_emerg, $($f)*); }
++ ($($f:tt)*) => { $crate::dev_printk!(pr_emerg, $($f)*) }
+ }
+
+ /// Prints an alert-level message (level 1) prefixed with device information.
+@@ -792,7 +790,7 @@ macro_rules! dev_emerg {
+ /// ```
+ #[macro_export]
+ macro_rules! dev_alert {
+- ($($f:tt)*) => { $crate::dev_printk!(pr_alert, $($f)*); }
++ ($($f:tt)*) => { $crate::dev_printk!(pr_alert, $($f)*) }
+ }
+
+ /// Prints a critical-level message (level 2) prefixed with device information.
+@@ -818,7 +816,7 @@ macro_rules! dev_alert {
+ /// ```
+ #[macro_export]
+ macro_rules! dev_crit {
+- ($($f:tt)*) => { $crate::dev_printk!(pr_crit, $($f)*); }
++ ($($f:tt)*) => { $crate::dev_printk!(pr_crit, $($f)*) }
+ }
+
+ /// Prints an error-level message (level 3) prefixed with device information.
+@@ -844,7 +842,7 @@ macro_rules! dev_crit {
+ /// ```
+ #[macro_export]
+ macro_rules! dev_err {
+- ($($f:tt)*) => { $crate::dev_printk!(pr_err, $($f)*); }
++ ($($f:tt)*) => { $crate::dev_printk!(pr_err, $($f)*) }
+ }
+
+ /// Prints a warning-level message (level 4) prefixed with device information.
+@@ -870,7 +868,7 @@ macro_rules! dev_err {
+ /// ```
+ #[macro_export]
+ macro_rules! dev_warn {
+- ($($f:tt)*) => { $crate::dev_printk!(pr_warn, $($f)*); }
++ ($($f:tt)*) => { $crate::dev_printk!(pr_warn, $($f)*) }
+ }
+
+ /// Prints a notice-level message (level 5) prefixed with device information.
+@@ -896,7 +894,7 @@ macro_rules! dev_warn {
+ /// ```
+ #[macro_export]
+ macro_rules! dev_notice {
+- ($($f:tt)*) => { $crate::dev_printk!(pr_notice, $($f)*); }
++ ($($f:tt)*) => { $crate::dev_printk!(pr_notice, $($f)*) }
+ }
+
+ /// Prints an info-level message (level 6) prefixed with device information.
+@@ -922,7 +920,7 @@ macro_rules! dev_notice {
+ /// ```
+ #[macro_export]
+ macro_rules! dev_info {
+- ($($f:tt)*) => { $crate::dev_printk!(pr_info, $($f)*); }
++ ($($f:tt)*) => { $crate::dev_printk!(pr_info, $($f)*) }
+ }
+
+ /// Prints a debug-level message (level 7) prefixed with device information.
+@@ -948,5 +946,5 @@ macro_rules! dev_info {
+ /// ```
+ #[macro_export]
+ macro_rules! dev_dbg {
+- ($($f:tt)*) => { $crate::dev_printk!(pr_dbg, $($f)*); }
++ ($($f:tt)*) => { $crate::dev_printk!(pr_dbg, $($f)*) }
+ }
--- /dev/null
+From 880c43b185ca52239e75bc546cc4f4d9154d0fed Mon Sep 17 00:00:00 2001
+From: FUJITA Tomonori <fujita.tomonori@gmail.com>
+Date: Tue, 14 Jul 2026 07:52:35 +0900
+Subject: rust: time: fix as_micros_ceil() to round correctly for negative Delta
+
+From: FUJITA Tomonori <fujita.tomonori@gmail.com>
+
+commit 880c43b185ca52239e75bc546cc4f4d9154d0fed upstream.
+
+The ceiling-division idiom `(n + d - 1) / d` only produces the
+correct result when `n` is non-negative.
+
+For example, if n = -1000 (exactly -1us), the old code computed (-1000
++ 999) / 1000 == 0 instead of -1.
+
+For negative n, truncating division already rounds towards positive
+infinity, so no bias is needed in that case.
+
+Fixes: fae0cdc12340 ("rust: time: Introduce Delta type")
+Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
+Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260713225235.3243480-1-tomo@flapping.org
+Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ rust/kernel/time.rs | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+--- a/rust/kernel/time.rs
++++ b/rust/kernel/time.rs
+@@ -441,15 +441,22 @@ impl Delta {
+ /// to the value in the [`Delta`].
+ #[inline]
+ pub fn as_micros_ceil(self) -> i64 {
++ let n = self.as_nanos();
++ let n = if n >= 0 {
++ n.saturating_add(NSEC_PER_USEC - 1)
++ } else {
++ n
++ };
++
+ #[cfg(CONFIG_64BIT)]
+ {
+- self.as_nanos().saturating_add(NSEC_PER_USEC - 1) / NSEC_PER_USEC
++ n / NSEC_PER_USEC
+ }
+
+ #[cfg(not(CONFIG_64BIT))]
+ // SAFETY: It is always safe to call `ktime_to_us()` with any value.
+ unsafe {
+- bindings::ktime_to_us(self.as_nanos().saturating_add(NSEC_PER_USEC - 1))
++ bindings::ktime_to_us(n)
+ }
+ }
+
--- /dev/null
+From bb66b1a3452534adb8b72abf2f761375970fe472 Mon Sep 17 00:00:00 2001
+From: Alice Ryhl <aliceryhl@google.com>
+Date: Wed, 8 Jul 2026 12:00:26 +0000
+Subject: rust_binder: only print failure if error has source
+
+From: Alice Ryhl <aliceryhl@google.com>
+
+commit bb66b1a3452534adb8b72abf2f761375970fe472 upstream.
+
+The commit that fixes BINDER_GET_EXTENDED_ERROR changed the condition
+for printing transaction failures so errors are printed even if the
+cause is a dead or frozen process. Undo this change so that the error
+is only printed if the failure has an errno associated with it.
+
+Cc: stable@kernel.org
+Fixes: 77bfebf11077 ("rust_binder: fix BINDER_GET_EXTENDED_ERROR")
+Signed-off-by: Alice Ryhl <aliceryhl@google.com>
+Link: https://patch.msgid.link/20260708-get-extended-error-fix-printing-v1-1-6e293b213b70@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/android/binder/thread.rs | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/android/binder/thread.rs
++++ b/drivers/android/binder/thread.rs
+@@ -1273,14 +1273,14 @@ impl Thread {
+ inner.extended_error =
+ ExtendedError::new(info.debug_id as u32, err.reply, source.to_errno());
+ }
+- }
+
+- pr_warn!(
+- "{}:{} transaction to {} failed: {err:?}",
+- info.from_pid,
+- info.from_tid,
+- info.to_pid
+- );
++ pr_warn!(
++ "{}:{} transaction to {} failed: {err:?}",
++ info.from_pid,
++ info.from_tid,
++ info.to_pid
++ );
++ }
+ }
+ }
+
--- /dev/null
+From e3213292c4fd69ba442c6ed4693f91a92b753140 Mon Sep 17 00:00:00 2001
+From: Geliang Tang <tanggeliang@kylinos.cn>
+Date: Wed, 22 Jul 2026 00:14:41 +0200
+Subject: selftests: mptcp: userspace_pm: fix undefined variable port
+
+From: Geliang Tang <tanggeliang@kylinos.cn>
+
+commit e3213292c4fd69ba442c6ed4693f91a92b753140 upstream.
+
+In make_connection(), the variable "port" is used but never defined.
+This leads to an empty argument being passed to wait_local_port_listen(),
+causing "printf: : invalid number" errors:
+
+ # INFO: Init
+ # 01 Created network namespaces ns1, ns2 [ OK ]
+ # INFO: Make connections
+ # ./../lib.sh: line 651: printf: : invalid number
+ # 02 Established IPv4 MPTCP Connection ns2 => ns1 [ OK ]
+ # INFO: Connection info: 10.0.1.2:59516 -> 10.0.1.1:50002
+ # ./../lib.sh: line 651: printf: : invalid number
+ # 03 Established IPv6 MPTCP Connection ns2 => ns1 [ OK ]
+
+Fix it by using the correctly defined variable "app_port", which holds the
+appropriate port number for the connection.
+
+Fixes: 39348f5f2f13 ("selftests: mptcp: wait for port instead of sleep")
+Cc: stable@vger.kernel.org
+Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-4-6fb595bc86ef@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/net/mptcp/userspace_pm.sh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/testing/selftests/net/mptcp/userspace_pm.sh
++++ b/tools/testing/selftests/net/mptcp/userspace_pm.sh
+@@ -212,7 +212,7 @@ make_connection()
+ ./mptcp_connect -s MPTCP -w 300 -p $app_port -l $listen_addr > /dev/null 2>&1 &
+ local server_pid=$!
+
+- mptcp_lib_wait_local_port_listen "${ns1}" "${port}"
++ mptcp_lib_wait_local_port_listen "${ns1}" "${app_port}"
+
+ # Run the client, transfer $file and stay connected to the server
+ # to conduct tests
--- /dev/null
+From f97752cfe511c1ed9933057455c73aaac07d6517 Mon Sep 17 00:00:00 2001
+From: Ethan Nelson-Moore <enelsonmoore@gmail.com>
+Date: Tue, 9 Jun 2026 10:55:04 -0700
+Subject: selftests: ntsync: correct CONFIG_NTSYNC name
+
+From: Ethan Nelson-Moore <enelsonmoore@gmail.com>
+
+commit f97752cfe511c1ed9933057455c73aaac07d6517 upstream.
+
+The config fragment for these tests defines CONFIG_WINESYNC, which
+refers to an earlier name for the ntsync driver before it was merged
+[1]. Correct it to define CONFIG_NTSYNC instead.
+
+[1] https://lore.kernel.org/all/f4cc1a38-1441-62f8-47e4-0c67f5ad1d43@codeweavers.com/
+
+Fixes: 7f853a252cde ("selftests: ntsync: Add some tests for semaphore state.")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
+Reviewed-by: Elizabeth Figura <zfigura@codeweavers.com>
+Link: https://patch.msgid.link/20260609175505.19632-1-enelsonmoore@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/drivers/ntsync/config | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/testing/selftests/drivers/ntsync/config
++++ b/tools/testing/selftests/drivers/ntsync/config
+@@ -1 +1 @@
+-CONFIG_WINESYNC=y
++CONFIG_NTSYNC=y
--- /dev/null
+From 7fb13fd7e9a59a37cd911efff83abe19e3ee029d Mon Sep 17 00:00:00 2001
+From: Jiangshan Yi <yijiangshan@kylinos.cn>
+Date: Wed, 15 Jul 2026 15:35:46 +0800
+Subject: serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR platforms
+
+From: Jiangshan Yi <yijiangshan@kylinos.cn>
+
+commit 7fb13fd7e9a59a37cd911efff83abe19e3ee029d upstream.
+
+Commit b1b4efea05a5 ("serial: 8250_mid: Disable DMA for selected
+platforms") replaced the dnv_board setup and exit callbacks with
+PTR_IF(false, ...), which evaluates to NULL. However, the three call
+sites in mid8250_probe() and mid8250_remove() unconditionally
+dereference these function pointers without NULL checks, causing a NULL
+pointer dereference (kernel oops) on any Denverton (DNV), Ice Lake Xeon
+D (ICX-D/CDF), or Snowridge (SNR) platform.
+
+Fix this by adding the missing NULL checks before calling the setup and
+exit callbacks.
+
+Fixes: b1b4efea05a5 ("serial: 8250_mid: Disable DMA for selected platforms")
+Cc: stable <stable@kernel.org>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
+Link: https://patch.msgid.link/20260715073546.1875083-1-yijiangshan@kylinos.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250_mid.c | 14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+--- a/drivers/tty/serial/8250/8250_mid.c
++++ b/drivers/tty/serial/8250/8250_mid.c
+@@ -318,9 +318,11 @@ static int mid8250_probe(struct pci_dev
+ if (!uart.port.membase)
+ return -ENOMEM;
+
+- ret = mid->board->setup(mid, &uart.port);
+- if (ret)
+- return ret;
++ if (mid->board->setup) {
++ ret = mid->board->setup(mid, &uart.port);
++ if (ret)
++ return ret;
++ }
+
+ ret = mid8250_dma_setup(mid, &uart);
+ if (ret)
+@@ -336,7 +338,8 @@ static int mid8250_probe(struct pci_dev
+ return 0;
+
+ err:
+- mid->board->exit(mid);
++ if (mid->board->exit)
++ mid->board->exit(mid);
+ return ret;
+ }
+
+@@ -346,7 +349,8 @@ static void mid8250_remove(struct pci_de
+
+ serial8250_unregister_port(mid->line);
+
+- mid->board->exit(mid);
++ if (mid->board->exit)
++ mid->board->exit(mid);
+ }
+
+ static const struct mid8250_board pnw_board = {
--- /dev/null
+From af071d9e07e57cfff239e8d09d2f3b05ebc9c667 Mon Sep 17 00:00:00 2001
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Date: Thu, 16 Jul 2026 17:08:09 -0400
+Subject: serial: sc16is7xx: implement gpio get_direction() callback
+
+From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+
+commit af071d9e07e57cfff239e8d09d2f3b05ebc9c667 upstream.
+
+It's strongly recommended for GPIO drivers to always implement the
+.get_direction() callback - even when the direction is tracked in
+software. The GPIO core emits a warning when the callback is missing
+and a user reads the direction of a line, e.g. via
+/sys/kernel/debug/gpio.
+
+Fixes: dfeae619d781 ("serial: sc16is7xx")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260716210813.2582826-1-hugo@hugovil.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/sc16is7xx.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/tty/serial/sc16is7xx.c
++++ b/drivers/tty/serial/sc16is7xx.c
+@@ -1274,6 +1274,17 @@ static int sc16is7xx_gpio_set(struct gpi
+ return 0;
+ }
+
++static int sc16is7xx_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
++{
++ struct sc16is7xx_port *s = gpiochip_get_data(chip);
++ struct uart_port *port = &s->p[0].port;
++ unsigned int val;
++
++ val = sc16is7xx_port_read(port, SC16IS7XX_IODIR_REG);
++
++ return val & BIT(offset) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN;
++}
++
+ static int sc16is7xx_gpio_direction_input(struct gpio_chip *chip,
+ unsigned offset)
+ {
+@@ -1351,6 +1362,7 @@ static int sc16is7xx_setup_gpio_chip(str
+ s->gpio.parent = dev;
+ s->gpio.label = dev_name(dev);
+ s->gpio.init_valid_mask = sc16is7xx_gpio_init_valid_mask;
++ s->gpio.get_direction = sc16is7xx_gpio_get_direction;
+ s->gpio.direction_input = sc16is7xx_gpio_direction_input;
+ s->gpio.get = sc16is7xx_gpio_get;
+ s->gpio.direction_output = sc16is7xx_gpio_direction_output;
exec-fix-unsigned-loop-counter-wrap-in-transfer_args_to_stack.patch
binfmt_misc-set-have_execfd-only-once-the-interpreter-is-opened.patch
platform-loongarch-laptop-explicitly-reset-bl_powered-state-when-suspend.patch
+rust_binder-only-print-failure-if-error-has-source.patch
+rust-time-fix-as_micros_ceil-to-round-correctly-for-negative-delta.patch
+rust-device-avoid-trailing-in-printing-macros.patch
+rust-allow-suspicious_runtime_symbol_definitions-lint-for-rust-1.98.patch
+rust-allow-clippy-unwrap_or_default-globally.patch
+objtool-rust-add-one-more-noreturn-rust-function-for-rust-1.99.0.patch
+loongarch-fix-address-space-mismatch-in-kexec-command-line-lookup.patch
+loongarch-fix-build-errors-due-to-wrong-instructions-for-32bit.patch
+loongarch-fix-oops-during-single-step-debugging.patch
+loongarch-increase-task_struct_offset-up-to-2040-for-32bit.patch
+loongarch-move-jump_label_init-before-parse_early_param.patch
+loongarch-retrieve-cpu-package-id-from-pptt-when-available.patch
+cdrom-fix-stack-out-of-bounds-read-in-cdromvolctrl.patch
+rhashtable-clear-stale-iter-p-on-table-restart.patch
+firmware-stratix10-svc-fix-memory-leaks-and-list-corruption-bugs.patch
+firmware-stratix10-svc-fix-teardown-order-in-remove-to-prevent-race.patch
+firmware-stratix10-svc-handle-no_response-in-async-poll.patch
+x86-boot-compressed-disable-jump-tables.patch
+comedi-comedi_parport-deal-with-premature-interrupt.patch
+uio_hv_generic-bind-to-fcopy-device-by-default.patch
+serial-sc16is7xx-implement-gpio-get_direction-callback.patch
+serial-8250_mid-fix-null-function-pointer-dereference-on-dnv-icx-d-snr-platforms.patch
+selftests-ntsync-correct-config_ntsync-name.patch
+mei-bus-access-mei_device-under-device_lock-on-cleanup.patch
+intel_th-fix-msc-output-device-reference-leak.patch
+misc-nsm-only-unlock-nsm_dev-on-post-lock-error-paths.patch
+misc-nsm-pin-the-module-while-the-device-is-open.patch
+tracing-delay-module-ref-count-for-enable_event-trigger.patch
+tracing-fix-context-switch-counter-truncation.patch
+tracing-fix-mmiotrace-possible-null-dereferencing-of-hiter-dev.patch
+tracing-fix-resource-leak-on-mmiotrace-trace_pipe-close.patch
+tracing-fix-union-collision-of-module-and-refcnt-for-dynamic-events.patch
+tracing-perf-fix-stale-head-for-perf-syscall-tracing.patch
+tracing-propagate-errors-from-remote-event-bulk-updates.patch
+ublk-wait-on-ublk_dev_ready-instead-of-ub-completion.patch
+tracing-eprobe-fix-exact-system-name-matching-in-eprobe_dyn_event_match.patch
+tracing-probes-avoid-temporary-buffer-truncation-in-trace_probe_match_command_args.patch
+tracing-probes-fix-potential-underflow-in-len_or_zero-macro.patch
+tracing-probes-prevent-out-of-bounds-write-in-__trace_probe_log_err.patch
+tracing-remotes-fix-page_va-access-before-counter-update-in-trace_remote_alloc_buffer.patch
+arm64-make-huge_ptep_get-handled-unaligned-addresses.patch
+arm64-syscall-ensure-saved-x0-is-kept-in-sync-with-tracer-updates.patch
+revert-arm64-syscall-ensure-saved-x0-is-kept-in-sync-with-tracer-updates.patch
+mptcp-decrement-subflows-counter-on-failed-passive-join.patch
+mptcp-fix-build_bug_on-on-legacy-arm-config.patch
+mptcp-fix-stale-skb-sk-reference-on-subflow-close.patch
+mptcp-only-set-data_fin-when-a-mapping-is-present.patch
+mptcp-pm-userspace-fix-use-after-free-in-get_local_id.patch
+selftests-mptcp-userspace_pm-fix-undefined-variable-port.patch
+afs-fix-afs_edit_dir_remove-to-get-not-find-block-0.patch
+btrfs-do-not-try-compression-for-data-reloc-inodes.patch
--- /dev/null
+From e091351b38818ef620d27f44f4bfd625f13afbff Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Fri, 24 Jul 2026 13:24:15 -0400
+Subject: tracing: Delay module ref count for "enable_event" trigger
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit e091351b38818ef620d27f44f4bfd625f13afbff upstream.
+
+Triggers are now delayed from freeing, but can still be triggered until
+after the RCU grace period has ended. The freeing of the enable_event data
+is put into the private_data_free() callback, but the put of the module
+refcount is done immediately.
+
+It is possible that if a module is removed that has an event that would
+enable (or disable) it is still active, it can read the data of the module
+after it is removed causing a use-after-free bug.
+
+Move the trace_event_put_ref() that releases the module into the delayed
+callback so that the module can not be removed until any reference to its
+events are finished.
+
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260724132415.1b5005db@gandalf.local.home
+Reported-by: Sashiko <sashiko-bot@kernel.org>
+Link: https://sashiko.dev/#/patchset/20260724030523.19081-1-devnexen%40gmail.com
+Fixes: 61d445af0a7c ("tracing: Add bulk garbage collection of freeing event_trigger_data")
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_events_trigger.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c
+index 46e60b70a4bb..ad83419cb420 100644
+--- a/kernel/trace/trace_events_trigger.c
++++ b/kernel/trace/trace_events_trigger.c
+@@ -1726,7 +1726,10 @@ int event_enable_trigger_print(struct seq_file *m,
+
+ static void enable_trigger_private_data_free(struct event_trigger_data *data)
+ {
+- kfree(data->private_data);
++ struct enable_trigger_data *enable_data = data->private_data;
++
++ trace_event_put_ref(enable_data->file->event_call);
++ kfree(enable_data);
+ }
+
+ void event_enable_trigger_free(struct event_trigger_data *data)
+@@ -1741,7 +1744,6 @@ void event_enable_trigger_free(struct event_trigger_data *data)
+ /* Remove the SOFT_MODE flag */
+ trace_event_enable_disable(enable_data->file, 0, 1);
+ data->private_data_free = enable_trigger_private_data_free;
+- trace_event_put_ref(enable_data->file->event_call);
+ trigger_data_free(data);
+ }
+ }
+--
+2.55.0
+
--- /dev/null
+From f418d68d71fd4a0a9cef92377bc8c4c3334b5b53 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Mon, 20 Jul 2026 19:12:38 +0900
+Subject: tracing/eprobe: Fix exact system name matching in eprobe_dyn_event_match()
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit f418d68d71fd4a0a9cef92377bc8c4c3334b5b53 upstream.
+
+eprobe_dyn_event_match() checks if the target event system in argv[0]
+matches ep->event_system using strncmp(ep->event_system, argv[0], len).
+However, if ep->event_system is longer than len (e.g. "eprobes" vs
+"ep/event"), strncmp() still returns 0 because the first len characters
+match.
+
+Check that ep->event_system[len] is '\0' to ensure exact system name
+matching.
+
+Link: https://lore.kernel.org/all/178454235856.290363.14872590900774231133.stgit@devnote2/
+
+Fixes: 7d5fda1c841f ("tracing: Fix event probe removal from dynamic events")
+Cc: stable@vger.kernel.org
+Assisted-by: Antigravity:gemini-3.5-flash
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_eprobe.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_eprobe.c
++++ b/kernel/trace/trace_eprobe.c
+@@ -172,7 +172,8 @@ static bool eprobe_dyn_event_match(const
+ if (!slash)
+ return false;
+
+- if (strncmp(ep->event_system, argv[0], slash - argv[0]))
++ if (strncmp(ep->event_system, argv[0], slash - argv[0]) ||
++ ep->event_system[slash - argv[0]] != '\0')
+ return false;
+ if (strcmp(ep->event_name, slash + 1))
+ return false;
--- /dev/null
+From 8f76afb9b114bee1c1251e0e52553e9dc7c59f20 Mon Sep 17 00:00:00 2001
+From: Usama Arif <usama.arif@linux.dev>
+Date: Fri, 17 Jul 2026 10:32:52 -0700
+Subject: tracing: Fix context switch counter truncation
+
+From: Usama Arif <usama.arif@linux.dev>
+
+commit 8f76afb9b114bee1c1251e0e52553e9dc7c59f20 upstream.
+
+trace_user_fault_read() samples nr_context_switches_cpu() before enabling
+preemption and retries the user copy if the counter changes. The helper
+returns unsigned long long because rq->nr_switches is u64, but the saved
+value is unsigned int.
+
+Once a CPU has performed 2^32 context switches, assigning the counter to
+cnt discards its upper bits. The comparison after the copy promotes cnt
+back to unsigned long long, but the lost bits remain zero, so it reports a
+change even when the task was never scheduled out. Every retry then fails
+the same way until the 100-try guard warns and the user copy is abandoned.
+
+This affects long-running systems and workloads with high context-switch
+rates. A CPU switching 1,000 times per second takes about 50 days.
+
+Store the sampled count in unsigned long long so the full value is
+preserved.
+
+Cc: stable@vger.kernel.org
+Fixes: 64cf7d058a00 ("tracing: Have trace_marker use per-cpu data to read user space")
+Link: https://patch.msgid.link/20260717173252.3431565-1-usama.arif@linux.dev
+Reported-by: Breno Leitao <leitao@debian.org>
+Signed-off-by: Usama Arif <usama.arif@linux.dev>
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Reviewed-by: Breno Leitao <leitao@debian.org>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -6191,7 +6191,7 @@ char *trace_user_fault_read(struct trace
+ {
+ int cpu = smp_processor_id();
+ char *buffer = per_cpu_ptr(tinfo->tbuf, cpu)->buf;
+- unsigned int cnt;
++ unsigned long long cnt;
+ int trys = 0;
+ int ret;
+
--- /dev/null
+From 144f29e85702234b23d2a62abf723e6a17eb5427 Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Tue, 21 Jul 2026 21:11:43 -0400
+Subject: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit 144f29e85702234b23d2a62abf723e6a17eb5427 upstream.
+
+If the mmio_pipe_open() fails to find a PCI device, the hiter->dev
+will be assigned to NULL. The mmiotrace read() function dereferences the
+hiter->dev if hiter exists.
+
+Change the test of the read to not only check hiter being NULL, but also
+the hiter->dev before dereferencing it.
+
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260721211143.36dbd559@gandalf.local.home
+Fixes: f984b51e0779 ("ftrace: add mmiotrace plugin")
+Reported-by: Sashiko <sashiko-bot@kernel.org>
+Link: https://sashiko.dev/#/patchset/20260715143604.14481-1-gaikwad.dcg%40gmail.com
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_mmiotrace.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_mmiotrace.c
++++ b/kernel/trace/trace_mmiotrace.c
+@@ -146,7 +146,7 @@ static ssize_t mmio_read(struct trace_it
+ goto print_out;
+ }
+
+- if (!hiter)
++ if (!hiter || !hiter->dev)
+ return 0;
+
+ mmio_print_pcidev(s, hiter->dev);
--- /dev/null
+From c1d87e724ae55e781b7cc7ccafb34d9e668582b2 Mon Sep 17 00:00:00 2001
+From: deepakraog <gaikwad.dcg@gmail.com>
+Date: Wed, 15 Jul 2026 20:06:04 +0530
+Subject: tracing: Fix resource leak on mmiotrace trace_pipe close
+
+From: deepakraog <gaikwad.dcg@gmail.com>
+
+commit c1d87e724ae55e781b7cc7ccafb34d9e668582b2 upstream.
+
+The mmiotrace tracer was added May 12th 2008. At that time, resources
+created in pipe_open() could not be freed because there was not
+pipe_close function pointer of the tracer. The pipe_close function pointer
+was added in December 7th, 2009, but the mmiotrace tracer was not updated.
+
+mmio_pipe_open() allocates a header_iter and takes a pci_dev reference
+when trace_pipe is opened. mmio_close() frees them, but it was only
+wired to the tracer's .close callback.
+
+tracing_release_pipe() invokes .pipe_close, not .close, when the
+trace_pipe file is released. As a result, closing trace_pipe with the
+mmiotrace tracer active leaked the header_iter allocation and left a
+stale pci_dev reference.
+
+Set .pipe_close to mmio_close, matching how function_graph wires both
+callbacks to the same handler.
+
+Note, if the trace_pipe is read to completion, it will clean up the
+resources, but if one were to run:
+
+ # head -n 1 /sys/kernel/tracing/trace_pipe
+ VERSION 20070824
+
+Over and over again, it would trigger a massive leak.
+
+Cc: stable@vger.kernel.org
+Fixes: c521efd1700a8 ("tracing: Add pipe_close interface)
+Link: https://patch.msgid.link/20260715143604.14481-1-gaikwad.dcg@gmail.com
+Signed-off-by: deepakraog <gaikwad.dcg@gmail.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_mmiotrace.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_mmiotrace.c
++++ b/kernel/trace/trace_mmiotrace.c
+@@ -109,7 +109,6 @@ static void mmio_pipe_open(struct trace_
+ iter->private = hiter;
+ }
+
+-/* XXX: This is not called when the pipe is closed! */
+ static void mmio_close(struct trace_iterator *iter)
+ {
+ struct header_iter *hiter = iter->private;
+@@ -279,6 +278,7 @@ static struct tracer mmio_tracer __read_
+ .start = mmio_trace_start,
+ .pipe_open = mmio_pipe_open,
+ .close = mmio_close,
++ .pipe_close = mmio_close,
+ .read = mmio_read,
+ .print_line = mmio_print_line,
+ .noboot = true,
--- /dev/null
+From b4eb07bde606c2096b24252be589e735eff6d413 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Fri, 17 Jul 2026 11:51:49 +0900
+Subject: tracing: Fix union collision of module and refcnt for dynamic events
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit b4eb07bde606c2096b24252be589e735eff6d413 upstream.
+
+In 'struct trace_event_call', the 'module' pointer and the 'refcnt'
+atomic variable share the same memory space in a union. For dynamic
+events, the union member is 'refcnt', which acts as an active
+reference counter.
+
+When a dynamic event (such as kprobe, uprobe, fprobe, eprobe, or
+wprobe) has a non-zero reference count (e.g. due to active event
+triggers or perf attachments), its 'call->module' evaluates to a
+small non-zero integer instead of NULL.
+
+When filtering or setting events for a specific module (e.g., writing
+':mod:<module>' to 'set_event'), the code in
+'__ftrace_set_clr_event_nolock()' and 'update_event_fields()' reads
+'call->module' directly without checking whether the event is dynamic.
+This causes the kernel to treat the small integer (refcnt) as a
+'struct module' pointer, leading to a NULL/invalid pointer dereference
+(Oops) when dereferencing the module name.
+
+Fix this by ensuring that the 'TRACE_EVENT_FL_DYNAMIC' flag is checked
+before treating 'call->module' as a valid pointer in these code paths.
+
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/178425670947.84440.11344393611899824907.stgit@devnote2
+Fixes: 4c86bc531e60 ("tracing: Add :mod: command to enabled module events")
+Assisted-by: Antigravity:gemini-3.5-flash
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_events.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_events.c
++++ b/kernel/trace/trace_events.c
+@@ -1350,7 +1350,9 @@ __ftrace_set_clr_event_nolock(struct tra
+ call = file->event_call;
+
+ /* If a module is specified, skip events that are not that module */
+- if (module && (!call->module || strcmp(module_name(call->module), module)))
++ if (module &&
++ ((call->flags & TRACE_EVENT_FL_DYNAMIC) ||
++ !call->module || strcmp(module_name(call->module), module)))
+ continue;
+
+ name = trace_event_name(call);
--- /dev/null
+From 2c2b322acdcc78575b8d6afa64a085cf92e03c12 Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Fri, 24 Jul 2026 19:32:10 -0400
+Subject: tracing: perf: Fix stale head for perf syscall tracing
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit 2c2b322acdcc78575b8d6afa64a085cf92e03c12 upstream.
+
+The code that can read the user space parameters of a system call may
+enable preemption and migrate. The head of the per CPU perf events list
+may be pointing to the wrong CPU event if the code migrates the task.
+
+Reassign the head pointer if the system call event called the code that
+may have caused a migration.
+
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260724193210.03fae1d6@gandalf.local.home
+Reported-by: Sashiko <>
+Link: https://sashiko.dev/#/patchset/20260717173252.3431565-1-usama.arif%40linux.dev
+Fixes: edca33a56297d ("tracing: Fix failure to read user space from system call trace events")
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_syscalls.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/kernel/trace/trace_syscalls.c
++++ b/kernel/trace/trace_syscalls.c
+@@ -1436,6 +1436,11 @@ static void perf_syscall_enter(void *ign
+ if (syscall_get_data(sys_data, args, &user_ptr,
+ &size, user_sizes, &uargs, buf_size) < 0)
+ return;
++
++ /* The above may have caused a migration */
++ head = this_cpu_ptr(sys_data->enter_event->perf_events);
++ if (hlist_empty(head))
++ return;
+ }
+
+ head = this_cpu_ptr(sys_data->enter_event->perf_events);
--- /dev/null
+From 15f197856d68882af9416fc97516bb55079b7677 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Mon, 20 Jul 2026 19:12:10 +0900
+Subject: tracing/probes: Avoid temporary buffer truncation in trace_probe_match_command_args()
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit 15f197856d68882af9416fc97516bb55079b7677 upstream.
+
+In trace_probe_match_command_args(), a stack buffer buf[MAX_ARGSTR_LEN + 1]
+(256 bytes) is used to format "<name>=<comm>". However, since name can
+be up to 32 bytes (MAX_ARG_NAME_LEN) and comm up to 255 bytes
+(MAX_ARGSTR_LEN), the formatted string can exceed 256 bytes and get
+truncated by snprintf(), causing spurious argument matching failures.
+
+Instead of formatting into a temporary buffer on stack, compare the
+argument name, the '=' delimiter, and the comm expression directly.
+
+Link: https://lore.kernel.org/all/178454233010.290363.10428767141343428804.stgit@devnote2/
+
+Fixes: eb5bf81330a7 ("tracing/kprobe: Add per-probe delete from event")
+Cc: stable@vger.kernel.org
+Assisted-by: Antigravity:gemini-3.5-flash
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_probe.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/kernel/trace/trace_probe.c
++++ b/kernel/trace/trace_probe.c
+@@ -2344,16 +2344,17 @@ int trace_probe_compare_arg_type(struct
+ bool trace_probe_match_command_args(struct trace_probe *tp,
+ int argc, const char **argv)
+ {
+- char buf[MAX_ARGSTR_LEN + 1];
+ int i;
+
+ if (tp->nr_args < argc)
+ return false;
+
+ for (i = 0; i < argc; i++) {
+- snprintf(buf, sizeof(buf), "%s=%s",
+- tp->args[i].name, tp->args[i].comm);
+- if (strcmp(buf, argv[i]))
++ int len = strlen(tp->args[i].name);
++
++ if (strncmp(argv[i], tp->args[i].name, len) ||
++ argv[i][len] != '=' ||
++ strcmp(argv[i] + len + 1, tp->args[i].comm))
+ return false;
+ }
+ return true;
--- /dev/null
+From 8ce20bfba48902e1382187cd1a852f7cf3a1e739 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Mon, 20 Jul 2026 19:12:29 +0900
+Subject: tracing/probes: Fix potential underflow in LEN_OR_ZERO macro
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit 8ce20bfba48902e1382187cd1a852f7cf3a1e739 upstream.
+
+In __set_print_fmt(), LEN_OR_ZERO is defined as (len ? len - pos : 0).
+If len is non-zero but smaller than pos, len - pos evaluates to a negative
+integer. When passed as a size argument to snprintf(), this negative value
+is cast to a large unsigned size_t, bypassing buffer size limits.
+
+Ensure len > pos before subtracting to avoid integer underflow.
+
+Link: https://lore.kernel.org/all/178454234934.290363.15247317871499514139.stgit@devnote2/
+
+Fixes: 5bf652aaf46c ("tracing/probes: Integrate duplicate set_print_fmt()")
+Cc: stable@vger.kernel.org
+Assisted-by: Antigravity:gemini-3.5-flash
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_probe.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_probe.c
++++ b/kernel/trace/trace_probe.c
+@@ -2018,7 +2018,7 @@ int traceprobe_update_arg(struct probe_a
+ }
+
+ /* When len=0, we just calculate the needed length */
+-#define LEN_OR_ZERO (len ? len - pos : 0)
++#define LEN_OR_ZERO (len > pos ? len - pos : 0)
+ static int __set_print_fmt(struct trace_probe *tp, char *buf, int len,
+ enum probe_print_type ptype)
+ {
--- /dev/null
+From a9d6fb284039a5d3858a1d9f9a0d7e46cfb7c2d4 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Mon, 20 Jul 2026 19:12:20 +0900
+Subject: tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit a9d6fb284039a5d3858a1d9f9a0d7e46cfb7c2d4 upstream.
+
+If trace_probe_log.argc is 0 in __trace_probe_log_err(), the loop
+constructing the command string will not execute and p will remain equal to
+command. Writing to *(p - 1) will cause an out-of-bounds access before
+command. This should not happen, but better to be treated.
+
+Reject if trace_probe_log.argc is 0.
+
+Link: https://lore.kernel.org/all/178454233992.290363.18323091580600697731.stgit@devnote2/
+
+Fixes: ab105a4fb894 ("tracing: Use tracing error_log with probe events")
+Cc: stable@vger.kernel.org
+Assisted-by: Antigravity:gemini-3.5-flash
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_probe.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_probe.c
++++ b/kernel/trace/trace_probe.c
+@@ -188,7 +188,7 @@ void __trace_probe_log_err(int offset, i
+
+ lockdep_assert_held(&dyn_event_ops_mutex);
+
+- if (!trace_probe_log.argv)
++ if (!trace_probe_log.argv || !trace_probe_log.argc)
+ return;
+
+ /* Recalculate the length and allocate buffer */
--- /dev/null
+From 655111f878a455f724e20122929cf2afa52b76e4 Mon Sep 17 00:00:00 2001
+From: Jackie Liu <liuyun01@kylinos.cn>
+Date: Wed, 15 Jul 2026 15:44:55 +0800
+Subject: tracing: Propagate errors from remote event bulk updates
+
+From: Jackie Liu <liuyun01@kylinos.cn>
+
+commit 655111f878a455f724e20122929cf2afa52b76e4 upstream.
+
+remote_events_dir_enable_write() ignores the return value from
+trace_remote_enable_event(). If a remote rejects an event state change,
+the write therefore reports success even though the affected event remains
+in its previous state.
+
+Keep trying all events, but retain and return the first error. This matches
+__ftrace_set_clr_event_nolock(), which permits partial updates while
+notifying userspace when an operation fails.
+
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260715074455.3897-1-liu.yun@linux.dev
+Fixes: 775cb093bc50 ("tracing: Add events/ root files to trace remotes")
+Assisted-by: Codex:gpt-5.6-sol
+Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
+Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_remote.c | 13 ++++++++++++-
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_remote.c
++++ b/kernel/trace/trace_remote.c
+@@ -1150,10 +1150,21 @@ static ssize_t remote_events_dir_enable_
+
+ for (i = 0; i < remote->nr_events; i++) {
+ struct remote_event *evt = &remote->events[i];
++ int eret;
+
+- trace_remote_enable_event(remote, evt, enable);
++ eret = trace_remote_enable_event(remote, evt, enable);
++ /*
++ * Save the first error and return that. Some events
++ * may still have been enabled, but let the user
++ * know that something went wrong.
++ */
++ if (!ret && eret)
++ ret = eret;
+ }
+
++ if (ret)
++ return ret;
++
+ return count;
+ }
+
--- /dev/null
+From 94b83ff0c0a69e42f403b59918529fbca2a89daf Mon Sep 17 00:00:00 2001
+From: Fuad Tabba <fuad.tabba@linux.dev>
+Date: Mon, 13 Jul 2026 08:28:23 +0100
+Subject: tracing/remotes: Fix page_va[] access before counter update in trace_remote_alloc_buffer()
+
+From: Fuad Tabba <fuad.tabba@linux.dev>
+
+commit 94b83ff0c0a69e42f403b59918529fbca2a89daf upstream.
+
+page_va[] is annotated __counted_by(nr_page_va), so nr_page_va must
+cover an index before that element is accessed. The allocation loop
+writes page_va[id] while nr_page_va is still id and increments it only
+afterwards, so every write is one element past the declared count.
+
+The store is out of bounds with respect to the annotation: a build with
+CONFIG_UBSAN_BOUNDS on a toolchain that honours __counted_by
+(clang >= 20.1, gcc >= 15.1) flags it as an array-index overflow.
+
+Increment nr_page_va before writing the element it now covers. A failed
+allocation then leaves the slot counted but NULL; the error path frees
+it with free_page(0), which is a no-op.
+
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20260713072823.2668323-1-fuad.tabba@linux.dev
+Fixes: 96e43537af546 ("tracing: Introduce trace remotes")
+Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
+Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
+Tested-by: Vincent Donnefort <vdonnefort@google.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_remote.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/kernel/trace/trace_remote.c
++++ b/kernel/trace/trace_remote.c
+@@ -1004,11 +1004,10 @@ int trace_remote_alloc_buffer(struct tra
+ desc->nr_cpus++;
+
+ for (id = 0; id < nr_pages; id++) {
++ rb_desc->nr_page_va++;
+ rb_desc->page_va[id] = (unsigned long)__get_free_page(GFP_KERNEL);
+ if (!rb_desc->page_va[id])
+ goto err;
+-
+- rb_desc->nr_page_va++;
+ }
+ rb_desc = __next_ring_buffer_desc(rb_desc);
+ }
--- /dev/null
+From 432a9b2780c0a01caf547bd1fc2fcf28aeb8d173 Mon Sep 17 00:00:00 2001
+From: Ming Lei <tom.leiming@gmail.com>
+Date: Sun, 19 Jul 2026 08:45:40 -0500
+Subject: ublk: wait on ublk_dev_ready() instead of ub->completion
+
+From: Ming Lei <tom.leiming@gmail.com>
+
+commit 432a9b2780c0a01caf547bd1fc2fcf28aeb8d173 upstream.
+
+ub->completion is only re-armed by a successful START_USER_RECOVERY. If
+the ublk server sends END_USER_RECOVERY without one - e.g. its START
+failed with -EBUSY and the error was ignored - the wait is satisfied by
+the stale completion of the previous recovery cycle, and the device is
+marked LIVE and the requeue list kicked while the FETCH stream is still
+running and ubq->canceling is still set. The kick redispatches a
+previously requeued request, __ublk_queue_rq_common() sees ->canceling
+and parks it again via __ublk_abort_rq(), and after the last FETCH
+clears ->canceling nothing ever kicks the requeue list again: the
+request is stranded there while holding its tag. If it is the flush
+machinery's flush_rq, every subsequent fsync piles up in uninterruptible
+sleep and teardown hangs on tag draining. This matches a report of a
+lost PREFLUSH with ext4 on top of ublk after daemon crash recovery.
+
+ub->completion is an edge-triggered latch used as a proxy for the level
+condition "every queue has fetched all I/O commands", which can regress
+(F_BATCH's UNPREP, daemon death) and whose re-arm can be skipped. Drop
+it and wait on the real condition instead: the new helper
+ublk_wait_dev_ready_and_lock() waits on ublk_dev_ready() via
+wait_var_event_interruptible(), woken from ublk_mark_io_ready(), then
+re-checks it under ub->mutex, waiting again on regression, and returns
+with the mutex held and readiness guaranteed.
+
+Readiness becomes true in the same ub->mutex critical section that
+clears the last queue's ->canceling, so END_USER_RECOVERY marks the
+device LIVE and kicks the requeue list strictly after ->canceling
+clears. The wait stays interruptible, so a server whose daemon died can
+still be signalled out. For ublk_ctrl_start_dev() this replaces the
+fail-fast -EINVAL on an F_BATCH ready->UNPREP regression with waiting
+until the device is ready again.
+
+Reported-by: George Salisbury <gsalisbury@apnic.net>
+Fixes: 728cbac5fe21 ("ublk: move device reset into ublk_ch_release()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ming Lei <tom.leiming@gmail.com>
+Link: https://patch.msgid.link/20260719134540.120269-1-tom.leiming@gmail.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/block/ublk_drv.c | 47 ++++++++++++++++++++++++++++++-----------------
+ 1 file changed, 30 insertions(+), 17 deletions(-)
+
+--- a/drivers/block/ublk_drv.c
++++ b/drivers/block/ublk_drv.c
+@@ -19,6 +19,7 @@
+ #include <linux/errno.h>
+ #include <linux/major.h>
+ #include <linux/wait.h>
++#include <linux/wait_bit.h>
+ #include <linux/blkdev.h>
+ #include <linux/init.h>
+ #include <linux/swap.h>
+@@ -26,7 +27,6 @@
+ #include <linux/compat.h>
+ #include <linux/mutex.h>
+ #include <linux/writeback.h>
+-#include <linux/completion.h>
+ #include <linux/highmem.h>
+ #include <linux/sysfs.h>
+ #include <linux/miscdevice.h>
+@@ -327,7 +327,6 @@ struct ublk_device {
+
+ struct ublk_params params;
+
+- struct completion completion;
+ u32 nr_queue_ready;
+ bool unprivileged_daemons;
+ struct mutex cancel_mutex;
+@@ -3058,12 +3057,12 @@ static void ublk_mark_io_ready(struct ub
+ if (ublk_dev_ready(ub)) {
+ /*
+ * All queues ready - clear device-level canceling flag
+- * and complete the recovery/initialization.
++ * and wake ublk_dev_ready() waiters.
+ */
+ mutex_lock(&ub->cancel_mutex);
+ ub->canceling = false;
+ mutex_unlock(&ub->cancel_mutex);
+- complete_all(&ub->completion);
++ wake_up_var(&ub->nr_queue_ready);
+ }
+ }
+
+@@ -4266,7 +4265,6 @@ static int ublk_init_queues(struct ublk_
+ goto fail;
+ }
+
+- init_completion(&ub->completion);
+ return 0;
+
+ fail:
+@@ -4410,6 +4408,26 @@ static bool ublk_validate_user_pid(struc
+ return ub->ublksrv_tgid == ublksrv_pid;
+ }
+
++/*
++ * Wait until all queues have fetched their I/O commands, and return with
++ * ub->mutex held and readiness guaranteed: then every queue's ->canceling
++ * is cleared. Ready may regress between wakeup and mutex_lock() (F_BATCH
++ * UNPREP, daemon death), so re-check it under the mutex and wait again.
++ */
++static int ublk_wait_dev_ready_and_lock(struct ublk_device *ub)
++{
++ while (true) {
++ if (wait_var_event_interruptible(&ub->nr_queue_ready,
++ ublk_dev_ready(ub)))
++ return -EINTR;
++
++ mutex_lock(&ub->mutex);
++ if (ublk_dev_ready(ub))
++ return 0;
++ mutex_unlock(&ub->mutex);
++ }
++}
++
+ static int ublk_ctrl_start_dev(struct ublk_device *ub,
+ const struct ublksrv_ctrl_cmd *header)
+ {
+@@ -4492,15 +4510,10 @@ static int ublk_ctrl_start_dev(struct ub
+ };
+ }
+
+- if (wait_for_completion_interruptible(&ub->completion) != 0)
++ if (ublk_wait_dev_ready_and_lock(ub))
+ return -EINTR;
+
+- if (!ublk_validate_user_pid(ub, ublksrv_pid))
+- return -EINVAL;
+-
+- mutex_lock(&ub->mutex);
+- /* device may become not ready in case of F_BATCH */
+- if (!ublk_dev_ready(ub)) {
++ if (!ublk_validate_user_pid(ub, ublksrv_pid)) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+@@ -5064,7 +5077,6 @@ static int ublk_ctrl_start_recovery(stru
+ goto out_unlock;
+ }
+ pr_devel("%s: start recovery for dev id %d\n", __func__, ub->ub_number);
+- init_completion(&ub->completion);
+ ret = 0;
+ out_unlock:
+ mutex_unlock(&ub->mutex);
+@@ -5080,16 +5092,17 @@ static int ublk_ctrl_end_recovery(struct
+ pr_devel("%s: Waiting for all FETCH_REQs, dev id %d...\n", __func__,
+ header->dev_id);
+
+- if (wait_for_completion_interruptible(&ub->completion))
++ if (ublk_wait_dev_ready_and_lock(ub))
+ return -EINTR;
+
+ pr_devel("%s: All FETCH_REQs received, dev id %d\n", __func__,
+ header->dev_id);
+
+- if (!ublk_validate_user_pid(ub, ublksrv_pid))
+- return -EINVAL;
++ if (!ublk_validate_user_pid(ub, ublksrv_pid)) {
++ ret = -EINVAL;
++ goto out_unlock;
++ }
+
+- mutex_lock(&ub->mutex);
+ if (ublk_nosrv_should_stop_dev(ub))
+ goto out_unlock;
+
--- /dev/null
+From 87d3621ccc63b3999d756bb59f0cedd738c28eb3 Mon Sep 17 00:00:00 2001
+From: Ben Hutchings <benh@debian.org>
+Date: Mon, 25 May 2026 14:04:22 +0200
+Subject: uio_hv_generic: Bind to FCopy device by default
+
+From: Ben Hutchings <benh@debian.org>
+
+commit 87d3621ccc63b3999d756bb59f0cedd738c28eb3 upstream.
+
+The Hyper-V kernel-mode fcopy driver was removed in 6.10 and the new
+fcopy daemon requires this uio driver to function. However, by
+default the driver does not bind to any devices, and must be
+configured through the sysfs "new_id" file.
+
+Since the FCopy device is now only usable through this driver, add its
+ID to the driver's ID table so that the daemon will work "out of the
+box".
+
+Signed-off-by: Ben Hutchings <benh@debian.org>
+Fixes: ec314f61e4fc ("Drivers: hv: Remove fcopy driver")
+Cc: stable <stable@kernel.org>
+Link: https://patch.msgid.link/ahQ6xuhSReidmN-3@decadent.org.uk
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/uio/uio_hv_generic.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/uio/uio_hv_generic.c
++++ b/drivers/uio/uio_hv_generic.c
+@@ -396,9 +396,15 @@ hv_uio_remove(struct hv_device *dev)
+ vmbus_free_ring(dev->channel);
+ }
+
++static const struct hv_vmbus_device_id hv_uio_id_table[] = {
++ { HV_FCOPY_GUID },
++ {}
++};
++MODULE_DEVICE_TABLE(vmbus, hv_uio_id_table);
++
+ static struct hv_driver hv_uio_drv = {
+ .name = "uio_hv_generic",
+- .id_table = NULL, /* only dynamic id's */
++ .id_table = hv_uio_id_table,
+ .probe = hv_uio_probe,
+ .remove = hv_uio_remove,
+ };
--- /dev/null
+From 4a9ec5ec9555ad62dc5b81a37ac946025c2ea002 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Wed, 22 Jul 2026 17:09:43 -0700
+Subject: x86/boot/compressed: Disable jump tables
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit 4a9ec5ec9555ad62dc5b81a37ac946025c2ea002 upstream.
+
+After a recent upstream LLVM change to start generating jump and lookup
+tables in switch statements in more instances [1], linking the
+compressed x86 boot image when CONFIG_KERNEL_ZSTD is enabled fails with:
+
+ ld.lld: error: Unexpected run-time relocations (.rela) detected!
+
+Dumping the relocations in misc.o, which is the only file influenced by
+CONFIG_KERNEL_ZSTD in the decompressor, shows dynamic relocations to
+some string constants, which correspond to the string literals in the
+switch statement in handle_zstd_error():
+
+ Relocation section '.rela.data.rel.ro' at offset 0x277b0 contains 31 entries:
+ Offset Info Type Symbol's Value Symbol's Name + Addend
+ 0000000000000000 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 73a
+ 0000000000000008 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e
+ 0000000000000010 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e
+ 0000000000000018 0000006600000001 R_X86_64_64 0000000000000000 .rodata.str1.1 + 78e
+ ...
+
+This optimization is problematic for the decompressor environment, as it
+is built as -fPIE without any explicit absolute references (as described
+at the top of misc.c) while not applying any dynamic relocations, hence
+the linker assertion. To opt out of this optimization, which is of
+little value in this special early boot code, and to mirror the other
+x86 startup code in arch/x86/boot/startup, disable jump tables in the
+decompressor.
+
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Acked-by: Ard Biesheuvel <ardb@kernel.org>
+Cc: Bill Wendling <morbo@google.com>
+Cc: Justin Stitt <justinstitt@google.com>
+Cc: Nick Desaulniers <ndesaulniers@google.com>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://github.com/llvm/llvm-project/commit/fa02a6ed66b1700c996b49c96c6bc0eb014c9518 [1]
+Link: https://patch.msgid.link/20260722-x86-boot-compressed-disable-jt-clang-v2-1-7373d38482fb@kernel.org
+Closes: https://github.com/ClangBuiltLinux/linux/issues/2165
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/boot/compressed/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/boot/compressed/Makefile
++++ b/arch/x86/boot/compressed/Makefile
+@@ -27,6 +27,7 @@ targets := vmlinux vmlinux.bin vmlinux.b
+ KBUILD_CFLAGS := -m$(BITS) -O2 $(CLANG_FLAGS)
+ KBUILD_CFLAGS += $(CC_FLAGS_DIALECT)
+ KBUILD_CFLAGS += -fno-strict-aliasing -fPIE
++KBUILD_CFLAGS += -fno-jump-tables
+ KBUILD_CFLAGS += -Wundef
+ KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
+ cflags-$(CONFIG_X86_32) := -march=i386
projects / thirdparty / kernel / stable-queue.git / commitdiff
