From: Greg Kroah-Hartman Date: Mon, 5 Jan 2026 13:09:54 +0000 (+0100) Subject: 6.1-stable patches X-Git-Tag: v6.12.64~23 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=afd39f6c62f6cad2abcde16bc79ec072ce995558;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches 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 --- 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 index 0000000000..b1fe41d76c --- /dev/null +++ b/queue-6.1/compiler_types.h-add-auto-as-a-macro-for-__auto_type.patch @@ -0,0 +1,58 @@ +From 2fb6915fa22dc5524d704afba58a13305dd9f533 Mon Sep 17 00:00:00 2001 +From: "H. Peter Anvin" +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 + +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 because that header is +included in some of the tools headers, wheres 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) +Acked-by: Miguel Ojeda +Cc: +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..10080b82dd --- /dev/null +++ b/queue-6.1/e1000-fix-oob-in-e1000_tbi_should_accept.patch @@ -0,0 +1,123 @@ +From 9c72a5182ed92904d01057f208c390a303f00a0f Mon Sep 17 00:00:00 2001 +From: Guangshuo Li +Date: Mon, 1 Dec 2025 11:40:58 +0800 +Subject: e1000: fix OOB in e1000_tbi_should_accept() + +From: Guangshuo Li + +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: + + 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 + + + __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 + +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 +Reviewed-by: Simon Horman +Reviewed-by: Aleksandr Loktionov +Signed-off-by: Tony Nguyen +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..6428d994dc --- /dev/null +++ b/queue-6.1/fjes-add-missing-iounmap-in-fjes_hw_init.patch @@ -0,0 +1,60 @@ +From 15ef641a0c6728d25a400df73922e80ab2cf029c Mon Sep 17 00:00:00 2001 +From: Haoxiang Li +Date: Thu, 11 Dec 2025 15:37:56 +0800 +Subject: fjes: Add missing iounmap in fjes_hw_init() + +From: Haoxiang Li + +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 +Signed-off-by: Simon Horman +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20251211073756.101824-1-lihaoxiang@isrc.iscas.ac.cn +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..eed5f4bc0e --- /dev/null +++ b/queue-6.1/idr-fix-idr_alloc-returning-an-id-out-of-range.patch @@ -0,0 +1,80 @@ +From c6e8e595a0798ad67da0f7bebaf69c31ef70dfff Mon Sep 17 00:00:00 2001 +From: "Matthew Wilcox (Oracle)" +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) + +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) +Reported-by: Jan Sokolowski +Reported-by: Koen Koning +Reported-by: Peter Senna Tschudin +Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6449 +Reviewed-by: Christian König +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..c6d3a5a1d8 --- /dev/null +++ b/queue-6.1/kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch @@ -0,0 +1,122 @@ +From 6f13db031e27e88213381039032a9cc061578ea6 Mon Sep 17 00:00:00 2001 +From: Maciej Wieczor-Retman +Date: Thu, 4 Dec 2025 19:00:04 +0000 +Subject: kasan: refactor pcpu kasan vmalloc unpoison + +From: Maciej Wieczor-Retman + +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 +Reviewed-by: Andrey Konovalov +Cc: Alexander Potapenko +Cc: Andrey Ryabinin +Cc: Danilo Krummrich +Cc: Dmitriy Vyukov +Cc: Jiayuan Chen +Cc: Kees Cook +Cc: Marco Elver +Cc: "Uladzislau Rezki (Sony)" +Cc: Vincenzo Frascino +Cc: [6.1+] +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include + + #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 index 0000000000..017bf668f9 --- /dev/null +++ b/queue-6.1/loongarch-bpf-sign-extend-kfunc-call-arguments.patch @@ -0,0 +1,86 @@ +From 3f5a238f24d7b75f9efe324d3539ad388f58536e Mon Sep 17 00:00:00 2001 +From: Hengqi Chen +Date: Wed, 31 Dec 2025 15:19:20 +0800 +Subject: LoongArch: BPF: Sign extend kfunc call arguments + +From: Hengqi Chen + +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 +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..57897e30b1 --- /dev/null +++ b/queue-6.1/loongarch-bpf-zero-extend-bpf_tail_call-index.patch @@ -0,0 +1,36 @@ +From eb71f5c433e1c6dff089b315881dec40a88a7baf Mon Sep 17 00:00:00 2001 +From: Hengqi Chen +Date: Wed, 31 Dec 2025 15:19:20 +0800 +Subject: LoongArch: BPF: Zero-extend bpf_tail_call() index + +From: Hengqi Chen + +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 +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..8ed3ea0350 --- /dev/null +++ b/queue-6.1/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch @@ -0,0 +1,170 @@ +From 99537d5c476cada9cf75aef9fa75579a31faadb9 Mon Sep 17 00:00:00 2001 +From: Xiaolei Wang +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 + +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 +Signed-off-by: Xiaolei Wang +Link: https://patch.msgid.link/20251222015624.1994551-1-xiaolei.wang@windriver.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..dccbd71dc5 --- /dev/null +++ b/queue-6.1/net-nfc-fix-deadlock-between-nfc_unregister_device-and-rfkill_fop_write.patch @@ -0,0 +1,91 @@ +From 1ab526d97a57e44d26fadcc0e9adeb9c0c0182f5 Mon Sep 17 00:00:00 2001 +From: Deepanshu Kartikey +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 + +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 +Reviewed-by: Krzysztof Kozlowski +Link: https://patch.msgid.link/20251218012355.279940-1-kartikey406@gmail.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..2e4a06faf8 --- /dev/null +++ b/queue-6.1/net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch @@ -0,0 +1,43 @@ +From fa0b198be1c6775bc7804731a43be5d899d19e7a Mon Sep 17 00:00:00 2001 +From: Ethan Nelson-Moore +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 + +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 +Link: https://patch.msgid.link/20251221082400.50688-1-enelsonmoore@gmail.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..49da048c88 --- /dev/null +++ b/queue-6.1/nfsd-drop-the-client-reference-in-client_states_open.patch @@ -0,0 +1,36 @@ +From 1f941b2c23fd34c6f3b76d36f9d0a2528fa92b8f Mon Sep 17 00:00:00 2001 +From: Haoxiang Li +Date: Sat, 6 Dec 2025 15:38:42 +0800 +Subject: nfsd: Drop the client reference in client_states_open() + +From: Haoxiang Li + +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 +Signed-off-by: Haoxiang Li +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..32975b21b0 --- /dev/null +++ b/queue-6.1/rdma-cm-fix-leaking-the-multicast-gid-table-reference.patch @@ -0,0 +1,51 @@ +From 57f3cb6c84159d12ba343574df2115fb18dd83ca Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Fri, 28 Nov 2025 20:53:21 -0400 +Subject: RDMA/cm: Fix leaking the multicast GID table reference + +From: Jason Gunthorpe + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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 index 0000000000..f60ef54025 --- /dev/null +++ b/queue-6.1/rdma-core-check-for-the-presence-of-ls_nla_type_dgid-correctly.patch @@ -0,0 +1,129 @@ +From a7b8e876e0ef0232b8076972c57ce9a7286b47ca Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +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 + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.1/series b/queue-6.1/series index 3f593a6387..0bec1f664c 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -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