]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
6.1-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 5 Jan 2026 13:09:54 +0000 (14:09 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 5 Jan 2026 13:09:54 +0000 (14:09 +0100)
added patches:
compiler_types.h-add-auto-as-a-macro-for-__auto_type.patch
e1000-fix-oob-in-e1000_tbi_should_accept.patch
fjes-add-missing-iounmap-in-fjes_hw_init.patch
idr-fix-idr_alloc-returning-an-id-out-of-range.patch
kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch
loongarch-bpf-sign-extend-kfunc-call-arguments.patch
loongarch-bpf-zero-extend-bpf_tail_call-index.patch
net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch
net-nfc-fix-deadlock-between-nfc_unregister_device-and-rfkill_fop_write.patch
net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch
nfsd-drop-the-client-reference-in-client_states_open.patch
rdma-cm-fix-leaking-the-multicast-gid-table-reference.patch
rdma-core-check-for-the-presence-of-ls_nla_type_dgid-correctly.patch

14 files changed:
queue-6.1/compiler_types.h-add-auto-as-a-macro-for-__auto_type.patch [new file with mode: 0644]
queue-6.1/e1000-fix-oob-in-e1000_tbi_should_accept.patch [new file with mode: 0644]
queue-6.1/fjes-add-missing-iounmap-in-fjes_hw_init.patch [new file with mode: 0644]
queue-6.1/idr-fix-idr_alloc-returning-an-id-out-of-range.patch [new file with mode: 0644]
queue-6.1/kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch [new file with mode: 0644]
queue-6.1/loongarch-bpf-sign-extend-kfunc-call-arguments.patch [new file with mode: 0644]
queue-6.1/loongarch-bpf-zero-extend-bpf_tail_call-index.patch [new file with mode: 0644]
queue-6.1/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch [new file with mode: 0644]
queue-6.1/net-nfc-fix-deadlock-between-nfc_unregister_device-and-rfkill_fop_write.patch [new file with mode: 0644]
queue-6.1/net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch [new file with mode: 0644]
queue-6.1/nfsd-drop-the-client-reference-in-client_states_open.patch [new file with mode: 0644]
queue-6.1/rdma-cm-fix-leaking-the-multicast-gid-table-reference.patch [new file with mode: 0644]
queue-6.1/rdma-core-check-for-the-presence-of-ls_nla_type_dgid-correctly.patch [new file with mode: 0644]
queue-6.1/series

diff --git a/queue-6.1/compiler_types.h-add-auto-as-a-macro-for-__auto_type.patch b/queue-6.1/compiler_types.h-add-auto-as-a-macro-for-__auto_type.patch
new file mode 100644 (file)
index 0000000..b1fe41d
--- /dev/null
@@ -0,0 +1,58 @@
+From 2fb6915fa22dc5524d704afba58a13305dd9f533 Mon Sep 17 00:00:00 2001
+From: "H. Peter Anvin" <hpa@zytor.com>
+Date: Fri, 18 Jul 2025 11:35:00 -0700
+Subject: compiler_types.h: add "auto" as a macro for "__auto_type"
+
+From: H. Peter Anvin <hpa@zytor.com>
+
+commit 2fb6915fa22dc5524d704afba58a13305dd9f533 upstream.
+
+"auto" was defined as a keyword back in the K&R days, but as a storage
+type specifier.  No one ever used it, since it was and is the default
+storage type for local variables.
+
+C++11 recycled the keyword to allow a type to be declared based on the
+type of an initializer.  This was finally adopted into standard C in
+C23.
+
+gcc and clang provide the "__auto_type" alias keyword as an extension
+for pre-C23, however, there is no reason to pollute the bulk of the
+source base with this temporary keyword; instead define "auto" as a
+macro unless the compiler is running in C23+ mode.
+
+This macro is added in <linux/compiler_types.h> because that header is
+included in some of the tools headers, wheres <linux/compiler.h> is
+not as it has a bunch of very kernel-specific things in it.
+
+[ Cc: stable to reduce potential backporting burden. ]
+
+Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
+Acked-by: Miguel Ojeda <ojeda@kernel.org>
+Cc: <stable@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/compiler_types.h |   13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/include/linux/compiler_types.h
++++ b/include/linux/compiler_types.h
+@@ -5,6 +5,19 @@
+ #ifndef __ASSEMBLY__
+ /*
++ * C23 introduces "auto" as a standard way to define type-inferred
++ * variables, but "auto" has been a (useless) keyword even since K&R C,
++ * so it has always been "namespace reserved."
++ *
++ * Until at some future time we require C23 support, we need the gcc
++ * extension __auto_type, but there is no reason to put that elsewhere
++ * in the source code.
++ */
++#if __STDC_VERSION__ < 202311L
++# define auto __auto_type
++#endif
++
++/*
+  * Skipped when running bindgen due to a libclang issue;
+  * see https://github.com/rust-lang/rust-bindgen/issues/2244.
+  */
diff --git a/queue-6.1/e1000-fix-oob-in-e1000_tbi_should_accept.patch b/queue-6.1/e1000-fix-oob-in-e1000_tbi_should_accept.patch
new file mode 100644 (file)
index 0000000..10080b8
--- /dev/null
@@ -0,0 +1,123 @@
+From 9c72a5182ed92904d01057f208c390a303f00a0f Mon Sep 17 00:00:00 2001
+From: Guangshuo Li <lgs201920130244@gmail.com>
+Date: Mon, 1 Dec 2025 11:40:58 +0800
+Subject: e1000: fix OOB in e1000_tbi_should_accept()
+
+From: Guangshuo Li <lgs201920130244@gmail.com>
+
+commit 9c72a5182ed92904d01057f208c390a303f00a0f upstream.
+
+In e1000_tbi_should_accept() we read the last byte of the frame via
+'data[length - 1]' to evaluate the TBI workaround. If the descriptor-
+reported length is zero or larger than the actual RX buffer size, this
+read goes out of bounds and can hit unrelated slab objects. The issue
+is observed from the NAPI receive path (e1000_clean_rx_irq):
+
+==================================================================
+BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790
+Read of size 1 at addr ffff888014114e54 by task sshd/363
+
+CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
+Call Trace:
+ <IRQ>
+ dump_stack_lvl+0x5a/0x74
+ print_address_description+0x7b/0x440
+ print_report+0x101/0x200
+ kasan_report+0xc1/0xf0
+ e1000_tbi_should_accept+0x610/0x790
+ e1000_clean_rx_irq+0xa8c/0x1110
+ e1000_clean+0xde2/0x3c10
+ __napi_poll+0x98/0x380
+ net_rx_action+0x491/0xa20
+ __do_softirq+0x2c9/0x61d
+ do_softirq+0xd1/0x120
+ </IRQ>
+ <TASK>
+ __local_bh_enable_ip+0xfe/0x130
+ ip_finish_output2+0x7d5/0xb00
+ __ip_queue_xmit+0xe24/0x1ab0
+ __tcp_transmit_skb+0x1bcb/0x3340
+ tcp_write_xmit+0x175d/0x6bd0
+ __tcp_push_pending_frames+0x7b/0x280
+ tcp_sendmsg_locked+0x2e4f/0x32d0
+ tcp_sendmsg+0x24/0x40
+ sock_write_iter+0x322/0x430
+ vfs_write+0x56c/0xa60
+ ksys_write+0xd1/0x190
+ do_syscall_64+0x43/0x90
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+RIP: 0033:0x7f511b476b10
+Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24
+RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
+RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10
+RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003
+RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00
+R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000
+R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003
+ </TASK>
+Allocated by task 1:
+ __kasan_krealloc+0x131/0x1c0
+ krealloc+0x90/0xc0
+ add_sysfs_param+0xcb/0x8a0
+ kernel_add_sysfs_param+0x81/0xd4
+ param_sysfs_builtin+0x138/0x1a6
+ param_sysfs_init+0x57/0x5b
+ do_one_initcall+0x104/0x250
+ do_initcall_level+0x102/0x132
+ do_initcalls+0x46/0x74
+ kernel_init_freeable+0x28f/0x393
+ kernel_init+0x14/0x1a0
+ ret_from_fork+0x22/0x30
+The buggy address belongs to the object at ffff888014114000
+ which belongs to the cache kmalloc-2k of size 2048
+The buggy address is located 1620 bytes to the right of
+ 2048-byte region [ffff888014114000, ffff888014114800]
+The buggy address belongs to the physical page:
+page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110
+head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0
+flags: 0x100000000010200(slab|head|node=0|zone=1)
+raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000
+raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
+page dumped because: kasan: bad access detected
+==================================================================
+
+This happens because the TBI check unconditionally dereferences the last
+byte without validating the reported length first:
+
+       u8 last_byte = *(data + length - 1);
+
+Fix by rejecting the frame early if the length is zero, or if it exceeds
+adapter->rx_buffer_len. This preserves the TBI workaround semantics for
+valid frames and prevents touching memory beyond the RX buffer.
+
+Fixes: 2037110c96d5 ("e1000: move tbi workaround code into helper function")
+Cc: stable@vger.kernel.org
+Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/e1000/e1000_main.c |   10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
++++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
+@@ -4091,7 +4091,15 @@ static bool e1000_tbi_should_accept(stru
+                                   u32 length, const u8 *data)
+ {
+       struct e1000_hw *hw = &adapter->hw;
+-      u8 last_byte = *(data + length - 1);
++      u8 last_byte;
++
++      /* Guard against OOB on data[length - 1] */
++      if (unlikely(!length))
++              return false;
++      /* Upper bound: length must not exceed rx_buffer_len */
++      if (unlikely(length > adapter->rx_buffer_len))
++              return false;
++      last_byte = *(data + length - 1);
+       if (TBI_ACCEPT(hw, status, errors, length, last_byte)) {
+               unsigned long irq_flags;
diff --git a/queue-6.1/fjes-add-missing-iounmap-in-fjes_hw_init.patch b/queue-6.1/fjes-add-missing-iounmap-in-fjes_hw_init.patch
new file mode 100644 (file)
index 0000000..6428d99
--- /dev/null
@@ -0,0 +1,60 @@
+From 15ef641a0c6728d25a400df73922e80ab2cf029c Mon Sep 17 00:00:00 2001
+From: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
+Date: Thu, 11 Dec 2025 15:37:56 +0800
+Subject: fjes: Add missing iounmap in fjes_hw_init()
+
+From: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
+
+commit 15ef641a0c6728d25a400df73922e80ab2cf029c upstream.
+
+In error paths, add fjes_hw_iounmap() to release the
+resource acquired by fjes_hw_iomap(). Add a goto label
+to do so.
+
+Fixes: 8cdc3f6c5d22 ("fjes: Hardware initialization routine")
+Cc: stable@vger.kernel.org
+Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
+Signed-off-by: Simon Horman <horms@kernel.org>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://patch.msgid.link/20251211073756.101824-1-lihaoxiang@isrc.iscas.ac.cn
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/fjes/fjes_hw.c |   12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/fjes/fjes_hw.c
++++ b/drivers/net/fjes/fjes_hw.c
+@@ -334,7 +334,7 @@ int fjes_hw_init(struct fjes_hw *hw)
+       ret = fjes_hw_reset(hw);
+       if (ret)
+-              return ret;
++              goto err_iounmap;
+       fjes_hw_set_irqmask(hw, REG_ICTL_MASK_ALL, true);
+@@ -347,8 +347,10 @@ int fjes_hw_init(struct fjes_hw *hw)
+       hw->max_epid = fjes_hw_get_max_epid(hw);
+       hw->my_epid = fjes_hw_get_my_epid(hw);
+-      if ((hw->max_epid == 0) || (hw->my_epid >= hw->max_epid))
+-              return -ENXIO;
++      if ((hw->max_epid == 0) || (hw->my_epid >= hw->max_epid)) {
++              ret = -ENXIO;
++              goto err_iounmap;
++      }
+       ret = fjes_hw_setup(hw);
+@@ -356,6 +358,10 @@ int fjes_hw_init(struct fjes_hw *hw)
+       hw->hw_info.trace_size = FJES_DEBUG_BUFFER_SIZE;
+       return ret;
++
++err_iounmap:
++      fjes_hw_iounmap(hw);
++      return ret;
+ }
+ void fjes_hw_exit(struct fjes_hw *hw)
diff --git a/queue-6.1/idr-fix-idr_alloc-returning-an-id-out-of-range.patch b/queue-6.1/idr-fix-idr_alloc-returning-an-id-out-of-range.patch
new file mode 100644 (file)
index 0000000..eed5f4b
--- /dev/null
@@ -0,0 +1,80 @@
+From c6e8e595a0798ad67da0f7bebaf69c31ef70dfff Mon Sep 17 00:00:00 2001
+From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
+Date: Fri, 28 Nov 2025 16:18:32 +0000
+Subject: idr: fix idr_alloc() returning an ID out of range
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Matthew Wilcox (Oracle) <willy@infradead.org>
+
+commit c6e8e595a0798ad67da0f7bebaf69c31ef70dfff upstream.
+
+If you use an IDR with a non-zero base, and specify a range that lies
+entirely below the base, 'max - base' becomes very large and
+idr_get_free() can return an ID that lies outside of the requested range.
+
+Link: https://lkml.kernel.org/r/20251128161853.3200058-1-willy@infradead.org
+Fixes: 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
+Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Reported-by: Jan Sokolowski <jan.sokolowski@intel.com>
+Reported-by: Koen Koning <koen.koning@intel.com>
+Reported-by: Peter Senna Tschudin <peter.senna@linux.intel.com>
+Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6449
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ lib/idr.c                           |    2 ++
+ tools/testing/radix-tree/idr-test.c |   21 +++++++++++++++++++++
+ 2 files changed, 23 insertions(+)
+
+--- a/lib/idr.c
++++ b/lib/idr.c
+@@ -40,6 +40,8 @@ int idr_alloc_u32(struct idr *idr, void
+       if (WARN_ON_ONCE(!(idr->idr_rt.xa_flags & ROOT_IS_IDR)))
+               idr->idr_rt.xa_flags |= IDR_RT_MARKER;
++      if (max < base)
++              return -ENOSPC;
+       id = (id < base) ? 0 : id - base;
+       radix_tree_iter_init(&iter, id);
+--- a/tools/testing/radix-tree/idr-test.c
++++ b/tools/testing/radix-tree/idr-test.c
+@@ -57,6 +57,26 @@ void idr_alloc_test(void)
+       idr_destroy(&idr);
+ }
++void idr_alloc2_test(void)
++{
++      int id;
++      struct idr idr = IDR_INIT_BASE(idr, 1);
++
++      id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL);
++      assert(id == -ENOSPC);
++
++      id = idr_alloc(&idr, idr_alloc2_test, 1, 2, GFP_KERNEL);
++      assert(id == 1);
++
++      id = idr_alloc(&idr, idr_alloc2_test, 0, 1, GFP_KERNEL);
++      assert(id == -ENOSPC);
++
++      id = idr_alloc(&idr, idr_alloc2_test, 0, 2, GFP_KERNEL);
++      assert(id == -ENOSPC);
++
++      idr_destroy(&idr);
++}
++
+ void idr_replace_test(void)
+ {
+       DEFINE_IDR(idr);
+@@ -409,6 +429,7 @@ void idr_checks(void)
+       idr_replace_test();
+       idr_alloc_test();
++      idr_alloc2_test();
+       idr_null_test();
+       idr_nowait_test();
+       idr_get_next_test(0);
diff --git a/queue-6.1/kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch b/queue-6.1/kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch
new file mode 100644 (file)
index 0000000..c6d3a5a
--- /dev/null
@@ -0,0 +1,122 @@
+From 6f13db031e27e88213381039032a9cc061578ea6 Mon Sep 17 00:00:00 2001
+From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
+Date: Thu, 4 Dec 2025 19:00:04 +0000
+Subject: kasan: refactor pcpu kasan vmalloc unpoison
+
+From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
+
+commit 6f13db031e27e88213381039032a9cc061578ea6 upstream.
+
+A KASAN tag mismatch, possibly causing a kernel panic, can be observed
+on systems with a tag-based KASAN enabled and with multiple NUMA nodes.
+It was reported on arm64 and reproduced on x86. It can be explained in
+the following points:
+
+1. There can be more than one virtual memory chunk.
+2. Chunk's base address has a tag.
+3. The base address points at the first chunk and thus inherits
+   the tag of the first chunk.
+4. The subsequent chunks will be accessed with the tag from the
+   first chunk.
+5. Thus, the subsequent chunks need to have their tag set to
+   match that of the first chunk.
+
+Refactor code by reusing __kasan_unpoison_vmalloc in a new helper in
+preparation for the actual fix.
+
+Link: https://lkml.kernel.org/r/eb61d93b907e262eefcaa130261a08bcb6c5ce51.1764874575.git.m.wieczorretman@pm.me
+Fixes: 1d96320f8d53 ("kasan, vmalloc: add vmalloc tagging for SW_TAGS")
+Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
+Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
+Cc: Danilo Krummrich <dakr@kernel.org>
+Cc: Dmitriy Vyukov <dvyukov@google.com>
+Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
+Cc: Kees Cook <kees@kernel.org>
+Cc: Marco Elver <elver@google.com>
+Cc: "Uladzislau Rezki (Sony)" <urezki@gmail.com>
+Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
+Cc: <stable@vger.kernel.org>   [6.1+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/kasan.h |   15 +++++++++++++++
+ mm/kasan/common.c     |   17 +++++++++++++++++
+ mm/vmalloc.c          |    4 +---
+ 3 files changed, 33 insertions(+), 3 deletions(-)
+
+--- a/include/linux/kasan.h
++++ b/include/linux/kasan.h
+@@ -428,6 +428,16 @@ static __always_inline void kasan_poison
+               __kasan_poison_vmalloc(start, size);
+ }
++void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
++                               kasan_vmalloc_flags_t flags);
++static __always_inline void
++kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
++                        kasan_vmalloc_flags_t flags)
++{
++      if (kasan_enabled())
++              __kasan_unpoison_vmap_areas(vms, nr_vms, flags);
++}
++
+ #else /* CONFIG_KASAN_VMALLOC */
+ static inline void kasan_populate_early_vm_area_shadow(void *start,
+@@ -451,6 +461,11 @@ static inline void *kasan_unpoison_vmall
+ static inline void kasan_poison_vmalloc(const void *start, unsigned long size)
+ { }
++static __always_inline void
++kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
++                        kasan_vmalloc_flags_t flags)
++{ }
++
+ #endif /* CONFIG_KASAN_VMALLOC */
+ #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \
+--- a/mm/kasan/common.c
++++ b/mm/kasan/common.c
+@@ -26,6 +26,7 @@
+ #include <linux/string.h>
+ #include <linux/types.h>
+ #include <linux/bug.h>
++#include <linux/vmalloc.h>
+ #include "kasan.h"
+ #include "../slab.h"
+@@ -450,3 +451,19 @@ bool __kasan_check_byte(const void *addr
+       }
+       return true;
+ }
++
++#ifdef CONFIG_KASAN_VMALLOC
++void __kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms,
++                               kasan_vmalloc_flags_t flags)
++{
++      unsigned long size;
++      void *addr;
++      int area;
++
++      for (area = 0 ; area < nr_vms ; area++) {
++              size = vms[area]->size;
++              addr = vms[area]->addr;
++              vms[area]->addr = __kasan_unpoison_vmalloc(addr, size, flags);
++      }
++}
++#endif
+--- a/mm/vmalloc.c
++++ b/mm/vmalloc.c
+@@ -3960,9 +3960,7 @@ retry:
+        * With hardware tag-based KASAN, marking is skipped for
+        * non-VM_ALLOC mappings, see __kasan_unpoison_vmalloc().
+        */
+-      for (area = 0; area < nr_vms; area++)
+-              vms[area]->addr = kasan_unpoison_vmalloc(vms[area]->addr,
+-                              vms[area]->size, KASAN_VMALLOC_PROT_NORMAL);
++      kasan_unpoison_vmap_areas(vms, nr_vms, KASAN_VMALLOC_PROT_NORMAL);
+       kfree(vas);
+       return vms;
diff --git a/queue-6.1/loongarch-bpf-sign-extend-kfunc-call-arguments.patch b/queue-6.1/loongarch-bpf-sign-extend-kfunc-call-arguments.patch
new file mode 100644 (file)
index 0000000..017bf66
--- /dev/null
@@ -0,0 +1,86 @@
+From 3f5a238f24d7b75f9efe324d3539ad388f58536e Mon Sep 17 00:00:00 2001
+From: Hengqi Chen <hengqi.chen@gmail.com>
+Date: Wed, 31 Dec 2025 15:19:20 +0800
+Subject: LoongArch: BPF: Sign extend kfunc call arguments
+
+From: Hengqi Chen <hengqi.chen@gmail.com>
+
+commit 3f5a238f24d7b75f9efe324d3539ad388f58536e upstream.
+
+The kfunc calls are native calls so they should follow LoongArch calling
+conventions. Sign extend its arguments properly to avoid kernel panic.
+This is done by adding a new emit_abi_ext() helper. The emit_abi_ext()
+helper performs extension in place meaning a value already store in the
+target register (Note: this is different from the existing sign_extend()
+helper and thus we can't reuse it).
+
+Cc: stable@vger.kernel.org
+Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support")
+Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/net/bpf_jit.c |   16 ++++++++++++++++
+ arch/loongarch/net/bpf_jit.h |   26 ++++++++++++++++++++++++++
+ 2 files changed, 42 insertions(+)
+
+--- a/arch/loongarch/net/bpf_jit.c
++++ b/arch/loongarch/net/bpf_jit.c
+@@ -773,6 +773,22 @@ static int build_insn(const struct bpf_i
+               if (ret < 0)
+                       return ret;
++              if (insn->src_reg == BPF_PSEUDO_KFUNC_CALL) {
++                      const struct btf_func_model *m;
++                      int i;
++
++                      m = bpf_jit_find_kfunc_model(ctx->prog, insn);
++                      if (!m)
++                              return -EINVAL;
++
++                      for (i = 0; i < m->nr_args; i++) {
++                              u8 reg = regmap[BPF_REG_1 + i];
++                              bool sign = m->arg_flags[i] & BTF_FMODEL_SIGNED_ARG;
++
++                              emit_abi_ext(ctx, reg, m->arg_size[i], sign);
++                      }
++              }
++
+               move_addr(ctx, t1, func_addr);
+               emit_insn(ctx, jirl, t1, LOONGARCH_GPR_RA, 0);
+               move_reg(ctx, regmap[BPF_REG_0], LOONGARCH_GPR_A0);
+--- a/arch/loongarch/net/bpf_jit.h
++++ b/arch/loongarch/net/bpf_jit.h
+@@ -80,6 +80,32 @@ static inline void emit_sext_32(struct j
+       emit_insn(ctx, addiw, reg, reg, 0);
+ }
++/* Emit proper extension according to ABI requirements.
++ * Note that it requires a value of size `size` already resides in register `reg`.
++ */
++static inline void emit_abi_ext(struct jit_ctx *ctx, int reg, u8 size, bool sign)
++{
++      /* ABI requires unsigned char/short to be zero-extended */
++      if (!sign && (size == 1 || size == 2))
++              return;
++
++      switch (size) {
++      case 1:
++              emit_insn(ctx, extwb, reg, reg);
++              break;
++      case 2:
++              emit_insn(ctx, extwh, reg, reg);
++              break;
++      case 4:
++              emit_insn(ctx, addiw, reg, reg, 0);
++              break;
++      case 8:
++              break;
++      default:
++              pr_warn("bpf_jit: invalid size %d for extension\n", size);
++      }
++}
++
+ static inline void move_addr(struct jit_ctx *ctx, enum loongarch_gpr rd, u64 addr)
+ {
+       u64 imm_11_0, imm_31_12, imm_51_32, imm_63_52;
diff --git a/queue-6.1/loongarch-bpf-zero-extend-bpf_tail_call-index.patch b/queue-6.1/loongarch-bpf-zero-extend-bpf_tail_call-index.patch
new file mode 100644 (file)
index 0000000..57897e3
--- /dev/null
@@ -0,0 +1,36 @@
+From eb71f5c433e1c6dff089b315881dec40a88a7baf Mon Sep 17 00:00:00 2001
+From: Hengqi Chen <hengqi.chen@gmail.com>
+Date: Wed, 31 Dec 2025 15:19:20 +0800
+Subject: LoongArch: BPF: Zero-extend bpf_tail_call() index
+
+From: Hengqi Chen <hengqi.chen@gmail.com>
+
+commit eb71f5c433e1c6dff089b315881dec40a88a7baf upstream.
+
+The bpf_tail_call() index should be treated as a u32 value. Let's
+zero-extend it to avoid calling wrong BPF progs. See similar fixes
+for x86 [1]) and arm64 ([2]) for more details.
+
+  [1]: https://github.com/torvalds/linux/commit/90caccdd8cc0215705f18b92771b449b01e2474a
+  [2]: https://github.com/torvalds/linux/commit/16338a9b3ac30740d49f5dfed81bac0ffa53b9c7
+
+Cc: stable@vger.kernel.org
+Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support")
+Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/net/bpf_jit.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/loongarch/net/bpf_jit.c
++++ b/arch/loongarch/net/bpf_jit.c
+@@ -224,6 +224,8 @@ static int emit_bpf_tail_call(struct jit
+        *       goto out;
+        */
+       tc_ninsn = insn ? ctx->offset[insn+1] - ctx->offset[insn] : ctx->offset[0];
++      emit_zext_32(ctx, a2, true);
++
+       off = offsetof(struct bpf_array, map.max_entries);
+       emit_insn(ctx, ldwu, t1, a1, off);
+       /* bgeu $a2, $t1, jmp_offset */
diff --git a/queue-6.1/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch b/queue-6.1/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch
new file mode 100644 (file)
index 0000000..8ed3ea0
--- /dev/null
@@ -0,0 +1,170 @@
+From 99537d5c476cada9cf75aef9fa75579a31faadb9 Mon Sep 17 00:00:00 2001
+From: Xiaolei Wang <xiaolei.wang@windriver.com>
+Date: Mon, 22 Dec 2025 09:56:24 +0800
+Subject: net: macb: Relocate mog_init_rings() callback from macb_mac_link_up() to macb_open()
+
+From: Xiaolei Wang <xiaolei.wang@windriver.com>
+
+commit 99537d5c476cada9cf75aef9fa75579a31faadb9 upstream.
+
+In the non-RT kernel, local_bh_disable() merely disables preemption,
+whereas it maps to an actual spin lock in the RT kernel. Consequently,
+when attempting to refill RX buffers via netdev_alloc_skb() in
+macb_mac_link_up(), a deadlock scenario arises as follows:
+
+   WARNING: possible circular locking dependency detected
+   6.18.0-08691-g2061f18ad76e #39 Not tainted
+   ------------------------------------------------------
+   kworker/0:0/8 is trying to acquire lock:
+   ffff00080369bbe0 (&bp->lock){+.+.}-{3:3}, at: macb_start_xmit+0x808/0xb7c
+
+   but task is already holding lock:
+   ffff000803698e58 (&queue->tx_ptr_lock){+...}-{3:3}, at: macb_start_xmit
+   +0x148/0xb7c
+
+   which lock already depends on the new lock.
+
+   the existing dependency chain (in reverse order) is:
+
+   -> #3 (&queue->tx_ptr_lock){+...}-{3:3}:
+          rt_spin_lock+0x50/0x1f0
+          macb_start_xmit+0x148/0xb7c
+          dev_hard_start_xmit+0x94/0x284
+          sch_direct_xmit+0x8c/0x37c
+          __dev_queue_xmit+0x708/0x1120
+          neigh_resolve_output+0x148/0x28c
+          ip6_finish_output2+0x2c0/0xb2c
+          __ip6_finish_output+0x114/0x308
+          ip6_output+0xc4/0x4a4
+          mld_sendpack+0x220/0x68c
+          mld_ifc_work+0x2a8/0x4f4
+          process_one_work+0x20c/0x5f8
+          worker_thread+0x1b0/0x35c
+          kthread+0x144/0x200
+          ret_from_fork+0x10/0x20
+
+   -> #2 (_xmit_ETHER#2){+...}-{3:3}:
+          rt_spin_lock+0x50/0x1f0
+          sch_direct_xmit+0x11c/0x37c
+          __dev_queue_xmit+0x708/0x1120
+          neigh_resolve_output+0x148/0x28c
+          ip6_finish_output2+0x2c0/0xb2c
+          __ip6_finish_output+0x114/0x308
+          ip6_output+0xc4/0x4a4
+          mld_sendpack+0x220/0x68c
+          mld_ifc_work+0x2a8/0x4f4
+          process_one_work+0x20c/0x5f8
+          worker_thread+0x1b0/0x35c
+          kthread+0x144/0x200
+          ret_from_fork+0x10/0x20
+
+   -> #1 ((softirq_ctrl.lock)){+.+.}-{3:3}:
+          lock_release+0x250/0x348
+          __local_bh_enable_ip+0x7c/0x240
+          __netdev_alloc_skb+0x1b4/0x1d8
+          gem_rx_refill+0xdc/0x240
+          gem_init_rings+0xb4/0x108
+          macb_mac_link_up+0x9c/0x2b4
+          phylink_resolve+0x170/0x614
+          process_one_work+0x20c/0x5f8
+          worker_thread+0x1b0/0x35c
+          kthread+0x144/0x200
+          ret_from_fork+0x10/0x20
+
+   -> #0 (&bp->lock){+.+.}-{3:3}:
+          __lock_acquire+0x15a8/0x2084
+          lock_acquire+0x1cc/0x350
+          rt_spin_lock+0x50/0x1f0
+          macb_start_xmit+0x808/0xb7c
+          dev_hard_start_xmit+0x94/0x284
+          sch_direct_xmit+0x8c/0x37c
+          __dev_queue_xmit+0x708/0x1120
+          neigh_resolve_output+0x148/0x28c
+          ip6_finish_output2+0x2c0/0xb2c
+          __ip6_finish_output+0x114/0x308
+          ip6_output+0xc4/0x4a4
+          mld_sendpack+0x220/0x68c
+          mld_ifc_work+0x2a8/0x4f4
+          process_one_work+0x20c/0x5f8
+          worker_thread+0x1b0/0x35c
+          kthread+0x144/0x200
+          ret_from_fork+0x10/0x20
+
+   other info that might help us debug this:
+
+   Chain exists of:
+     &bp->lock --> _xmit_ETHER#2 --> &queue->tx_ptr_lock
+
+    Possible unsafe locking scenario:
+
+          CPU0                    CPU1
+          ----                    ----
+     lock(&queue->tx_ptr_lock);
+                                  lock(_xmit_ETHER#2);
+                                  lock(&queue->tx_ptr_lock);
+     lock(&bp->lock);
+
+    *** DEADLOCK ***
+
+   Call trace:
+    show_stack+0x18/0x24 (C)
+    dump_stack_lvl+0xa0/0xf0
+    dump_stack+0x18/0x24
+    print_circular_bug+0x28c/0x370
+    check_noncircular+0x198/0x1ac
+    __lock_acquire+0x15a8/0x2084
+    lock_acquire+0x1cc/0x350
+    rt_spin_lock+0x50/0x1f0
+    macb_start_xmit+0x808/0xb7c
+    dev_hard_start_xmit+0x94/0x284
+    sch_direct_xmit+0x8c/0x37c
+    __dev_queue_xmit+0x708/0x1120
+    neigh_resolve_output+0x148/0x28c
+    ip6_finish_output2+0x2c0/0xb2c
+    __ip6_finish_output+0x114/0x308
+    ip6_output+0xc4/0x4a4
+    mld_sendpack+0x220/0x68c
+    mld_ifc_work+0x2a8/0x4f4
+    process_one_work+0x20c/0x5f8
+    worker_thread+0x1b0/0x35c
+    kthread+0x144/0x200
+    ret_from_fork+0x10/0x20
+
+Notably, invoking the mog_init_rings() callback upon link establishment
+is unnecessary. Instead, we can exclusively call mog_init_rings() within
+the ndo_open() callback. This adjustment resolves the deadlock issue.
+Furthermore, since MACB_CAPS_MACB_IS_EMAC cases do not use mog_init_rings()
+when opening the network interface via at91ether_open(), moving
+mog_init_rings() to macb_open() also eliminates the MACB_CAPS_MACB_IS_EMAC
+check.
+
+Fixes: 633e98a711ac ("net: macb: use resolved link config in mac_link_up()")
+Cc: stable@vger.kernel.org
+Suggested-by: Kevin Hao <kexin.hao@windriver.com>
+Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
+Link: https://patch.msgid.link/20251222015624.1994551-1-xiaolei.wang@windriver.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/cadence/macb_main.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/cadence/macb_main.c
++++ b/drivers/net/ethernet/cadence/macb_main.c
+@@ -708,7 +708,6 @@ static void macb_mac_link_up(struct phyl
+               /* Initialize rings & buffers as clearing MACB_BIT(TE) in link down
+                * cleared the pipeline and control registers.
+                */
+-              bp->macbgem_ops.mog_init_rings(bp);
+               macb_init_buffers(bp);
+               for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue)
+@@ -2880,6 +2879,8 @@ static int macb_open(struct net_device *
+               goto pm_exit;
+       }
++      bp->macbgem_ops.mog_init_rings(bp);
++
+       for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
+               napi_enable(&queue->napi_rx);
+               napi_enable(&queue->napi_tx);
diff --git a/queue-6.1/net-nfc-fix-deadlock-between-nfc_unregister_device-and-rfkill_fop_write.patch b/queue-6.1/net-nfc-fix-deadlock-between-nfc_unregister_device-and-rfkill_fop_write.patch
new file mode 100644 (file)
index 0000000..dccbd71
--- /dev/null
@@ -0,0 +1,91 @@
+From 1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5 Mon Sep 17 00:00:00 2001
+From: Deepanshu Kartikey <kartikey406@gmail.com>
+Date: Thu, 18 Dec 2025 06:53:54 +0530
+Subject: net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write
+
+From: Deepanshu Kartikey <kartikey406@gmail.com>
+
+commit 1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5 upstream.
+
+A deadlock can occur between nfc_unregister_device() and rfkill_fop_write()
+due to lock ordering inversion between device_lock and rfkill_global_mutex.
+
+The problematic lock order is:
+
+Thread A (rfkill_fop_write):
+  rfkill_fop_write()
+    mutex_lock(&rfkill_global_mutex)
+      rfkill_set_block()
+        nfc_rfkill_set_block()
+          nfc_dev_down()
+            device_lock(&dev->dev)    <- waits for device_lock
+
+Thread B (nfc_unregister_device):
+  nfc_unregister_device()
+    device_lock(&dev->dev)
+      rfkill_unregister()
+        mutex_lock(&rfkill_global_mutex)  <- waits for rfkill_global_mutex
+
+This creates a classic ABBA deadlock scenario.
+
+Fix this by moving rfkill_unregister() and rfkill_destroy() outside the
+device_lock critical section. Store the rfkill pointer in a local variable
+before releasing the lock, then call rfkill_unregister() after releasing
+device_lock.
+
+This change is safe because rfkill_fop_write() holds rfkill_global_mutex
+while calling the rfkill callbacks, and rfkill_unregister() also acquires
+rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will
+wait for any ongoing callback to complete before proceeding, and
+device_del() is only called after rfkill_unregister() returns, preventing
+any use-after-free.
+
+The similar lock ordering in nfc_register_device() (device_lock ->
+rfkill_global_mutex via rfkill_register) is safe because during
+registration the device is not yet in rfkill_list, so no concurrent
+rfkill operations can occur on this device.
+
+Fixes: 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")
+Cc: stable@vger.kernel.org
+Reported-by: syzbot+4ef89409a235d804c6c2@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=4ef89409a235d804c6c2
+Link: https://lore.kernel.org/all/20251217054908.178907-1-kartikey406@gmail.com/T/ [v1]
+Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
+Link: https://patch.msgid.link/20251218012355.279940-1-kartikey406@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/nfc/core.c |    9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/net/nfc/core.c
++++ b/net/nfc/core.c
+@@ -1154,6 +1154,7 @@ EXPORT_SYMBOL(nfc_register_device);
+ void nfc_unregister_device(struct nfc_dev *dev)
+ {
+       int rc;
++      struct rfkill *rfk = NULL;
+       pr_debug("dev_name=%s\n", dev_name(&dev->dev));
+@@ -1164,13 +1165,17 @@ void nfc_unregister_device(struct nfc_de
+       device_lock(&dev->dev);
+       if (dev->rfkill) {
+-              rfkill_unregister(dev->rfkill);
+-              rfkill_destroy(dev->rfkill);
++              rfk = dev->rfkill;
+               dev->rfkill = NULL;
+       }
+       dev->shutting_down = true;
+       device_unlock(&dev->dev);
++      if (rfk) {
++              rfkill_unregister(rfk);
++              rfkill_destroy(rfk);
++      }
++
+       if (dev->ops->check_presence) {
+               del_timer_sync(&dev->check_pres_timer);
+               cancel_work_sync(&dev->check_pres_work);
diff --git a/queue-6.1/net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch b/queue-6.1/net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch
new file mode 100644 (file)
index 0000000..2e4a06f
--- /dev/null
@@ -0,0 +1,43 @@
+From fa0b198be1c6775bc7804731a43be5d899d19e7a Mon Sep 17 00:00:00 2001
+From: Ethan Nelson-Moore <enelsonmoore@gmail.com>
+Date: Sun, 21 Dec 2025 00:24:00 -0800
+Subject: net: usb: sr9700: fix incorrect command used to write single register
+
+From: Ethan Nelson-Moore <enelsonmoore@gmail.com>
+
+commit fa0b198be1c6775bc7804731a43be5d899d19e7a upstream.
+
+This fixes the device failing to initialize with "error reading MAC
+address" for me, probably because the incorrect write of NCR_RST to
+SR_NCR is not actually resetting the device.
+
+Fixes: c9b37458e95629b1d1171457afdcc1bf1eb7881d ("USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
+Link: https://patch.msgid.link/20251221082400.50688-1-enelsonmoore@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/usb/sr9700.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/usb/sr9700.c
++++ b/drivers/net/usb/sr9700.c
+@@ -52,7 +52,7 @@ static int sr_read_reg(struct usbnet *de
+ static int sr_write_reg(struct usbnet *dev, u8 reg, u8 value)
+ {
+-      return usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
++      return usbnet_write_cmd(dev, SR_WR_REG, SR_REQ_WR_REG,
+                               value, reg, NULL, 0);
+ }
+@@ -65,7 +65,7 @@ static void sr_write_async(struct usbnet
+ static void sr_write_reg_async(struct usbnet *dev, u8 reg, u8 value)
+ {
+-      usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
++      usbnet_write_cmd_async(dev, SR_WR_REG, SR_REQ_WR_REG,
+                              value, reg, NULL, 0);
+ }
diff --git a/queue-6.1/nfsd-drop-the-client-reference-in-client_states_open.patch b/queue-6.1/nfsd-drop-the-client-reference-in-client_states_open.patch
new file mode 100644 (file)
index 0000000..49da048
--- /dev/null
@@ -0,0 +1,36 @@
+From 1f941b2c23fd34c6f3b76d36f9d0a2528fa92b8f Mon Sep 17 00:00:00 2001
+From: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
+Date: Sat, 6 Dec 2025 15:38:42 +0800
+Subject: nfsd: Drop the client reference in client_states_open()
+
+From: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
+
+commit 1f941b2c23fd34c6f3b76d36f9d0a2528fa92b8f upstream.
+
+In error path, call drop_client() to drop the reference
+obtained by get_nfsdfs_clp().
+
+Fixes: 78599c42ae3c ("nfsd4: add file to display list of client's opens")
+Cc: stable@vger.kernel.org
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfsd/nfs4state.c |    4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/nfsd/nfs4state.c
++++ b/fs/nfsd/nfs4state.c
+@@ -2804,8 +2804,10 @@ static int client_states_open(struct ino
+               return -ENXIO;
+       ret = seq_open(file, &states_seq_ops);
+-      if (ret)
++      if (ret) {
++              drop_client(clp);
+               return ret;
++      }
+       s = file->private_data;
+       s->private = clp;
+       return 0;
diff --git a/queue-6.1/rdma-cm-fix-leaking-the-multicast-gid-table-reference.patch b/queue-6.1/rdma-cm-fix-leaking-the-multicast-gid-table-reference.patch
new file mode 100644 (file)
index 0000000..32975b2
--- /dev/null
@@ -0,0 +1,51 @@
+From 57f3cb6c84159d12ba343574df2115fb18dd83ca Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Fri, 28 Nov 2025 20:53:21 -0400
+Subject: RDMA/cm: Fix leaking the multicast GID table reference
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit 57f3cb6c84159d12ba343574df2115fb18dd83ca upstream.
+
+If the CM ID is destroyed while the CM event for multicast creating is
+still queued the cancel_work_sync() will prevent the work from running
+which also prevents destroying the ah_attr. This leaks a refcount and
+triggers a WARN:
+
+   GID entry ref leak for dev syz1 index 2 ref=573
+   WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]
+   WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886
+
+Destroy the ah_attr after canceling the work, it is safe to call this
+twice.
+
+Link: https://patch.msgid.link/r/0-v1-4285d070a6b2+20a-rdma_mc_gid_leak_syz_jgg@nvidia.com
+Cc: stable@vger.kernel.org
+Fixes: fe454dc31e84 ("RDMA/ucma: Fix use-after-free bug in ucma_create_uevent")
+Reported-by: syzbot+b0da83a6c0e2e2bddbd4@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/all/68232e7b.050a0220.f2294.09f6.GAE@google.com
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/core/cma.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/infiniband/core/cma.c
++++ b/drivers/infiniband/core/cma.c
+@@ -1970,6 +1970,7 @@ static void destroy_mc(struct rdma_id_pr
+               ib_sa_free_multicast(mc->sa_mc);
+       if (rdma_protocol_roce(id_priv->id.device, id_priv->id.port_num)) {
++              struct rdma_cm_event *event = &mc->iboe_join.event;
+               struct rdma_dev_addr *dev_addr =
+                       &id_priv->id.route.addr.dev_addr;
+               struct net_device *ndev = NULL;
+@@ -1992,6 +1993,8 @@ static void destroy_mc(struct rdma_id_pr
+               dev_put(ndev);
+               cancel_work_sync(&mc->iboe_join.work);
++              if (event->event == RDMA_CM_EVENT_MULTICAST_JOIN)
++                      rdma_destroy_ah_attr(&event->param.ud.ah_attr);
+       }
+       kfree(mc);
+ }
diff --git a/queue-6.1/rdma-core-check-for-the-presence-of-ls_nla_type_dgid-correctly.patch b/queue-6.1/rdma-core-check-for-the-presence-of-ls_nla_type_dgid-correctly.patch
new file mode 100644 (file)
index 0000000..f60ef54
--- /dev/null
@@ -0,0 +1,129 @@
+From a7b8e876e0ef0232b8076972c57ce9a7286b47ca Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Fri, 28 Nov 2025 13:37:28 -0400
+Subject: RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctly
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit a7b8e876e0ef0232b8076972c57ce9a7286b47ca upstream.
+
+The netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have a
+LS_NLA_TYPE_DGID attribute, it is invalid if it does not.
+
+Use the nl parsing logic properly and call nla_parse_deprecated() to fill
+the nlattrs array and then directly index that array to get the data for
+the DGID. Just fail if it is NULL.
+
+Remove the for loop searching for the nla, and squash the validation and
+parsing into one function.
+
+Fixes an uninitialized read from the stack triggered by userspace if it
+does not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVE
+query.
+
+    BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline]
+    BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490
+     hex_byte_pack include/linux/hex.h:13 [inline]
+     ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490
+     ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509
+     ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633
+     pointer+0xc09/0x1bd0 lib/vsprintf.c:2542
+     vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930
+     vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279
+     vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426
+     vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465
+     vprintk+0x36/0x50 kernel/printk/printk_safe.c:82
+     _printk+0x17e/0x1b0 kernel/printk/printk.c:2475
+     ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline]
+     ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141
+     rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline]
+     rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
+     rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259
+     netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
+     netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346
+     netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896
+     sock_sendmsg_nosec net/socket.c:714 [inline]
+     __sock_sendmsg+0x333/0x3d0 net/socket.c:729
+     ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617
+     ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671
+     __sys_sendmsg+0x1aa/0x300 net/socket.c:2703
+     __compat_sys_sendmsg net/compat.c:346 [inline]
+     __do_compat_sys_sendmsg net/compat.c:353 [inline]
+     __se_compat_sys_sendmsg net/compat.c:350 [inline]
+     __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350
+     ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371
+     do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]
+     __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306
+     do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331
+     do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3
+
+Link: https://patch.msgid.link/r/0-v1-3fbaef094271+2cf-rdma_op_ip_rslv_syz_jgg@nvidia.com
+Cc: stable@vger.kernel.org
+Fixes: ae43f8286730 ("IB/core: Add IP to GID netlink offload")
+Reported-by: syzbot+938fcd548c303fe33c1a@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/r/68dc3dac.a00a0220.102ee.004f.GAE@google.com
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/core/addr.c |   33 ++++++++++-----------------------
+ 1 file changed, 10 insertions(+), 23 deletions(-)
+
+--- a/drivers/infiniband/core/addr.c
++++ b/drivers/infiniband/core/addr.c
+@@ -80,37 +80,25 @@ static const struct nla_policy ib_nl_add
+               .min = sizeof(struct rdma_nla_ls_gid)},
+ };
+-static inline bool ib_nl_is_good_ip_resp(const struct nlmsghdr *nlh)
++static void ib_nl_process_ip_rsep(const struct nlmsghdr *nlh)
+ {
+       struct nlattr *tb[LS_NLA_TYPE_MAX] = {};
++      union ib_gid gid;
++      struct addr_req *req;
++      int found = 0;
+       int ret;
+       if (nlh->nlmsg_flags & RDMA_NL_LS_F_ERR)
+-              return false;
++              return;
+       ret = nla_parse_deprecated(tb, LS_NLA_TYPE_MAX - 1, nlmsg_data(nlh),
+                                  nlmsg_len(nlh), ib_nl_addr_policy, NULL);
+       if (ret)
+-              return false;
+-
+-      return true;
+-}
+-
+-static void ib_nl_process_good_ip_rsep(const struct nlmsghdr *nlh)
+-{
+-      const struct nlattr *head, *curr;
+-      union ib_gid gid;
+-      struct addr_req *req;
+-      int len, rem;
+-      int found = 0;
+-
+-      head = (const struct nlattr *)nlmsg_data(nlh);
+-      len = nlmsg_len(nlh);
++              return;
+-      nla_for_each_attr(curr, head, len, rem) {
+-              if (curr->nla_type == LS_NLA_TYPE_DGID)
+-                      memcpy(&gid, nla_data(curr), nla_len(curr));
+-      }
++      if (!tb[LS_NLA_TYPE_DGID])
++              return;
++      memcpy(&gid, nla_data(tb[LS_NLA_TYPE_DGID]), sizeof(gid));
+       spin_lock_bh(&lock);
+       list_for_each_entry(req, &req_list, list) {
+@@ -137,8 +125,7 @@ int ib_nl_handle_ip_res_resp(struct sk_b
+           !(NETLINK_CB(skb).sk))
+               return -EPERM;
+-      if (ib_nl_is_good_ip_resp(nlh))
+-              ib_nl_process_good_ip_rsep(nlh);
++      ib_nl_process_ip_rsep(nlh);
+       return 0;
+ }
index 3f593a6387500cb717f933e38ca10b5655a07b22..0bec1f664c0deb1fcd023b71a377941d8fb98f7b 100644 (file)
@@ -490,3 +490,16 @@ media-i2c-adv7842-remove-redundant-cancel_delayed_work-in-probe.patch
 loongarch-add-new-pci-id-for-pci_fixup_vgadev.patch
 loongarch-correct-the-calculation-logic-of-thread_count.patch
 loongarch-use-__pmd-__pte-for-swap-entry-conversions.patch
+compiler_types.h-add-auto-as-a-macro-for-__auto_type.patch
+kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch
+idr-fix-idr_alloc-returning-an-id-out-of-range.patch
+rdma-core-check-for-the-presence-of-ls_nla_type_dgid-correctly.patch
+rdma-cm-fix-leaking-the-multicast-gid-table-reference.patch
+e1000-fix-oob-in-e1000_tbi_should_accept.patch
+fjes-add-missing-iounmap-in-fjes_hw_init.patch
+loongarch-bpf-zero-extend-bpf_tail_call-index.patch
+loongarch-bpf-sign-extend-kfunc-call-arguments.patch
+nfsd-drop-the-client-reference-in-client_states_open.patch
+net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch
+net-nfc-fix-deadlock-between-nfc_unregister_device-and-rfkill_fop_write.patch
+net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch