From: Greg Kroah-Hartman Date: Mon, 5 Jan 2026 13:11:30 +0000 (+0100) Subject: 6.18-stable patches X-Git-Tag: v6.12.64~21 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=30f537698fa55f95af4de728b0190aa269274df2;p=thirdparty%2Fkernel%2Fstable-queue.git 6.18-stable patches added patches: af_unix-don-t-post-cmsg-for-so_inq-unless-explicitly-asked-for.patch compiler_types.h-add-auto-as-a-macro-for-__auto_type.patch e1000-fix-oob-in-e1000_tbi_should_accept.patch erspan-initialize-options_len-before-referencing-options.patch fjes-add-missing-iounmap-in-fjes_hw_init.patch gve-defer-interrupt-enabling-until-napi-registration.patch idr-fix-idr_alloc-returning-an-id-out-of-range.patch kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch kasan-unpoison-vms-addresses-with-a-common-tag.patch kernel-kexec-change-the-prototype-of-kimage_map_segment.patch kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch lockd-fix-vfs_test_lock-calls.patch loongarch-bpf-adjust-the-jump-offset-of-tail-calls.patch loongarch-bpf-enable-trampoline-based-tracing-for-module-functions.patch loongarch-bpf-save-return-address-register-ra-to-t0-before-trampoline.patch loongarch-bpf-sign-extend-kfunc-call-arguments.patch loongarch-bpf-zero-extend-bpf_tail_call-index.patch loongarch-refactor-register-restoration-in-ftrace_common_return.patch mm-consider-non-anon-swap-cache-folios-in-folio_expected_ref_count.patch mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch mm-page_alloc-change-all-pageblocks-migrate-type-on-coalescing.patch mm-page_owner-fix-memory-leak-in-page_owner_stack_fops-release.patch mptcp-fallback-earlier-on-simult-connection.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-phy-mediatek-fix-nvmem-cell-reference-leak-in-mt798x_phy_calibration.patch net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch nfsd-drop-the-client-reference-in-client_states_open.patch nfsd-fix-nfsd_file-reference-leak-in-nfsd4_add_rdaccess_to_wrdeleg.patch nfsd-use-attr_deleg-in-nfsd4_finalize_deleg_timestamps.patch platform-x86-alienware-wmi-wmax-add-awcc-support-for-alienware-x16.patch platform-x86-alienware-wmi-wmax-add-support-for-alienware-16x-aurora.patch platform-x86-alienware-wmi-wmax-add-support-for-new-area-51-laptops.patch platform-x86-samsung-galaxybook-fix-problematic-pointer-cast.patch pmdomain-imx-fix-reference-count-leak-in-imx_gpc_probe.patch pmdomain-mtk-pm-domains-fix-spinlock-recursion-fix-in-probe.patch rdma-cm-fix-leaking-the-multicast-gid-table-reference.patch rdma-core-check-for-the-presence-of-ls_nla_type_dgid-correctly.patch rust-maple_tree-rcu_read_lock-in-destructor-to-silence-lockdep.patch samples-ftrace-adjust-loongarch-register-restore-order-in-direct-calls.patch selftests-mm-fix-thread-state-check-in-uffd-unit-tests.patch tools-mm-page_owner_sort-fix-timestamp-comparison-for-stable-sorting.patch wifi-iwlwifi-fix-firmware-version-handling.patch wifi-mac80211-discard-beacon-frames-to-non-broadcast-address.patch x86-microcode-amd-fix-entrysign-revision-check-for-zen5-strix-halo.patch --- diff --git a/queue-6.18/af_unix-don-t-post-cmsg-for-so_inq-unless-explicitly-asked-for.patch b/queue-6.18/af_unix-don-t-post-cmsg-for-so_inq-unless-explicitly-asked-for.patch new file mode 100644 index 0000000000..18e7dfda46 --- /dev/null +++ b/queue-6.18/af_unix-don-t-post-cmsg-for-so_inq-unless-explicitly-asked-for.patch @@ -0,0 +1,72 @@ +From 4d1442979e4a53b9457ce1e373e187e1511ff688 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Thu, 18 Dec 2025 15:21:28 -0700 +Subject: af_unix: don't post cmsg for SO_INQ unless explicitly asked for + +From: Jens Axboe + +commit 4d1442979e4a53b9457ce1e373e187e1511ff688 upstream. + +A previous commit added SO_INQ support for AF_UNIX (SOCK_STREAM), but it +posts a SCM_INQ cmsg even if just msg->msg_get_inq is set. This is +incorrect, as ->msg_get_inq is just the caller asking for the remainder +to be passed back in msg->msg_inq, it has nothing to do with cmsg. The +original commit states that this is done to make sockets +io_uring-friendly", but it's actually incorrect as io_uring doesn't use +cmsg headers internally at all, and it's actively wrong as this means +that cmsg's are always posted if someone does recvmsg via io_uring. + +Fix that up by only posting a cmsg if u->recvmsg_inq is set. + +Additionally, mirror how TCP handles inquiry handling in that it should +only be done for a successful return. This makes the logic for the two +identical. + +Cc: stable@vger.kernel.org +Fixes: df30285b3670 ("af_unix: Introduce SO_INQ.") +Reported-by: Julian Orth +Link: https://github.com/axboe/liburing/issues/1509 +Signed-off-by: Jens Axboe +Reviewed-by: Willem de Bruijn +Link: https://patch.msgid.link/07adc0c2-2c3b-4d08-8af1-1c466a40b6a8@kernel.dk +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + net/unix/af_unix.c | 11 ++++++++--- + 1 file changed, 8 insertions(+), 3 deletions(-) + +--- a/net/unix/af_unix.c ++++ b/net/unix/af_unix.c +@@ -2929,6 +2929,7 @@ static int unix_stream_read_generic(stru + unsigned int last_len; + struct unix_sock *u; + int copied = 0; ++ bool do_cmsg; + int err = 0; + long timeo; + int target; +@@ -2954,6 +2955,9 @@ static int unix_stream_read_generic(stru + + u = unix_sk(sk); + ++ do_cmsg = READ_ONCE(u->recvmsg_inq); ++ if (do_cmsg) ++ msg->msg_get_inq = 1; + redo: + /* Lock the socket to prevent queue disordering + * while sleeps in memcpy_tomsg +@@ -3113,10 +3117,11 @@ unlock: + if (msg) { + scm_recv_unix(sock, msg, &scm, flags); + +- if (READ_ONCE(u->recvmsg_inq) || msg->msg_get_inq) { ++ if (msg->msg_get_inq && (copied ?: err) >= 0) { + msg->msg_inq = READ_ONCE(u->inq_len); +- put_cmsg(msg, SOL_SOCKET, SCM_INQ, +- sizeof(msg->msg_inq), &msg->msg_inq); ++ if (do_cmsg) ++ put_cmsg(msg, SOL_SOCKET, SCM_INQ, ++ sizeof(msg->msg_inq), &msg->msg_inq); + } + } else { + scm_destroy(&scm); diff --git a/queue-6.18/compiler_types.h-add-auto-as-a-macro-for-__auto_type.patch b/queue-6.18/compiler_types.h-add-auto-as-a-macro-for-__auto_type.patch new file mode 100644 index 0000000000..2774d618c1 --- /dev/null +++ b/queue-6.18/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 +@@ -14,6 +14,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.18/e1000-fix-oob-in-e1000_tbi_should_accept.patch b/queue-6.18/e1000-fix-oob-in-e1000_tbi_should_accept.patch new file mode 100644 index 0000000000..7804460620 --- /dev/null +++ b/queue-6.18/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 +@@ -4094,7 +4094,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.18/erspan-initialize-options_len-before-referencing-options.patch b/queue-6.18/erspan-initialize-options_len-before-referencing-options.patch new file mode 100644 index 0000000000..73fbbd00c2 --- /dev/null +++ b/queue-6.18/erspan-initialize-options_len-before-referencing-options.patch @@ -0,0 +1,115 @@ +From 35ddf66c65eff93fff91406756ba273600bf61a3 Mon Sep 17 00:00:00 2001 +From: Frode Nordahl +Date: Sat, 13 Dec 2025 10:13:36 +0000 +Subject: erspan: Initialize options_len before referencing options. + +From: Frode Nordahl + +commit 35ddf66c65eff93fff91406756ba273600bf61a3 upstream. + +The struct ip_tunnel_info has a flexible array member named +options that is protected by a counted_by(options_len) +attribute. + +The compiler will use this information to enforce runtime bounds +checking deployed by FORTIFY_SOURCE string helpers. + +As laid out in the GCC documentation, the counter must be +initialized before the first reference to the flexible array +member. + +After scanning through the files that use struct ip_tunnel_info +and also refer to options or options_len, it appears the normal +case is to use the ip_tunnel_info_opts_set() helper. + +Said helper would initialize options_len properly before copying +data into options, however in the GRE ERSPAN code a partial +update is done, preventing the use of the helper function. + +Before this change the handling of ERSPAN traffic in GRE tunnels +would cause a kernel panic when the kernel is compiled with +GCC 15+ and having FORTIFY_SOURCE configured: + +memcpy: detected buffer overflow: 4 byte write of buffer size 0 + +Call Trace: + + __fortify_panic+0xd/0xf + erspan_rcv.cold+0x68/0x83 + ? ip_route_input_slow+0x816/0x9d0 + gre_rcv+0x1b2/0x1c0 + gre_rcv+0x8e/0x100 + ? raw_v4_input+0x2a0/0x2b0 + ip_protocol_deliver_rcu+0x1ea/0x210 + ip_local_deliver_finish+0x86/0x110 + ip_local_deliver+0x65/0x110 + ? ip_rcv_finish_core+0xd6/0x360 + ip_rcv+0x186/0x1a0 + +Cc: stable@vger.kernel.org +Link: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-counted_005fby-variable-attribute +Reported-at: https://launchpad.net/bugs/2129580 +Fixes: bb5e62f2d547 ("net: Add options as a flexible array to struct ip_tunnel_info") +Signed-off-by: Frode Nordahl +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20251213101338.4693-1-fnordahl@ubuntu.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/ip_gre.c | 6 ++++-- + net/ipv6/ip6_gre.c | 6 ++++-- + 2 files changed, 8 insertions(+), 4 deletions(-) + +--- a/net/ipv4/ip_gre.c ++++ b/net/ipv4/ip_gre.c +@@ -330,6 +330,10 @@ static int erspan_rcv(struct sk_buff *sk + if (!tun_dst) + return PACKET_REJECT; + ++ /* MUST set options_len before referencing options */ ++ info = &tun_dst->u.tun_info; ++ info->options_len = sizeof(*md); ++ + /* skb can be uncloned in __iptunnel_pull_header, so + * old pkt_md is no longer valid and we need to reset + * it +@@ -344,10 +348,8 @@ static int erspan_rcv(struct sk_buff *sk + memcpy(md2, pkt_md, ver == 1 ? ERSPAN_V1_MDSIZE : + ERSPAN_V2_MDSIZE); + +- info = &tun_dst->u.tun_info; + __set_bit(IP_TUNNEL_ERSPAN_OPT_BIT, + info->key.tun_flags); +- info->options_len = sizeof(*md); + } + + skb_reset_mac_header(skb); +--- a/net/ipv6/ip6_gre.c ++++ b/net/ipv6/ip6_gre.c +@@ -535,6 +535,10 @@ static int ip6erspan_rcv(struct sk_buff + if (!tun_dst) + return PACKET_REJECT; + ++ /* MUST set options_len before referencing options */ ++ info = &tun_dst->u.tun_info; ++ info->options_len = sizeof(*md); ++ + /* skb can be uncloned in __iptunnel_pull_header, so + * old pkt_md is no longer valid and we need to reset + * it +@@ -543,7 +547,6 @@ static int ip6erspan_rcv(struct sk_buff + skb_network_header_len(skb); + pkt_md = (struct erspan_metadata *)(gh + gre_hdr_len + + sizeof(*ershdr)); +- info = &tun_dst->u.tun_info; + md = ip_tunnel_info_opts(info); + md->version = ver; + md2 = &md->u.md2; +@@ -551,7 +554,6 @@ static int ip6erspan_rcv(struct sk_buff + ERSPAN_V2_MDSIZE); + __set_bit(IP_TUNNEL_ERSPAN_OPT_BIT, + info->key.tun_flags); +- info->options_len = sizeof(*md); + + ip6_tnl_rcv(tunnel, skb, tpi, tun_dst, log_ecn_error); + diff --git a/queue-6.18/fjes-add-missing-iounmap-in-fjes_hw_init.patch b/queue-6.18/fjes-add-missing-iounmap-in-fjes_hw_init.patch new file mode 100644 index 0000000000..6428d994dc --- /dev/null +++ b/queue-6.18/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.18/gve-defer-interrupt-enabling-until-napi-registration.patch b/queue-6.18/gve-defer-interrupt-enabling-until-napi-registration.patch new file mode 100644 index 0000000000..66d94c9611 --- /dev/null +++ b/queue-6.18/gve-defer-interrupt-enabling-until-napi-registration.patch @@ -0,0 +1,74 @@ +From 3d970eda003441f66551a91fda16478ac0711617 Mon Sep 17 00:00:00 2001 +From: Ankit Garg +Date: Fri, 19 Dec 2025 10:29:45 +0000 +Subject: gve: defer interrupt enabling until NAPI registration + +From: Ankit Garg + +commit 3d970eda003441f66551a91fda16478ac0711617 upstream. + +Currently, interrupts are automatically enabled immediately upon +request. This allows interrupt to fire before the associated NAPI +context is fully initialized and cause failures like below: + +[ 0.946369] Call Trace: +[ 0.946369] +[ 0.946369] __napi_poll+0x2a/0x1e0 +[ 0.946369] net_rx_action+0x2f9/0x3f0 +[ 0.946369] handle_softirqs+0xd6/0x2c0 +[ 0.946369] ? handle_edge_irq+0xc1/0x1b0 +[ 0.946369] __irq_exit_rcu+0xc3/0xe0 +[ 0.946369] common_interrupt+0x81/0xa0 +[ 0.946369] +[ 0.946369] +[ 0.946369] asm_common_interrupt+0x22/0x40 +[ 0.946369] RIP: 0010:pv_native_safe_halt+0xb/0x10 + +Use the `IRQF_NO_AUTOEN` flag when requesting interrupts to prevent auto +enablement and explicitly enable the interrupt in NAPI initialization +path (and disable it during NAPI teardown). + +This ensures that interrupt lifecycle is strictly coupled with +readiness of NAPI context. + +Cc: stable@vger.kernel.org +Fixes: 1dfc2e46117e ("gve: Refactor napi add and remove functions") +Signed-off-by: Ankit Garg +Reviewed-by: Jordan Rhee +Reviewed-by: Joshua Washington +Signed-off-by: Harshitha Ramamurthy +Link: https://patch.msgid.link/20251219102945.2193617-1-hramamurthy@google.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/google/gve/gve_main.c | 2 +- + drivers/net/ethernet/google/gve/gve_utils.c | 2 ++ + 2 files changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/net/ethernet/google/gve/gve_main.c ++++ b/drivers/net/ethernet/google/gve/gve_main.c +@@ -558,7 +558,7 @@ static int gve_alloc_notify_blocks(struc + block->priv = priv; + err = request_irq(priv->msix_vectors[msix_idx].vector, + gve_is_gqi(priv) ? gve_intr : gve_intr_dqo, +- 0, block->name, block); ++ IRQF_NO_AUTOEN, block->name, block); + if (err) { + dev_err(&priv->pdev->dev, + "Failed to receive msix vector %d\n", i); +--- a/drivers/net/ethernet/google/gve/gve_utils.c ++++ b/drivers/net/ethernet/google/gve/gve_utils.c +@@ -112,11 +112,13 @@ void gve_add_napi(struct gve_priv *priv, + + netif_napi_add_locked(priv->dev, &block->napi, gve_poll); + netif_napi_set_irq_locked(&block->napi, block->irq); ++ enable_irq(block->irq); + } + + void gve_remove_napi(struct gve_priv *priv, int ntfy_idx) + { + struct gve_notify_block *block = &priv->ntfy_blocks[ntfy_idx]; + ++ disable_irq(block->irq); + netif_napi_del_locked(&block->napi); + } diff --git a/queue-6.18/idr-fix-idr_alloc-returning-an-id-out-of-range.patch b/queue-6.18/idr-fix-idr_alloc-returning-an-id-out-of-range.patch new file mode 100644 index 0000000000..eed5f4bc0e --- /dev/null +++ b/queue-6.18/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.18/kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch b/queue-6.18/kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch new file mode 100644 index 0000000000..cd32878a1c --- /dev/null +++ b/queue-6.18/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 +@@ -615,6 +615,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, +@@ -639,6 +649,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 +@@ -28,6 +28,7 @@ + #include + #include + #include ++#include + + #include "kasan.h" + #include "../slab.h" +@@ -582,3 +583,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 +@@ -4872,9 +4872,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.18/kasan-unpoison-vms-addresses-with-a-common-tag.patch b/queue-6.18/kasan-unpoison-vms-addresses-with-a-common-tag.patch new file mode 100644 index 0000000000..7843a2916a --- /dev/null +++ b/queue-6.18/kasan-unpoison-vms-addresses-with-a-common-tag.patch @@ -0,0 +1,85 @@ +From 6a0e5b333842cf65d6f4e4f0a2a4386504802515 Mon Sep 17 00:00:00 2001 +From: Maciej Wieczor-Retman +Date: Thu, 4 Dec 2025 19:00:11 +0000 +Subject: kasan: unpoison vms[area] addresses with a common tag + +From: Maciej Wieczor-Retman + +commit 6a0e5b333842cf65d6f4e4f0a2a4386504802515 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. + +Use the new vmalloc flag that disables random tag assignment in +__kasan_unpoison_vmalloc() - pass the same random tag to all the +vm_structs by tagging the pointers before they go inside +__kasan_unpoison_vmalloc(). Assigning a common tag resolves the pcpu +chunk address mismatch. + +[akpm@linux-foundation.org: use WARN_ON_ONCE(), per Andrey] + Link: https://lkml.kernel.org/r/CA+fCnZeuGdKSEm11oGT6FS71_vGq1vjq-xY36kxVdFvwmag2ZQ@mail.gmail.com +[maciej.wieczor-retman@intel.com: remove unneeded pr_warn()] + Link: https://lkml.kernel.org/r/919897daaaa3c982a27762a2ee038769ad033991.1764945396.git.m.wieczorretman@pm.me +Link: https://lkml.kernel.org/r/873821114a9f722ffb5d6702b94782e902883fdf.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 +--- + mm/kasan/common.c | 21 ++++++++++++++++++--- + 1 file changed, 18 insertions(+), 3 deletions(-) + +--- a/mm/kasan/common.c ++++ b/mm/kasan/common.c +@@ -591,11 +591,26 @@ void __kasan_unpoison_vmap_areas(struct + unsigned long size; + void *addr; + int area; ++ u8 tag; + +- for (area = 0 ; area < nr_vms ; area++) { ++ /* ++ * If KASAN_VMALLOC_KEEP_TAG was set at this point, all vms[] pointers ++ * would be unpoisoned with the KASAN_TAG_KERNEL which would disable ++ * KASAN checks down the line. ++ */ ++ if (WARN_ON_ONCE(flags & KASAN_VMALLOC_KEEP_TAG)) ++ return; ++ ++ size = vms[0]->size; ++ addr = vms[0]->addr; ++ vms[0]->addr = __kasan_unpoison_vmalloc(addr, size, flags); ++ tag = get_tag(vms[0]->addr); ++ ++ for (area = 1 ; area < nr_vms ; area++) { + size = vms[area]->size; +- addr = vms[area]->addr; +- vms[area]->addr = __kasan_unpoison_vmalloc(addr, size, flags); ++ addr = set_tag(vms[area]->addr, tag); ++ vms[area]->addr = ++ __kasan_unpoison_vmalloc(addr, size, flags | KASAN_VMALLOC_KEEP_TAG); + } + } + #endif diff --git a/queue-6.18/kernel-kexec-change-the-prototype-of-kimage_map_segment.patch b/queue-6.18/kernel-kexec-change-the-prototype-of-kimage_map_segment.patch new file mode 100644 index 0000000000..2def5c7892 --- /dev/null +++ b/queue-6.18/kernel-kexec-change-the-prototype-of-kimage_map_segment.patch @@ -0,0 +1,90 @@ +From fe55ea85939efcbf0e6baa234f0d70acb79e7b58 Mon Sep 17 00:00:00 2001 +From: Pingfan Liu +Date: Tue, 16 Dec 2025 09:48:51 +0800 +Subject: kernel/kexec: change the prototype of kimage_map_segment() + +From: Pingfan Liu + +commit fe55ea85939efcbf0e6baa234f0d70acb79e7b58 upstream. + +The kexec segment index will be required to extract the corresponding +information for that segment in kimage_map_segment(). Additionally, +kexec_segment already holds the kexec relocation destination address and +size. Therefore, the prototype of kimage_map_segment() can be changed. + +Link: https://lkml.kernel.org/r/20251216014852.8737-1-piliu@redhat.com +Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation") +Signed-off-by: Pingfan Liu +Acked-by: Baoquan He +Cc: Mimi Zohar +Cc: Roberto Sassu +Cc: Alexander Graf +Cc: Steven Chen +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/kexec.h | 4 ++-- + kernel/kexec_core.c | 9 ++++++--- + security/integrity/ima/ima_kexec.c | 4 +--- + 3 files changed, 9 insertions(+), 8 deletions(-) + +--- a/include/linux/kexec.h ++++ b/include/linux/kexec.h +@@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print; + #define kexec_dprintk(fmt, arg...) \ + do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0) + +-extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size); ++extern void *kimage_map_segment(struct kimage *image, int idx); + extern void kimage_unmap_segment(void *buffer); + #else /* !CONFIG_KEXEC_CORE */ + struct pt_regs; +@@ -540,7 +540,7 @@ static inline void __crash_kexec(struct + static inline void crash_kexec(struct pt_regs *regs) { } + static inline int kexec_should_crash(struct task_struct *p) { return 0; } + static inline int kexec_crash_loaded(void) { return 0; } +-static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size) ++static inline void *kimage_map_segment(struct kimage *image, int idx) + { return NULL; } + static inline void kimage_unmap_segment(void *buffer) { } + #define kexec_in_progress false +--- a/kernel/kexec_core.c ++++ b/kernel/kexec_core.c +@@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *i + return result; + } + +-void *kimage_map_segment(struct kimage *image, +- unsigned long addr, unsigned long size) ++void *kimage_map_segment(struct kimage *image, int idx) + { ++ unsigned long addr, size, eaddr; + unsigned long src_page_addr, dest_page_addr = 0; +- unsigned long eaddr = addr + size; + kimage_entry_t *ptr, entry; + struct page **src_pages; + unsigned int npages; + void *vaddr = NULL; + int i; + ++ addr = image->segment[idx].mem; ++ size = image->segment[idx].memsz; ++ eaddr = addr + size; ++ + /* + * Collect the source pages and map them in a contiguous VA range. + */ +--- a/security/integrity/ima/ima_kexec.c ++++ b/security/integrity/ima/ima_kexec.c +@@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage * + if (!image->ima_buffer_addr) + return; + +- ima_kexec_buffer = kimage_map_segment(image, +- image->ima_buffer_addr, +- image->ima_buffer_size); ++ ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index); + if (!ima_kexec_buffer) { + pr_err("Could not map measurements buffer.\n"); + return; diff --git a/queue-6.18/kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch b/queue-6.18/kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch new file mode 100644 index 0000000000..efebbb7240 --- /dev/null +++ b/queue-6.18/kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch @@ -0,0 +1,87 @@ +From a3785ae5d334bb71d47a593d54c686a03fb9d136 Mon Sep 17 00:00:00 2001 +From: Pingfan Liu +Date: Tue, 16 Dec 2025 09:48:52 +0800 +Subject: kernel/kexec: fix IMA when allocation happens in CMA area + +From: Pingfan Liu + +commit a3785ae5d334bb71d47a593d54c686a03fb9d136 upstream. + +*** Bug description *** + +When I tested kexec with the latest kernel, I ran into the following warning: + +[ 40.712410] ------------[ cut here ]------------ +[ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 +[...] +[ 40.816047] Call trace: +[ 40.818498] kimage_map_segment+0x144/0x198 (P) +[ 40.823221] ima_kexec_post_load+0x58/0xc0 +[ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 +[...] +[ 40.855423] ---[ end trace 0000000000000000 ]--- + +*** How to reproduce *** + +This bug is only triggered when the kexec target address is allocated in +the CMA area. If no CMA area is reserved in the kernel, use the "cma=" +option in the kernel command line to reserve one. + +*** Root cause *** +The commit 07d24902977e ("kexec: enable CMA based contiguous +allocation") allocates the kexec target address directly on the CMA area +to avoid copying during the jump. In this case, there is no IND_SOURCE +for the kexec segment. But the current implementation of +kimage_map_segment() assumes that IND_SOURCE pages exist and map them +into a contiguous virtual address by vmap(). + +*** Solution *** +If IMA segment is allocated in the CMA area, use its page_address() +directly. + +Link: https://lkml.kernel.org/r/20251216014852.8737-2-piliu@redhat.com +Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation") +Signed-off-by: Pingfan Liu +Acked-by: Baoquan He +Cc: Alexander Graf +Cc: Steven Chen +Cc: Mimi Zohar +Cc: Roberto Sassu +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + kernel/kexec_core.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/kernel/kexec_core.c ++++ b/kernel/kexec_core.c +@@ -967,13 +967,17 @@ void *kimage_map_segment(struct kimage * + kimage_entry_t *ptr, entry; + struct page **src_pages; + unsigned int npages; ++ struct page *cma; + void *vaddr = NULL; + int i; + ++ cma = image->segment_cma[idx]; ++ if (cma) ++ return page_address(cma); ++ + addr = image->segment[idx].mem; + size = image->segment[idx].memsz; + eaddr = addr + size; +- + /* + * Collect the source pages and map them in a contiguous VA range. + */ +@@ -1014,7 +1018,8 @@ void *kimage_map_segment(struct kimage * + + void kimage_unmap_segment(void *segment_buffer) + { +- vunmap(segment_buffer); ++ if (is_vmalloc_addr(segment_buffer)) ++ vunmap(segment_buffer); + } + + struct kexec_load_limit { diff --git a/queue-6.18/lockd-fix-vfs_test_lock-calls.patch b/queue-6.18/lockd-fix-vfs_test_lock-calls.patch new file mode 100644 index 0000000000..9a7ce64e11 --- /dev/null +++ b/queue-6.18/lockd-fix-vfs_test_lock-calls.patch @@ -0,0 +1,176 @@ +From a49a2a1baa0c553c3548a1c414b6a3c005a8deba Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Sat, 22 Nov 2025 12:00:36 +1100 +Subject: lockd: fix vfs_test_lock() calls + +From: NeilBrown + +commit a49a2a1baa0c553c3548a1c414b6a3c005a8deba upstream. + +Usage of vfs_test_lock() is somewhat confused. Documentation suggests +it is given a "lock" but this is not the case. It is given a struct +file_lock which contains some details of the sort of lock it should be +looking for. + +In particular passing a "file_lock" containing fl_lmops or fl_ops is +meaningless and possibly confusing. + +This is particularly problematic in lockd. nlmsvc_testlock() receives +an initialised "file_lock" from xdr-decode, including manager ops and an +owner. It then mistakenly passes this to vfs_test_lock() which might +replace the owner and the ops. This can lead to confusion when freeing +the lock. + +The primary role of the 'struct file_lock' passed to vfs_test_lock() is +to report a conflicting lock that was found, so it makes more sense for +nlmsvc_testlock() to pass "conflock", which it uses for returning the +conflicting lock. + +With this change, freeing of the lock is not confused and code in +__nlm4svc_proc_test() and __nlmsvc_proc_test() can be simplified. + +Documentation for vfs_test_lock() is improved to reflect its real +purpose, and a WARN_ON_ONCE() is added to avoid a similar problem in the +future. + +Reported-by: Olga Kornievskaia +Closes: https://lore.kernel.org/all/20251021130506.45065-1-okorniev@redhat.com +Signed-off-by: NeilBrown +Fixes: 20fa19027286 ("nfs: add export operations") +Cc: stable@vger.kernel.org +Reviewed-by: Jeff Layton +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + fs/lockd/svc4proc.c | 4 +--- + fs/lockd/svclock.c | 21 ++++++++++++--------- + fs/lockd/svcproc.c | 5 +---- + fs/locks.c | 12 ++++++++++-- + 4 files changed, 24 insertions(+), 18 deletions(-) + +--- a/fs/lockd/svc4proc.c ++++ b/fs/lockd/svc4proc.c +@@ -97,7 +97,6 @@ __nlm4svc_proc_test(struct svc_rqst *rqs + struct nlm_args *argp = rqstp->rq_argp; + struct nlm_host *host; + struct nlm_file *file; +- struct nlm_lockowner *test_owner; + __be32 rc = rpc_success; + + dprintk("lockd: TEST4 called\n"); +@@ -107,7 +106,6 @@ __nlm4svc_proc_test(struct svc_rqst *rqs + if ((resp->status = nlm4svc_retrieve_args(rqstp, argp, &host, &file))) + return resp->status == nlm_drop_reply ? rpc_drop_reply :rpc_success; + +- test_owner = argp->lock.fl.c.flc_owner; + /* Now check for conflicting locks */ + resp->status = nlmsvc_testlock(rqstp, file, host, &argp->lock, + &resp->lock); +@@ -116,7 +114,7 @@ __nlm4svc_proc_test(struct svc_rqst *rqs + else + dprintk("lockd: TEST4 status %d\n", ntohl(resp->status)); + +- nlmsvc_put_lockowner(test_owner); ++ nlmsvc_release_lockowner(&argp->lock); + nlmsvc_release_host(host); + nlm_release_file(file); + return rc; +--- a/fs/lockd/svclock.c ++++ b/fs/lockd/svclock.c +@@ -627,7 +627,13 @@ nlmsvc_testlock(struct svc_rqst *rqstp, + } + + mode = lock_to_openmode(&lock->fl); +- error = vfs_test_lock(file->f_file[mode], &lock->fl); ++ locks_init_lock(&conflock->fl); ++ /* vfs_test_lock only uses start, end, and owner, but tests flc_file */ ++ conflock->fl.c.flc_file = lock->fl.c.flc_file; ++ conflock->fl.fl_start = lock->fl.fl_start; ++ conflock->fl.fl_end = lock->fl.fl_end; ++ conflock->fl.c.flc_owner = lock->fl.c.flc_owner; ++ error = vfs_test_lock(file->f_file[mode], &conflock->fl); + if (error) { + /* We can't currently deal with deferred test requests */ + if (error == FILE_LOCK_DEFERRED) +@@ -637,22 +643,19 @@ nlmsvc_testlock(struct svc_rqst *rqstp, + goto out; + } + +- if (lock->fl.c.flc_type == F_UNLCK) { ++ if (conflock->fl.c.flc_type == F_UNLCK) { + ret = nlm_granted; + goto out; + } + + dprintk("lockd: conflicting lock(ty=%d, %Ld-%Ld)\n", +- lock->fl.c.flc_type, (long long)lock->fl.fl_start, +- (long long)lock->fl.fl_end); ++ conflock->fl.c.flc_type, (long long)conflock->fl.fl_start, ++ (long long)conflock->fl.fl_end); + conflock->caller = "somehost"; /* FIXME */ + conflock->len = strlen(conflock->caller); + conflock->oh.len = 0; /* don't return OH info */ +- conflock->svid = lock->fl.c.flc_pid; +- conflock->fl.c.flc_type = lock->fl.c.flc_type; +- conflock->fl.fl_start = lock->fl.fl_start; +- conflock->fl.fl_end = lock->fl.fl_end; +- locks_release_private(&lock->fl); ++ conflock->svid = conflock->fl.c.flc_pid; ++ locks_release_private(&conflock->fl); + + ret = nlm_lck_denied; + out: +--- a/fs/lockd/svcproc.c ++++ b/fs/lockd/svcproc.c +@@ -117,7 +117,6 @@ __nlmsvc_proc_test(struct svc_rqst *rqst + struct nlm_args *argp = rqstp->rq_argp; + struct nlm_host *host; + struct nlm_file *file; +- struct nlm_lockowner *test_owner; + __be32 rc = rpc_success; + + dprintk("lockd: TEST called\n"); +@@ -127,8 +126,6 @@ __nlmsvc_proc_test(struct svc_rqst *rqst + if ((resp->status = nlmsvc_retrieve_args(rqstp, argp, &host, &file))) + return resp->status == nlm_drop_reply ? rpc_drop_reply :rpc_success; + +- test_owner = argp->lock.fl.c.flc_owner; +- + /* Now check for conflicting locks */ + resp->status = cast_status(nlmsvc_testlock(rqstp, file, host, + &argp->lock, &resp->lock)); +@@ -138,7 +135,7 @@ __nlmsvc_proc_test(struct svc_rqst *rqst + dprintk("lockd: TEST status %d vers %d\n", + ntohl(resp->status), rqstp->rq_vers); + +- nlmsvc_put_lockowner(test_owner); ++ nlmsvc_release_lockowner(&argp->lock); + nlmsvc_release_host(host); + nlm_release_file(file); + return rc; +--- a/fs/locks.c ++++ b/fs/locks.c +@@ -2185,13 +2185,21 @@ SYSCALL_DEFINE2(flock, unsigned int, fd, + /** + * vfs_test_lock - test file byte range lock + * @filp: The file to test lock for +- * @fl: The lock to test; also used to hold result ++ * @fl: The byte-range in the file to test; also used to hold result + * ++ * On entry, @fl does not contain a lock, but identifies a range (fl_start, fl_end) ++ * in the file (c.flc_file), and an owner (c.flc_owner) for whom existing locks ++ * should be ignored. c.flc_type and c.flc_flags are ignored. ++ * Both fl_lmops and fl_ops in @fl must be NULL. + * Returns -ERRNO on failure. Indicates presence of conflicting lock by +- * setting conf->fl_type to something other than F_UNLCK. ++ * setting fl->fl_type to something other than F_UNLCK. ++ * ++ * If vfs_test_lock() does find a lock and return it, the caller must ++ * use locks_free_lock() or locks_release_private() on the returned lock. + */ + int vfs_test_lock(struct file *filp, struct file_lock *fl) + { ++ WARN_ON_ONCE(fl->fl_ops || fl->fl_lmops); + WARN_ON_ONCE(filp != fl->c.flc_file); + if (filp->f_op->lock) + return filp->f_op->lock(filp, F_GETLK, fl); diff --git a/queue-6.18/loongarch-bpf-adjust-the-jump-offset-of-tail-calls.patch b/queue-6.18/loongarch-bpf-adjust-the-jump-offset-of-tail-calls.patch new file mode 100644 index 0000000000..83b8948eca --- /dev/null +++ b/queue-6.18/loongarch-bpf-adjust-the-jump-offset-of-tail-calls.patch @@ -0,0 +1,39 @@ +From 61319d15a56093358c6822d30659fe2941f589f1 Mon Sep 17 00:00:00 2001 +From: Chenghao Duan +Date: Wed, 31 Dec 2025 15:19:21 +0800 +Subject: LoongArch: BPF: Adjust the jump offset of tail calls + +From: Chenghao Duan + +commit 61319d15a56093358c6822d30659fe2941f589f1 upstream. + +Call the next bpf prog and skip the first instruction of TCC +initialization. + +A total of 7 instructions are skipped: +'move t0, ra' 1 inst +'move_imm + jirl' 5 inst +'addid REG_TCC, zero, 0' 1 inst + +Relevant test cases: the tailcalls test item in selftests/bpf. + +Cc: stable@vger.kernel.org +Fixes: 677e6123e3d2 ("LoongArch: BPF: Disable trampoline for kernel module function trace") +Signed-off-by: Chenghao Duan +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/net/bpf_jit.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/loongarch/net/bpf_jit.c ++++ b/arch/loongarch/net/bpf_jit.c +@@ -239,7 +239,7 @@ static void __build_epilogue(struct jit_ + * Call the next bpf prog and skip the first instruction + * of TCC initialization. + */ +- emit_insn(ctx, jirl, LOONGARCH_GPR_ZERO, LOONGARCH_GPR_T3, 6); ++ emit_insn(ctx, jirl, LOONGARCH_GPR_ZERO, LOONGARCH_GPR_T3, 7); + } + } + diff --git a/queue-6.18/loongarch-bpf-enable-trampoline-based-tracing-for-module-functions.patch b/queue-6.18/loongarch-bpf-enable-trampoline-based-tracing-for-module-functions.patch new file mode 100644 index 0000000000..86bb3aa210 --- /dev/null +++ b/queue-6.18/loongarch-bpf-enable-trampoline-based-tracing-for-module-functions.patch @@ -0,0 +1,83 @@ +From 26138762d9a27a7f1c33f467c4123c600f64a36e Mon Sep 17 00:00:00 2001 +From: Chenghao Duan +Date: Wed, 31 Dec 2025 15:19:21 +0800 +Subject: LoongArch: BPF: Enable trampoline-based tracing for module functions + +From: Chenghao Duan + +commit 26138762d9a27a7f1c33f467c4123c600f64a36e upstream. + +Remove the previous restrictions that blocked the tracing of kernel +module functions. Fix the issue that previously caused kernel lockups +when attempting to trace module functions. + +Before entering the trampoline code, the return address register ra +shall store the address of the next assembly instruction after the +'bl trampoline' instruction, which is the traced function address, and +the register t0 shall store the parent function return address. Refine +the trampoline return logic to ensure that register data remains correct +when returning to both the traced function and the parent function. + +Before this patch was applied, the module_attach test in selftests/bpf +encountered a deadlock issue. This was caused by an incorrect jump +address after the trampoline execution, which resulted in an infinite +loop within the module function. + +Cc: stable@vger.kernel.org +Fixes: 677e6123e3d2 ("LoongArch: BPF: Disable trampoline for kernel module function trace") +Signed-off-by: Chenghao Duan +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/net/bpf_jit.c | 20 +++++++++++--------- + 1 file changed, 11 insertions(+), 9 deletions(-) + +--- a/arch/loongarch/net/bpf_jit.c ++++ b/arch/loongarch/net/bpf_jit.c +@@ -1284,7 +1284,7 @@ static int emit_jump_or_nops(void *targe + return 0; + } + +- return emit_jump_and_link(&ctx, is_call ? LOONGARCH_GPR_T0 : LOONGARCH_GPR_ZERO, (u64)target); ++ return emit_jump_and_link(&ctx, is_call ? LOONGARCH_GPR_RA : LOONGARCH_GPR_ZERO, (u64)target); + } + + static int emit_call(struct jit_ctx *ctx, u64 addr) +@@ -1638,14 +1638,12 @@ static int __arch_prepare_bpf_trampoline + + /* To traced function */ + /* Ftrace jump skips 2 NOP instructions */ +- if (is_kernel_text((unsigned long)orig_call)) ++ if (is_kernel_text((unsigned long)orig_call) || ++ is_module_text_address((unsigned long)orig_call)) + orig_call += LOONGARCH_FENTRY_NBYTES; + /* Direct jump skips 5 NOP instructions */ + else if (is_bpf_text_address((unsigned long)orig_call)) + orig_call += LOONGARCH_BPF_FENTRY_NBYTES; +- /* Module tracing not supported - cause kernel lockups */ +- else if (is_module_text_address((unsigned long)orig_call)) +- return -ENOTSUPP; + + if (flags & BPF_TRAMP_F_CALL_ORIG) { + move_addr(ctx, LOONGARCH_GPR_A0, (const u64)im); +@@ -1738,12 +1736,16 @@ static int __arch_prepare_bpf_trampoline + emit_insn(ctx, ldd, LOONGARCH_GPR_FP, LOONGARCH_GPR_SP, 0); + emit_insn(ctx, addid, LOONGARCH_GPR_SP, LOONGARCH_GPR_SP, 16); + +- if (flags & BPF_TRAMP_F_SKIP_FRAME) ++ if (flags & BPF_TRAMP_F_SKIP_FRAME) { + /* return to parent function */ +- emit_insn(ctx, jirl, LOONGARCH_GPR_ZERO, LOONGARCH_GPR_RA, 0); +- else +- /* return to traced function */ ++ move_reg(ctx, LOONGARCH_GPR_RA, LOONGARCH_GPR_T0); + emit_insn(ctx, jirl, LOONGARCH_GPR_ZERO, LOONGARCH_GPR_T0, 0); ++ } else { ++ /* return to traced function */ ++ move_reg(ctx, LOONGARCH_GPR_T1, LOONGARCH_GPR_RA); ++ move_reg(ctx, LOONGARCH_GPR_RA, LOONGARCH_GPR_T0); ++ emit_insn(ctx, jirl, LOONGARCH_GPR_ZERO, LOONGARCH_GPR_T1, 0); ++ } + } + + ret = ctx->idx; diff --git a/queue-6.18/loongarch-bpf-save-return-address-register-ra-to-t0-before-trampoline.patch b/queue-6.18/loongarch-bpf-save-return-address-register-ra-to-t0-before-trampoline.patch new file mode 100644 index 0000000000..7779ed4081 --- /dev/null +++ b/queue-6.18/loongarch-bpf-save-return-address-register-ra-to-t0-before-trampoline.patch @@ -0,0 +1,34 @@ +From d314e1f48260cef3f869e3edc02a02c8a48b08e1 Mon Sep 17 00:00:00 2001 +From: Chenghao Duan +Date: Wed, 31 Dec 2025 15:19:20 +0800 +Subject: LoongArch: BPF: Save return address register ra to t0 before trampoline + +From: Chenghao Duan + +commit d314e1f48260cef3f869e3edc02a02c8a48b08e1 upstream. + +Modify the build_prologue() function to ensure the return address +register ra is saved to t0 before entering trampoline operations. +This change ensures the accurate return address handling when a BPF +program calls another BPF program, preventing errors in the BPF-to-BPF +call chain. + +Cc: stable@vger.kernel.org +Fixes: 677e6123e3d2 ("LoongArch: BPF: Disable trampoline for kernel module function trace") +Signed-off-by: Chenghao Duan +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/net/bpf_jit.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/loongarch/net/bpf_jit.c ++++ b/arch/loongarch/net/bpf_jit.c +@@ -139,6 +139,7 @@ static void build_prologue(struct jit_ct + stack_adjust = round_up(stack_adjust, 16); + stack_adjust += bpf_stack_adjust; + ++ move_reg(ctx, LOONGARCH_GPR_T0, LOONGARCH_GPR_RA); + /* Reserve space for the move_imm + jirl instruction */ + for (i = 0; i < LOONGARCH_LONG_JUMP_NINSNS; i++) + emit_insn(ctx, nop); diff --git a/queue-6.18/loongarch-bpf-sign-extend-kfunc-call-arguments.patch b/queue-6.18/loongarch-bpf-sign-extend-kfunc-call-arguments.patch new file mode 100644 index 0000000000..04991e768c --- /dev/null +++ b/queue-6.18/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 +@@ -952,6 +952,22 @@ static int build_insn(const struct bpf_i + emit_insn(ctx, ldd, REG_TCC, LOONGARCH_GPR_SP, tcc_ptr_off); + } + ++ 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, LOONGARCH_GPR_RA, t1, 0); + +--- a/arch/loongarch/net/bpf_jit.h ++++ b/arch/loongarch/net/bpf_jit.h +@@ -88,6 +88,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.18/loongarch-bpf-zero-extend-bpf_tail_call-index.patch b/queue-6.18/loongarch-bpf-zero-extend-bpf_tail_call-index.patch new file mode 100644 index 0000000000..3586703439 --- /dev/null +++ b/queue-6.18/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 +@@ -280,6 +280,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.18/loongarch-refactor-register-restoration-in-ftrace_common_return.patch b/queue-6.18/loongarch-refactor-register-restoration-in-ftrace_common_return.patch new file mode 100644 index 0000000000..7e183c4fa4 --- /dev/null +++ b/queue-6.18/loongarch-refactor-register-restoration-in-ftrace_common_return.patch @@ -0,0 +1,75 @@ +From 45cb47c628dfbd1994c619f3eac271a780602826 Mon Sep 17 00:00:00 2001 +From: Chenghao Duan +Date: Wed, 31 Dec 2025 15:19:20 +0800 +Subject: LoongArch: Refactor register restoration in ftrace_common_return + +From: Chenghao Duan + +commit 45cb47c628dfbd1994c619f3eac271a780602826 upstream. + +Refactor the register restoration sequence in the ftrace_common_return +function to clearly distinguish between the logic of normal returns and +direct call returns in function tracing scenarios. The logic is as +follows: + +1. In the case of a normal return, the execution flow returns to the +traced function, and ftrace must ensure that the register data is +consistent with the state when the function was entered. + +ra = parent return address; t0 = traced function return address. + +2. In the case of a direct call return, the execution flow jumps to the +custom trampoline function, and ftrace must ensure that the register +data is consistent with the state when ftrace was entered. + +ra = traced function return address; t0 = parent return address. + +Cc: stable@vger.kernel.org +Fixes: 9cdc3b6a299c ("LoongArch: ftrace: Add direct call support") +Signed-off-by: Chenghao Duan +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kernel/mcount_dyn.S | 14 ++++++++++---- + 1 file changed, 10 insertions(+), 4 deletions(-) + +--- a/arch/loongarch/kernel/mcount_dyn.S ++++ b/arch/loongarch/kernel/mcount_dyn.S +@@ -94,7 +94,6 @@ SYM_INNER_LABEL(ftrace_graph_call, SYM_L + * at the callsite, so there is no need to restore the T series regs. + */ + ftrace_common_return: +- PTR_L ra, sp, PT_R1 + PTR_L a0, sp, PT_R4 + PTR_L a1, sp, PT_R5 + PTR_L a2, sp, PT_R6 +@@ -104,12 +103,17 @@ ftrace_common_return: + PTR_L a6, sp, PT_R10 + PTR_L a7, sp, PT_R11 + PTR_L fp, sp, PT_R22 +- PTR_L t0, sp, PT_ERA + PTR_L t1, sp, PT_R13 +- PTR_ADDI sp, sp, PT_SIZE + bnez t1, .Ldirect ++ ++ PTR_L ra, sp, PT_R1 ++ PTR_L t0, sp, PT_ERA ++ PTR_ADDI sp, sp, PT_SIZE + jr t0 + .Ldirect: ++ PTR_L t0, sp, PT_R1 ++ PTR_L ra, sp, PT_ERA ++ PTR_ADDI sp, sp, PT_SIZE + jr t1 + SYM_CODE_END(ftrace_common) + +@@ -161,6 +165,8 @@ SYM_CODE_END(return_to_handler) + #ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS + SYM_CODE_START(ftrace_stub_direct_tramp) + UNWIND_HINT_UNDEFINED +- jr t0 ++ move t1, ra ++ move ra, t0 ++ jr t1 + SYM_CODE_END(ftrace_stub_direct_tramp) + #endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */ diff --git a/queue-6.18/mm-consider-non-anon-swap-cache-folios-in-folio_expected_ref_count.patch b/queue-6.18/mm-consider-non-anon-swap-cache-folios-in-folio_expected_ref_count.patch new file mode 100644 index 0000000000..67e5823676 --- /dev/null +++ b/queue-6.18/mm-consider-non-anon-swap-cache-folios-in-folio_expected_ref_count.patch @@ -0,0 +1,116 @@ +From f183663901f21fe0fba8bd31ae894bc529709ee0 Mon Sep 17 00:00:00 2001 +From: Bijan Tabatabai +Date: Tue, 16 Dec 2025 14:07:27 -0600 +Subject: mm: consider non-anon swap cache folios in folio_expected_ref_count() + +From: Bijan Tabatabai + +commit f183663901f21fe0fba8bd31ae894bc529709ee0 upstream. + +Currently, folio_expected_ref_count() only adds references for the swap +cache if the folio is anonymous. However, according to the comment above +the definition of PG_swapcache in enum pageflags, shmem folios can also +have PG_swapcache set. This patch makes sure references for the swap +cache are added if folio_test_swapcache(folio) is true. + +This issue was found when trying to hot-unplug memory in a QEMU/KVM +virtual machine. When initiating hot-unplug when most of the guest memory +is allocated, hot-unplug hangs partway through removal due to migration +failures. The following message would be printed several times, and would +be printed again about every five seconds: + +[ 49.641309] migrating pfn b12f25 failed ret:7 +[ 49.641310] page: refcount:2 mapcount:0 mapping:0000000033bd8fe2 index:0x7f404d925 pfn:0xb12f25 +[ 49.641311] aops:swap_aops +[ 49.641313] flags: 0x300000000030508(uptodate|active|owner_priv_1|reclaim|swapbacked|node=0|zone=3) +[ 49.641314] raw: 0300000000030508 ffffed312c4bc908 ffffed312c4bc9c8 0000000000000000 +[ 49.641315] raw: 00000007f404d925 00000000000c823b 00000002ffffffff 0000000000000000 +[ 49.641315] page dumped because: migration failure + +When debugging this, I found that these migration failures were due to +__migrate_folio() returning -EAGAIN for a small set of folios because the +expected reference count it calculates via folio_expected_ref_count() is +one less than the actual reference count of the folios. Furthermore, all +of the affected folios were not anonymous, but had the PG_swapcache flag +set, inspiring this patch. After applying this patch, the memory +hot-unplug behaves as expected. + +I tested this on a machine running Ubuntu 24.04 with kernel version +6.8.0-90-generic and 64GB of memory. The guest VM is managed by libvirt +and runs Ubuntu 24.04 with kernel version 6.18 (though the head of the +mm-unstable branch as a Dec 16, 2025 was also tested and behaves the same) +and 48GB of memory. The libvirt XML definition for the VM can be found at +[1]. CONFIG_MHP_DEFAULT_ONLINE_TYPE_ONLINE_MOVABLE is set in the guest +kernel so the hot-pluggable memory is automatically onlined. + +Below are the steps to reproduce this behavior: + +1) Define and start and virtual machine + host$ virsh -c qemu:///system define ./test_vm.xml # test_vm.xml from [1] + host$ virsh -c qemu:///system start test_vm + +2) Setup swap in the guest + guest$ sudo fallocate -l 32G /swapfile + guest$ sudo chmod 0600 /swapfile + guest$ sudo mkswap /swapfile + guest$ sudo swapon /swapfile + +3) Use alloc_data [2] to allocate most of the remaining guest memory + guest$ ./alloc_data 45 + +4) In a separate guest terminal, monitor the amount of used memory + guest$ watch -n1 free -h + +5) When alloc_data has finished allocating, initiate the memory +hot-unplug using the provided xml file [3] + host$ virsh -c qemu:///system detach-device test_vm ./remove.xml --live + +After initiating the memory hot-unplug, you should see the amount of +available memory in the guest decrease, and the amount of used swap data +increase. If everything works as expected, when all of the memory is +unplugged, there should be around 8.5-9GB of data in swap. If the +unplugging is unsuccessful, the amount of used swap data will settle below +that. If that happens, you should be able to see log messages in dmesg +similar to the one posted above. + +Link: https://lkml.kernel.org/r/20251216200727.2360228-1-bijan311@gmail.com +Link: https://github.com/BijanT/linux_patch_files/blob/main/test_vm.xml [1] +Link: https://github.com/BijanT/linux_patch_files/blob/main/alloc_data.c [2] +Link: https://github.com/BijanT/linux_patch_files/blob/main/remove.xml [3] +Fixes: 86ebd50224c0 ("mm: add folio_expected_ref_count() for reference count calculation") +Signed-off-by: Bijan Tabatabai +Acked-by: David Hildenbrand (Red Hat) +Acked-by: Zi Yan +Reviewed-by: Baolin Wang +Cc: Liam Howlett +Cc: Lorenzo Stoakes +Cc: Michal Hocko +Cc: Mike Rapoport +Cc: Shivank Garg +Cc: Suren Baghdasaryan +Cc: Vlastimil Babka +Cc: Kairui Song +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/mm.h | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/include/linux/mm.h ++++ b/include/linux/mm.h +@@ -2272,10 +2272,10 @@ static inline int folio_expected_ref_cou + if (WARN_ON_ONCE(page_has_type(&folio->page) && !folio_test_hugetlb(folio))) + return 0; + +- if (folio_test_anon(folio)) { +- /* One reference per page from the swapcache. */ +- ref_count += folio_test_swapcache(folio) << order; +- } else { ++ /* One reference per page from the swapcache. */ ++ ref_count += folio_test_swapcache(folio) << order; ++ ++ if (!folio_test_anon(folio)) { + /* One reference per page from the pagecache. */ + ref_count += !!folio->mapping << order; + /* One reference from PG_private. */ diff --git a/queue-6.18/mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch b/queue-6.18/mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch new file mode 100644 index 0000000000..4bb4e8561f --- /dev/null +++ b/queue-6.18/mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch @@ -0,0 +1,151 @@ +From 007f5da43b3d0ecff972e2616062b8da1f862f5e Mon Sep 17 00:00:00 2001 +From: Jiayuan Chen +Date: Thu, 4 Dec 2025 18:59:55 +0000 +Subject: mm/kasan: fix incorrect unpoisoning in vrealloc for KASAN + +From: Jiayuan Chen + +commit 007f5da43b3d0ecff972e2616062b8da1f862f5e upstream. + +Patch series "kasan: vmalloc: Fixes for the percpu allocator and +vrealloc", v3. + +Patches fix two issues related to KASAN and vmalloc. + +The first one, a KASAN tag mismatch, possibly resulting in a kernel panic, +can be observed on systems with a tag-based KASAN enabled and with +multiple NUMA nodes. Initially it was only noticed on x86 [1] but later a +similar issue was also reported on arm64 [2]. + +Specifically the problem is related to how vm_structs interact with +pcpu_chunks - both when they are allocated, assigned and when pcpu_chunk +addresses are derived. + +When vm_structs are allocated they are unpoisoned, each with a different +random tag, if vmalloc support is enabled along the KASAN mode. Later +when first pcpu chunk is allocated it gets its 'base_addr' field set to +the first allocated vm_struct. With that it inherits that vm_struct's +tag. + +When pcpu_chunk addresses are later derived (by pcpu_chunk_addr(), for +example in pcpu_alloc_noprof()) the base_addr field is used and offsets +are added to it. If the initial conditions are satisfied then some of the +offsets will point into memory allocated with a different vm_struct. So +while the lower bits will get accurately derived the tag bits in the top +of the pointer won't match the shadow memory contents. + +The solution (proposed at v2 of the x86 KASAN series [3]) is to unpoison +the vm_structs with the same tag when allocating them for the per cpu +allocator (in pcpu_get_vm_areas()). + +The second one reported by syzkaller [4] is related to vrealloc and +happens because of random tag generation when unpoisoning memory without +allocating new pages. This breaks shadow memory tracking and needs to +reuse the existing tag instead of generating a new one. At the same time +an inconsistency in used flags is corrected. + + +This patch (of 3): + +Syzkaller reported a memory out-of-bounds bug [4]. This patch fixes two +issues: + +1. In vrealloc the KASAN_VMALLOC_VM_ALLOC flag is missing when + unpoisoning the extended region. This flag is required to correctly + associate the allocation with KASAN's vmalloc tracking. + + Note: In contrast, vzalloc (via __vmalloc_node_range_noprof) + explicitly sets KASAN_VMALLOC_VM_ALLOC and calls + kasan_unpoison_vmalloc() with it. vrealloc must behave consistently -- + especially when reusing existing vmalloc regions -- to ensure KASAN can + track allocations correctly. + +2. When vrealloc reuses an existing vmalloc region (without allocating + new pages) KASAN generates a new tag, which breaks tag-based memory + access tracking. + +Introduce KASAN_VMALLOC_KEEP_TAG, a new KASAN flag that allows reusing the +tag already attached to the pointer, ensuring consistent tag behavior +during reallocation. + +Pass KASAN_VMALLOC_KEEP_TAG and KASAN_VMALLOC_VM_ALLOC to the +kasan_unpoison_vmalloc inside vrealloc_node_align_noprof(). + +Link: https://lkml.kernel.org/r/cover.1765978969.git.m.wieczorretman@pm.me +Link: https://lkml.kernel.org/r/38dece0a4074c43e48150d1e242f8242c73bf1a5.1764874575.git.m.wieczorretman@pm.me +Link: https://lore.kernel.org/all/e7e04692866d02e6d3b32bb43b998e5d17092ba4.1738686764.git.maciej.wieczor-retman@intel.com/ [1] +Link: https://lore.kernel.org/all/aMUrW1Znp1GEj7St@MiWiFi-R3L-srv/ [2] +Link: https://lore.kernel.org/all/CAPAsAGxDRv_uFeMYu9TwhBVWHCCtkSxoWY4xmFB_vowMbi8raw@mail.gmail.com/ [3] +Link: https://syzkaller.appspot.com/bug?extid=997752115a851cb0cf36 [4] +Fixes: a0309faf1cb0 ("mm: vmalloc: support more granular vrealloc() sizing") +Signed-off-by: Jiayuan Chen +Co-developed-by: Maciej Wieczor-Retman +Signed-off-by: Maciej Wieczor-Retman +Reported-by: syzbot+997752115a851cb0cf36@syzkaller.appspotmail.com +Closes: https://lore.kernel.org/all/68e243a2.050a0220.1696c6.007d.GAE@google.com/T/ +Reviewed-by: Andrey Konovalov +Cc: Alexander Potapenko +Cc: Andrey Ryabinin +Cc: Danilo Krummrich +Cc: Dmitriy Vyukov +Cc: Kees Cook +Cc: Marco Elver +Cc: "Uladzislau Rezki (Sony)" +Cc: Vincenzo Frascino +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/kasan.h | 1 + + mm/kasan/hw_tags.c | 2 +- + mm/kasan/shadow.c | 4 +++- + mm/vmalloc.c | 4 +++- + 4 files changed, 8 insertions(+), 3 deletions(-) + +--- a/include/linux/kasan.h ++++ b/include/linux/kasan.h +@@ -28,6 +28,7 @@ typedef unsigned int __bitwise kasan_vma + #define KASAN_VMALLOC_INIT ((__force kasan_vmalloc_flags_t)0x01u) + #define KASAN_VMALLOC_VM_ALLOC ((__force kasan_vmalloc_flags_t)0x02u) + #define KASAN_VMALLOC_PROT_NORMAL ((__force kasan_vmalloc_flags_t)0x04u) ++#define KASAN_VMALLOC_KEEP_TAG ((__force kasan_vmalloc_flags_t)0x08u) + + #define KASAN_VMALLOC_PAGE_RANGE 0x1 /* Apply exsiting page range */ + #define KASAN_VMALLOC_TLB_FLUSH 0x2 /* TLB flush */ +--- a/mm/kasan/hw_tags.c ++++ b/mm/kasan/hw_tags.c +@@ -361,7 +361,7 @@ void *__kasan_unpoison_vmalloc(const voi + return (void *)start; + } + +- tag = kasan_random_tag(); ++ tag = (flags & KASAN_VMALLOC_KEEP_TAG) ? get_tag(start) : kasan_random_tag(); + start = set_tag(start, tag); + + /* Unpoison and initialize memory up to size. */ +--- a/mm/kasan/shadow.c ++++ b/mm/kasan/shadow.c +@@ -648,7 +648,9 @@ void *__kasan_unpoison_vmalloc(const voi + !(flags & KASAN_VMALLOC_PROT_NORMAL)) + return (void *)start; + +- start = set_tag(start, kasan_random_tag()); ++ if (unlikely(!(flags & KASAN_VMALLOC_KEEP_TAG))) ++ start = set_tag(start, kasan_random_tag()); ++ + kasan_unpoison(start, size, false); + return (void *)start; + } +--- a/mm/vmalloc.c ++++ b/mm/vmalloc.c +@@ -4176,7 +4176,9 @@ void *vrealloc_node_align_noprof(const v + */ + if (size <= alloced_size) { + kasan_unpoison_vmalloc(p + old_size, size - old_size, +- KASAN_VMALLOC_PROT_NORMAL); ++ KASAN_VMALLOC_PROT_NORMAL | ++ KASAN_VMALLOC_VM_ALLOC | ++ KASAN_VMALLOC_KEEP_TAG); + /* + * No need to zero memory here, as unused memory will have + * already been zeroed at initial allocation time or during diff --git a/queue-6.18/mm-page_alloc-change-all-pageblocks-migrate-type-on-coalescing.patch b/queue-6.18/mm-page_alloc-change-all-pageblocks-migrate-type-on-coalescing.patch new file mode 100644 index 0000000000..130e98b378 --- /dev/null +++ b/queue-6.18/mm-page_alloc-change-all-pageblocks-migrate-type-on-coalescing.patch @@ -0,0 +1,189 @@ +From 7838a4eb8a1d23160bd3f588ea7f2b8f7c00c55b Mon Sep 17 00:00:00 2001 +From: Alexander Gordeev +Date: Fri, 12 Dec 2025 16:14:57 +0100 +Subject: mm/page_alloc: change all pageblocks migrate type on coalescing + +From: Alexander Gordeev + +commit 7838a4eb8a1d23160bd3f588ea7f2b8f7c00c55b upstream. + +When a page is freed it coalesces with a buddy into a higher order page +while possible. When the buddy page migrate type differs, it is expected +to be updated to match the one of the page being freed. + +However, only the first pageblock of the buddy page is updated, while the +rest of the pageblocks are left unchanged. + +That causes warnings in later expand() and other code paths (like below), +since an inconsistency between migration type of the list containing the +page and the page-owned pageblocks migration types is introduced. + +[ 308.986589] ------------[ cut here ]------------ +[ 308.987227] page type is 0, passed migratetype is 1 (nr=256) +[ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:812 expand+0x23c/0x270 +[ 308.987293] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) +[ 308.987439] Unloaded tainted modules: hmac_s390(E):2 +[ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT +[ 308.987657] Tainted: [E]=UNSIGNED_MODULE +[ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) +[ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) +[ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 +[ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 +[ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 +[ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 +[ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 +[ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2 larl %r2,000003499883abd4 + 00000349976fa5f6: c0e5ffe3f4b5 brasl %r14,0000034997378f60 + #00000349976fa5fc: af000000 mc 0,0 + >00000349976fa600: a7f4ff4c brc 15,00000349976fa498 + 00000349976fa604: b9040026 lgr %r2,%r6 + 00000349976fa608: c0300088317f larl %r3,0000034998800906 + 00000349976fa60e: c0e5fffdb6e1 brasl %r14,00000349976b13d0 + 00000349976fa614: af000000 mc 0,0 +[ 308.987734] Call Trace: +[ 308.987738] [<00000349976fa600>] expand+0x240/0x270 +[ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) +[ 308.987749] [<00000349976ff95e>] rmqueue_bulk+0x71e/0x940 +[ 308.987754] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 +[ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 +[ 308.987763] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 +[ 308.987768] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 +[ 308.987774] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 +[ 308.987781] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 +[ 308.987786] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 +[ 308.987791] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 +[ 308.987799] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 +[ 308.987804] [<00000349976cb08e>] __handle_mm_fault+0x4de/0x500 +[ 308.987809] [<00000349976cb14c>] handle_mm_fault+0x9c/0x3a0 +[ 308.987813] [<000003499734d70e>] do_exception+0x1de/0x540 +[ 308.987822] [<0000034998387390>] __do_pgm_check+0x130/0x220 +[ 308.987830] [<000003499839a934>] pgm_check_handler+0x114/0x160 +[ 308.987838] 3 locks held by mempig_verify/5224: +[ 308.987842] #0: 0000023ea44c1e08 (vm_lock){++++}-{0:0}, at: lock_vma_under_rcu+0xb2/0x2a0 +[ 308.987859] #1: 0000023ee4d41b18 (&pcp->lock){+.+.}-{2:2}, at: rmqueue.isra.0+0xad6/0xf40 +[ 308.987871] #2: 0000023efe6c8998 (&zone->lock){..-.}-{2:2}, at: rmqueue_bulk+0x5a/0x940 +[ 308.987886] Last Breaking-Event-Address: +[ 308.987890] [<0000034997379096>] __warn_printk+0x136/0x140 +[ 308.987897] irq event stamp: 52330356 +[ 308.987901] hardirqs last enabled at (52330355): [<000003499838742e>] __do_pgm_check+0x1ce/0x220 +[ 308.987907] hardirqs last disabled at (52330356): [<000003499839932e>] _raw_spin_lock_irqsave+0x9e/0xe0 +[ 308.987913] softirqs last enabled at (52329882): [<0000034997383786>] handle_softirqs+0x2c6/0x530 +[ 308.987922] softirqs last disabled at (52329859): [<0000034997382f86>] __irq_exit_rcu+0x126/0x140 +[ 308.987929] ---[ end trace 0000000000000000 ]--- +[ 308.987936] ------------[ cut here ]------------ +[ 308.987940] page type is 0, passed migratetype is 1 (nr=256) +[ 308.987951] WARNING: CPU: 1 PID: 5224 at mm/page_alloc.c:860 __del_page_from_free_list+0x1be/0x1e0 +[ 308.987960] Modules linked in: algif_hash(E) af_alg(E) nft_fib_inet(E) nft_fib_ipv4(E) nft_fib_ipv6(E) nft_fib(E) nft_reject_inet(E) nf_reject_ipv4(E) nf_reject_ipv6(E) nft_reject(E) nft_ct(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) s390_trng(E) vfio_ccw(E) mdev(E) vfio_iommu_type1(E) vfio(E) sch_fq_codel(E) drm(E) i2c_core(E) drm_panel_orientation_quirks(E) loop(E) nfnetlink(E) vsock_loopback(E) vmw_vsock_virtio_transport_common(E) vsock(E) ctcm(E) fsm(E) diag288_wdt(E) watchdog(E) zfcp(E) scsi_transport_fc(E) ghash_s390(E) prng(E) aes_s390(E) des_generic(E) des_s390(E) libdes(E) sha3_512_s390(E) sha3_256_s390(E) sha_common(E) paes_s390(E) crypto_engine(E) pkey_cca(E) pkey_ep11(E) zcrypt(E) rng_core(E) pkey_pckmo(E) pkey(E) autofs4(E) +[ 308.988070] Unloaded tainted modules: hmac_s390(E):2 +[ 308.988087] CPU: 1 UID: 0 PID: 5224 Comm: mempig_verify Kdump: loaded Tainted: G W E 6.18.0-gcc-bpf-debug #431 PREEMPT +[ 308.988095] Tainted: [W]=WARN, [E]=UNSIGNED_MODULE +[ 308.988100] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) +[ 308.988105] Krnl PSW : 0404f00180000000 00000349976f9e32 (__del_page_from_free_list+0x1c2/0x1e0) +[ 308.988118] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 +[ 308.988127] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 +[ 308.988133] 0000000000000005 0000034980000005 0000034998d57290 0000023efe6c8300 +[ 308.988139] 0000000000000001 0000000000000008 000002be00000100 000002be803ac000 +[ 308.988144] 0000000000000000 0000000000000001 00000349976f9e2e 000002c99b1eb728 +[ 308.988153] Krnl Code: 00000349976f9e22: c020008a06d9 larl %r2,000003499883abd4 + 00000349976f9e28: c0e5ffe3f89c brasl %r14,0000034997378f60 + #00000349976f9e2e: af000000 mc 0,0 + >00000349976f9e32: a7f4ff4e brc 15,00000349976f9cce + 00000349976f9e36: b904002b lgr %r2,%r11 + 00000349976f9e3a: c030008a06e7 larl %r3,000003499883ac08 + 00000349976f9e40: c0e5fffdbac8 brasl %r14,00000349976b13d0 + 00000349976f9e46: af000000 mc 0,0 +[ 308.988184] Call Trace: +[ 308.988188] [<00000349976f9e32>] __del_page_from_free_list+0x1c2/0x1e0 +[ 308.988195] ([<00000349976f9e2e>] __del_page_from_free_list+0x1be/0x1e0) +[ 308.988202] [<00000349976ff946>] rmqueue_bulk+0x706/0x940 +[ 308.988208] [<00000349976ffd7e>] __rmqueue_pcplist+0x1fe/0x2a0 +[ 308.988214] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 +[ 308.988221] [<0000034997703ec8>] get_page_from_freelist+0x198/0x8d0 +[ 308.988227] [<0000034997706fa8>] __alloc_frozen_pages_noprof+0x198/0x400 +[ 308.988233] [<00000349977536f8>] alloc_pages_mpol+0xb8/0x220 +[ 308.988240] [<0000034997753bf6>] folio_alloc_mpol_noprof+0x26/0xc0 +[ 308.988247] [<0000034997753e4c>] vma_alloc_folio_noprof+0x6c/0xa0 +[ 308.988253] [<0000034997775b22>] vma_alloc_anon_folio_pmd+0x42/0x240 +[ 308.988260] [<000003499777bfea>] __do_huge_pmd_anonymous_page+0x3a/0x210 +[ 308.988267] [<00000349976cb08e>] __handle_mm_fault+0x4de/0x500 +[ 308.988273] [<00000349976cb14c>] handle_mm_fault+0x9c/0x3a0 +[ 308.988279] [<000003499734d70e>] do_exception+0x1de/0x540 +[ 308.988286] [<0000034998387390>] __do_pgm_check+0x130/0x220 +[ 308.988293] [<000003499839a934>] pgm_check_handler+0x114/0x160 +[ 308.988300] 3 locks held by mempig_verify/5224: +[ 308.988305] #0: 0000023ea44c1e08 (vm_lock){++++}-{0:0}, at: lock_vma_under_rcu+0xb2/0x2a0 +[ 308.988322] #1: 0000023ee4d41b18 (&pcp->lock){+.+.}-{2:2}, at: rmqueue.isra.0+0xad6/0xf40 +[ 308.988334] #2: 0000023efe6c8998 (&zone->lock){..-.}-{2:2}, at: rmqueue_bulk+0x5a/0x940 +[ 308.988346] Last Breaking-Event-Address: +[ 308.988350] [<0000034997379096>] __warn_printk+0x136/0x140 +[ 308.988356] irq event stamp: 52330356 +[ 308.988360] hardirqs last enabled at (52330355): [<000003499838742e>] __do_pgm_check+0x1ce/0x220 +[ 308.988366] hardirqs last disabled at (52330356): [<000003499839932e>] _raw_spin_lock_irqsave+0x9e/0xe0 +[ 308.988373] softirqs last enabled at (52329882): [<0000034997383786>] handle_softirqs+0x2c6/0x530 +[ 308.988380] softirqs last disabled at (52329859): [<0000034997382f86>] __irq_exit_rcu+0x126/0x140 +[ 308.988388] ---[ end trace 0000000000000000 ]--- + +Link: https://lkml.kernel.org/r/20251215081002.3353900A9c-agordeev@linux.ibm.com +Link: https://lkml.kernel.org/r/20251212151457.3898073Add-agordeev@linux.ibm.com +Fixes: e6cf9e1c4cde ("mm: page_alloc: fix up block types when merging compatible blocks") +Signed-off-by: Alexander Gordeev +Reported-by: Marc Hartmayer +Closes: https://lore.kernel.org/linux-mm/87wmalyktd.fsf@linux.ibm.com/ +Acked-by: Vlastimil Babka +Acked-by: Johannes Weiner +Reviewed-by: Wei Yang +Cc: Marc Hartmayer +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/page_alloc.c | 24 ++++++++++++------------ + 1 file changed, 12 insertions(+), 12 deletions(-) + +--- a/mm/page_alloc.c ++++ b/mm/page_alloc.c +@@ -913,6 +913,17 @@ buddy_merge_likely(unsigned long pfn, un + NULL) != NULL; + } + ++static void change_pageblock_range(struct page *pageblock_page, ++ int start_order, int migratetype) ++{ ++ int nr_pageblocks = 1 << (start_order - pageblock_order); ++ ++ while (nr_pageblocks--) { ++ set_pageblock_migratetype(pageblock_page, migratetype); ++ pageblock_page += pageblock_nr_pages; ++ } ++} ++ + /* + * Freeing function for a buddy system allocator. + * +@@ -999,7 +1010,7 @@ static inline void __free_one_page(struc + * expand() down the line puts the sub-blocks + * on the right freelists. + */ +- set_pageblock_migratetype(buddy, migratetype); ++ change_pageblock_range(buddy, order, migratetype); + } + + combined_pfn = buddy_pfn & pfn; +@@ -2146,17 +2157,6 @@ bool pageblock_unisolate_and_move_free_p + + #endif /* CONFIG_MEMORY_ISOLATION */ + +-static void change_pageblock_range(struct page *pageblock_page, +- int start_order, int migratetype) +-{ +- int nr_pageblocks = 1 << (start_order - pageblock_order); +- +- while (nr_pageblocks--) { +- set_pageblock_migratetype(pageblock_page, migratetype); +- pageblock_page += pageblock_nr_pages; +- } +-} +- + static inline bool boost_watermark(struct zone *zone) + { + unsigned long max_boost; diff --git a/queue-6.18/mm-page_owner-fix-memory-leak-in-page_owner_stack_fops-release.patch b/queue-6.18/mm-page_owner-fix-memory-leak-in-page_owner_stack_fops-release.patch new file mode 100644 index 0000000000..6df64934c8 --- /dev/null +++ b/queue-6.18/mm-page_owner-fix-memory-leak-in-page_owner_stack_fops-release.patch @@ -0,0 +1,43 @@ +From a76a5ae2c6c645005672c2caf2d49361c6f2500f Mon Sep 17 00:00:00 2001 +From: Ran Xiaokai +Date: Fri, 19 Dec 2025 07:42:32 +0000 +Subject: mm/page_owner: fix memory leak in page_owner_stack_fops->release() + +From: Ran Xiaokai + +commit a76a5ae2c6c645005672c2caf2d49361c6f2500f upstream. + +The page_owner_stack_fops->open() callback invokes seq_open_private(), +therefore its corresponding ->release() callback must call +seq_release_private(). Otherwise it will cause a memory leak of struct +stack_print_ctx. + +Link: https://lkml.kernel.org/r/20251219074232.136482-1-ranxiaokai627@163.com +Fixes: 765973a09803 ("mm,page_owner: display all stacks and their count") +Signed-off-by: Ran Xiaokai +Acked-by: Michal Hocko +Acked-by: Vlastimil Babka +Cc: Andrey Konovalov +Cc: Brendan Jackman +Cc: Johannes Weiner +Cc: Marco Elver +Cc: Suren Baghdasaryan +Cc: Zi Yan +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/page_owner.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/page_owner.c ++++ b/mm/page_owner.c +@@ -936,7 +936,7 @@ static const struct file_operations page + .open = page_owner_stack_open, + .read = seq_read, + .llseek = seq_lseek, +- .release = seq_release, ++ .release = seq_release_private, + }; + + static int page_owner_threshold_get(void *data, u64 *val) diff --git a/queue-6.18/mptcp-fallback-earlier-on-simult-connection.patch b/queue-6.18/mptcp-fallback-earlier-on-simult-connection.patch new file mode 100644 index 0000000000..1ec29767d4 --- /dev/null +++ b/queue-6.18/mptcp-fallback-earlier-on-simult-connection.patch @@ -0,0 +1,142 @@ +From 71154bbe49423128c1c8577b6576de1ed6836830 Mon Sep 17 00:00:00 2001 +From: Paolo Abeni +Date: Fri, 12 Dec 2025 13:54:03 +0100 +Subject: mptcp: fallback earlier on simult connection + +From: Paolo Abeni + +commit 71154bbe49423128c1c8577b6576de1ed6836830 upstream. + +Syzkaller reports a simult-connect race leading to inconsistent fallback +status: + + WARNING: CPU: 3 PID: 33 at net/mptcp/subflow.c:1515 subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515 + Modules linked in: + CPU: 3 UID: 0 PID: 33 Comm: ksoftirqd/3 Not tainted syzkaller #0 PREEMPT(full) + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 + RIP: 0010:subflow_data_ready+0x40b/0x7c0 net/mptcp/subflow.c:1515 + Code: 89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 <0f> 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6 + RSP: 0018:ffffc900006cf338 EFLAGS: 00010246 + RAX: 0000000000000000 RBX: ffff888031acd100 RCX: ffffffff8b7f2abf + RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005 + RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007 + R10: 0000000000000004 R11: 0000000000002c10 R12: ffff88802ba69900 + R13: 1ffff920000d9e67 R14: ffff888046f81800 R15: 0000000000000004 + FS: 0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0 + Call Trace: + + tcp_data_queue+0x13b0/0x4f90 net/ipv4/tcp_input.c:5197 + tcp_rcv_state_process+0xfdf/0x4ec0 net/ipv4/tcp_input.c:6922 + tcp_v6_do_rcv+0x492/0x1740 net/ipv6/tcp_ipv6.c:1672 + tcp_v6_rcv+0x2976/0x41e0 net/ipv6/tcp_ipv6.c:1918 + ip6_protocol_deliver_rcu+0x188/0x1520 net/ipv6/ip6_input.c:438 + ip6_input_finish+0x1e4/0x4b0 net/ipv6/ip6_input.c:489 + NF_HOOK include/linux/netfilter.h:318 [inline] + NF_HOOK include/linux/netfilter.h:312 [inline] + ip6_input+0x105/0x2f0 net/ipv6/ip6_input.c:500 + dst_input include/net/dst.h:471 [inline] + ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] + NF_HOOK include/linux/netfilter.h:318 [inline] + NF_HOOK include/linux/netfilter.h:312 [inline] + ipv6_rcv+0x264/0x650 net/ipv6/ip6_input.c:311 + __netif_receive_skb_one_core+0x12d/0x1e0 net/core/dev.c:5979 + __netif_receive_skb+0x1d/0x160 net/core/dev.c:6092 + process_backlog+0x442/0x15e0 net/core/dev.c:6444 + __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7494 + napi_poll net/core/dev.c:7557 [inline] + net_rx_action+0xa9f/0xfe0 net/core/dev.c:7684 + handle_softirqs+0x216/0x8e0 kernel/softirq.c:579 + run_ksoftirqd kernel/softirq.c:968 [inline] + run_ksoftirqd+0x3a/0x60 kernel/softirq.c:960 + smpboot_thread_fn+0x3f7/0xae0 kernel/smpboot.c:160 + kthread+0x3c2/0x780 kernel/kthread.c:463 + ret_from_fork+0x5d7/0x6f0 arch/x86/kernel/process.c:148 + ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 + + +The TCP subflow can process the simult-connect syn-ack packet after +transitioning to TCP_FIN1 state, bypassing the MPTCP fallback check, +as the sk_state_change() callback is not invoked for * -> FIN_WAIT1 +transitions. + +That will move the msk socket to an inconsistent status and the next +incoming data will hit the reported splat. + +Close the race moving the simult-fallback check at the earliest possible +stage - that is at syn-ack generation time. + +About the fixes tags: [2] was supposed to also fix this issue introduced +by [3]. [1] is required as a dependence: it was not explicitly marked as +a fix, but it is one and it has already been backported before [3]. In +other words, this commit should be backported up to [3], including [2] +and [1] if that's not already there. + +Fixes: 23e89e8ee7be ("tcp: Don't drop SYN+ACK for simultaneous connect().") [1] +Fixes: 4fd19a307016 ("mptcp: fix inconsistent state on fastopen race") [2] +Fixes: 1e777f39b4d7 ("mptcp: add MSG_FASTOPEN sendmsg flag support") [3] +Cc: stable@vger.kernel.org +Reported-by: syzbot+0ff6b771b4f7a5bce83b@syzkaller.appspotmail.com +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/586 +Signed-off-by: Paolo Abeni +Reviewed-by: Matthieu Baerts (NGI0) +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20251212-net-mptcp-subflow_data_ready-warn-v1-1-d1f9fd1c36c8@kernel.org +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/options.c | 10 ++++++++++ + net/mptcp/protocol.h | 6 ++---- + net/mptcp/subflow.c | 6 ------ + 3 files changed, 12 insertions(+), 10 deletions(-) + +--- a/net/mptcp/options.c ++++ b/net/mptcp/options.c +@@ -408,6 +408,16 @@ bool mptcp_syn_options(struct sock *sk, + */ + subflow->snd_isn = TCP_SKB_CB(skb)->end_seq; + if (subflow->request_mptcp) { ++ if (unlikely(subflow_simultaneous_connect(sk))) { ++ WARN_ON_ONCE(!mptcp_try_fallback(sk, MPTCP_MIB_SIMULTCONNFALLBACK)); ++ ++ /* Ensure mptcp_finish_connect() will not process the ++ * MPC handshake. ++ */ ++ subflow->request_mptcp = 0; ++ return false; ++ } ++ + opts->suboptions = OPTION_MPTCP_MPC_SYN; + opts->csum_reqd = mptcp_is_checksum_enabled(sock_net(sk)); + opts->allow_join_id0 = mptcp_allow_join_id0(sock_net(sk)); +--- a/net/mptcp/protocol.h ++++ b/net/mptcp/protocol.h +@@ -1293,10 +1293,8 @@ static inline bool subflow_simultaneous_ + { + struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(sk); + +- return (1 << sk->sk_state) & +- (TCPF_ESTABLISHED | TCPF_FIN_WAIT1 | TCPF_FIN_WAIT2 | TCPF_CLOSING) && +- is_active_ssk(subflow) && +- !subflow->conn_finished; ++ /* Note that the sk state implies !subflow->conn_finished. */ ++ return sk->sk_state == TCP_SYN_RECV && is_active_ssk(subflow); + } + + #ifdef CONFIG_SYN_COOKIES +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -1856,12 +1856,6 @@ static void subflow_state_change(struct + + __subflow_state_change(sk); + +- if (subflow_simultaneous_connect(sk)) { +- WARN_ON_ONCE(!mptcp_try_fallback(sk, MPTCP_MIB_SIMULTCONNFALLBACK)); +- subflow->conn_finished = 1; +- mptcp_propagate_state(parent, sk, subflow, NULL); +- } +- + /* as recvmsg() does not acquire the subflow socket for ssk selection + * a fin packet carrying a DSS can be unnoticed if we don't trigger + * the data available machinery here. diff --git a/queue-6.18/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch b/queue-6.18/net-macb-relocate-mog_init_rings-callback-from-macb_mac_link_up-to-macb_open.patch new file mode 100644 index 0000000000..d3c0fa02c4 --- /dev/null +++ b/queue-6.18/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 +@@ -744,7 +744,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) +@@ -2991,6 +2990,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.18/net-nfc-fix-deadlock-between-nfc_unregister_device-and-rfkill_fop_write.patch b/queue-6.18/net-nfc-fix-deadlock-between-nfc_unregister_device-and-rfkill_fop_write.patch new file mode 100644 index 0000000000..d6b92c2116 --- /dev/null +++ b/queue-6.18/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) { + timer_delete_sync(&dev->check_pres_timer); + cancel_work_sync(&dev->check_pres_work); diff --git a/queue-6.18/net-phy-mediatek-fix-nvmem-cell-reference-leak-in-mt798x_phy_calibration.patch b/queue-6.18/net-phy-mediatek-fix-nvmem-cell-reference-leak-in-mt798x_phy_calibration.patch new file mode 100644 index 0000000000..1add1c9a97 --- /dev/null +++ b/queue-6.18/net-phy-mediatek-fix-nvmem-cell-reference-leak-in-mt798x_phy_calibration.patch @@ -0,0 +1,42 @@ +From 1e5a541420b8c6d87d88eb50b6b978cdeafee1c9 Mon Sep 17 00:00:00 2001 +From: Miaoqian Lin +Date: Thu, 11 Dec 2025 12:13:13 +0400 +Subject: net: phy: mediatek: fix nvmem cell reference leak in mt798x_phy_calibration + +From: Miaoqian Lin + +commit 1e5a541420b8c6d87d88eb50b6b978cdeafee1c9 upstream. + +When nvmem_cell_read() fails in mt798x_phy_calibration(), the function +returns without calling nvmem_cell_put(), leaking the cell reference. + +Move nvmem_cell_put() right after nvmem_cell_read() to ensure the cell +reference is always released regardless of the read result. + +Found via static analysis and code review. + +Fixes: 98c485eaf509 ("net: phy: add driver for MediaTek SoC built-in GE PHYs") +Cc: stable@vger.kernel.org +Signed-off-by: Miaoqian Lin +Reviewed-by: Daniel Golle +Reviewed-by: Andrew Lunn +Link: https://patch.msgid.link/20251211081313.2368460-1-linmq006@gmail.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/phy/mediatek/mtk-ge-soc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/phy/mediatek/mtk-ge-soc.c ++++ b/drivers/net/phy/mediatek/mtk-ge-soc.c +@@ -1167,9 +1167,9 @@ static int mt798x_phy_calibration(struct + } + + buf = (u32 *)nvmem_cell_read(cell, &len); ++ nvmem_cell_put(cell); + if (IS_ERR(buf)) + return PTR_ERR(buf); +- nvmem_cell_put(cell); + + if (!buf[0] || !buf[1] || !buf[2] || !buf[3] || len < 4 * sizeof(u32)) { + phydev_err(phydev, "invalid efuse data\n"); diff --git a/queue-6.18/net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch b/queue-6.18/net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch new file mode 100644 index 0000000000..2e4a06faf8 --- /dev/null +++ b/queue-6.18/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.18/nfsd-drop-the-client-reference-in-client_states_open.patch b/queue-6.18/nfsd-drop-the-client-reference-in-client_states_open.patch new file mode 100644 index 0000000000..36031ac9f7 --- /dev/null +++ b/queue-6.18/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 +@@ -3099,8 +3099,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.18/nfsd-fix-nfsd_file-reference-leak-in-nfsd4_add_rdaccess_to_wrdeleg.patch b/queue-6.18/nfsd-fix-nfsd_file-reference-leak-in-nfsd4_add_rdaccess_to_wrdeleg.patch new file mode 100644 index 0000000000..06ee41f6a7 --- /dev/null +++ b/queue-6.18/nfsd-fix-nfsd_file-reference-leak-in-nfsd4_add_rdaccess_to_wrdeleg.patch @@ -0,0 +1,72 @@ +From 8072e34e1387d03102b788677d491e2bcceef6f5 Mon Sep 17 00:00:00 2001 +From: Chuck Lever +Date: Mon, 1 Dec 2025 17:09:55 -0500 +Subject: nfsd: fix nfsd_file reference leak in nfsd4_add_rdaccess_to_wrdeleg() + +From: Chuck Lever + +commit 8072e34e1387d03102b788677d491e2bcceef6f5 upstream. + +nfsd4_add_rdaccess_to_wrdeleg() unconditionally overwrites +fp->fi_fds[O_RDONLY] with a newly acquired nfsd_file. However, if +the client already has a SHARE_ACCESS_READ open from a previous OPEN +operation, this action overwrites the existing pointer without +releasing its reference, orphaning the previous reference. + +Additionally, the function originally stored the same nfsd_file +pointer in both fp->fi_fds[O_RDONLY] and fp->fi_rdeleg_file with +only a single reference. When put_deleg_file() runs, it clears +fi_rdeleg_file and calls nfs4_file_put_access() to release the file. + +However, nfs4_file_put_access() only releases fi_fds[O_RDONLY] when +the fi_access[O_RDONLY] counter drops to zero. If another READ open +exists on the file, the counter remains elevated and the nfsd_file +reference from the delegation is never released. This potentially +causes open conflicts on that file. + +Then, on server shutdown, these leaks cause __nfsd_file_cache_purge() +to encounter files with an elevated reference count that cannot be +cleaned up, ultimately triggering a BUG() in kmem_cache_destroy() +because there are still nfsd_file objects allocated in that cache. + +Fixes: e7a8ebc305f2 ("NFSD: Offer write delegation for OPEN with OPEN4_SHARE_ACCESS_WRITE") +Cc: stable@vger.kernel.org +Reviewed-by: Jeff Layton +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfsd/nfs4state.c | 14 ++++++++++---- + 1 file changed, 10 insertions(+), 4 deletions(-) + +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -1218,8 +1218,10 @@ static void put_deleg_file(struct nfs4_f + + if (nf) + nfsd_file_put(nf); +- if (rnf) ++ if (rnf) { ++ nfsd_file_put(rnf); + nfs4_file_put_access(fp, NFS4_SHARE_ACCESS_READ); ++ } + } + + static void nfsd4_finalize_deleg_timestamps(struct nfs4_delegation *dp, struct file *f) +@@ -6253,10 +6255,14 @@ nfsd4_add_rdaccess_to_wrdeleg(struct svc + fp = stp->st_stid.sc_file; + spin_lock(&fp->fi_lock); + __nfs4_file_get_access(fp, NFS4_SHARE_ACCESS_READ); +- fp = stp->st_stid.sc_file; +- fp->fi_fds[O_RDONLY] = nf; +- fp->fi_rdeleg_file = nf; ++ if (!fp->fi_fds[O_RDONLY]) { ++ fp->fi_fds[O_RDONLY] = nf; ++ nf = NULL; ++ } ++ fp->fi_rdeleg_file = nfsd_file_get(fp->fi_fds[O_RDONLY]); + spin_unlock(&fp->fi_lock); ++ if (nf) ++ nfsd_file_put(nf); + } + return true; + } diff --git a/queue-6.18/nfsd-use-attr_deleg-in-nfsd4_finalize_deleg_timestamps.patch b/queue-6.18/nfsd-use-attr_deleg-in-nfsd4_finalize_deleg_timestamps.patch new file mode 100644 index 0000000000..272de0897a --- /dev/null +++ b/queue-6.18/nfsd-use-attr_deleg-in-nfsd4_finalize_deleg_timestamps.patch @@ -0,0 +1,40 @@ +From 8f9e967830ff32ab7756f530a36adf74a9f12b76 Mon Sep 17 00:00:00 2001 +From: Jeff Layton +Date: Wed, 3 Dec 2025 10:52:15 -0500 +Subject: nfsd: use ATTR_DELEG in nfsd4_finalize_deleg_timestamps() + +From: Jeff Layton + +commit 8f9e967830ff32ab7756f530a36adf74a9f12b76 upstream. + +When finalizing timestamps that have never been updated and preparing to +release the delegation lease, the notify_change() call can trigger a +delegation break, and fail to update the timestamps. When this happens, +there will be messages like this in dmesg: + + [ 2709.375785] Unable to update timestamps on inode 00:39:263: -11 + +Since this code is going to release the lease just after updating the +timestamps, breaking the delegation is undesirable. Fix this by setting +ATTR_DELEG in ia_valid, in order to avoid the delegation break. + +Fixes: e5e9b24ab8fa ("nfsd: freeze c/mtime updates with outstanding WRITE_ATTRS delegation") +Cc: stable@vger.kernel.org +Signed-off-by: Jeff Layton +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfsd/nfs4state.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -1226,7 +1226,7 @@ static void put_deleg_file(struct nfs4_f + + static void nfsd4_finalize_deleg_timestamps(struct nfs4_delegation *dp, struct file *f) + { +- struct iattr ia = { .ia_valid = ATTR_ATIME | ATTR_CTIME | ATTR_MTIME }; ++ struct iattr ia = { .ia_valid = ATTR_ATIME | ATTR_CTIME | ATTR_MTIME | ATTR_DELEG }; + struct inode *inode = file_inode(f); + int ret; + diff --git a/queue-6.18/platform-x86-alienware-wmi-wmax-add-awcc-support-for-alienware-x16.patch b/queue-6.18/platform-x86-alienware-wmi-wmax-add-awcc-support-for-alienware-x16.patch new file mode 100644 index 0000000000..7267114d1a --- /dev/null +++ b/queue-6.18/platform-x86-alienware-wmi-wmax-add-awcc-support-for-alienware-x16.patch @@ -0,0 +1,41 @@ +From a584644a490d276907e56817694859eaac2a4199 Mon Sep 17 00:00:00 2001 +From: Kurt Borja +Date: Fri, 5 Dec 2025 13:50:11 -0500 +Subject: platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Kurt Borja + +commit a584644a490d276907e56817694859eaac2a4199 upstream. + +Add AWCC support for Alienware x16 laptops. + +Cc: stable@vger.kernel.org +Signed-off-by: Kurt Borja +Reviewed-by: Ilpo Järvinen +Link: https://patch.msgid.link/20251205-area-51-v1-2-d2cb13530851@gmail.com +Signed-off-by: Ilpo Järvinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/dell/alienware-wmi-wmax.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/platform/x86/dell/alienware-wmi-wmax.c ++++ b/drivers/platform/x86/dell/alienware-wmi-wmax.c +@@ -178,6 +178,14 @@ static const struct dmi_system_id awcc_d + .driver_data = &generic_quirks, + }, + { ++ .ident = "Alienware x16", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Alienware"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Alienware x16"), ++ }, ++ .driver_data = &g_series_quirks, ++ }, ++ { + .ident = "Alienware x17", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Alienware"), diff --git a/queue-6.18/platform-x86-alienware-wmi-wmax-add-support-for-alienware-16x-aurora.patch b/queue-6.18/platform-x86-alienware-wmi-wmax-add-support-for-alienware-16x-aurora.patch new file mode 100644 index 0000000000..37444eda59 --- /dev/null +++ b/queue-6.18/platform-x86-alienware-wmi-wmax-add-support-for-alienware-16x-aurora.patch @@ -0,0 +1,41 @@ +From 7f3c2499da24551968640528fee9aed3bb4f0c3f Mon Sep 17 00:00:00 2001 +From: Kurt Borja +Date: Fri, 5 Dec 2025 13:50:12 -0500 +Subject: platform/x86: alienware-wmi-wmax: Add support for Alienware 16X Aurora +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Kurt Borja + +commit 7f3c2499da24551968640528fee9aed3bb4f0c3f upstream. + +Add AWCC support for Alienware 16X Aurora laptops. + +Cc: stable@vger.kernel.org +Signed-off-by: Kurt Borja +Reviewed-by: Ilpo Järvinen +Link: https://patch.msgid.link/20251205-area-51-v1-3-d2cb13530851@gmail.com +Signed-off-by: Ilpo Järvinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/dell/alienware-wmi-wmax.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/platform/x86/dell/alienware-wmi-wmax.c ++++ b/drivers/platform/x86/dell/alienware-wmi-wmax.c +@@ -98,6 +98,14 @@ static const struct dmi_system_id awcc_d + .driver_data = &g_series_quirks, + }, + { ++ .ident = "Alienware 16X Aurora", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Alienware"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Alienware 16X Aurora"), ++ }, ++ .driver_data = &g_series_quirks, ++ }, ++ { + .ident = "Alienware 18 Area-51", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Alienware"), diff --git a/queue-6.18/platform-x86-alienware-wmi-wmax-add-support-for-new-area-51-laptops.patch b/queue-6.18/platform-x86-alienware-wmi-wmax-add-support-for-new-area-51-laptops.patch new file mode 100644 index 0000000000..30235d487c --- /dev/null +++ b/queue-6.18/platform-x86-alienware-wmi-wmax-add-support-for-new-area-51-laptops.patch @@ -0,0 +1,49 @@ +From 433f7744cb302ac22800dc0cd50494319ce64ba0 Mon Sep 17 00:00:00 2001 +From: Kurt Borja +Date: Fri, 5 Dec 2025 13:50:10 -0500 +Subject: platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptops +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Kurt Borja + +commit 433f7744cb302ac22800dc0cd50494319ce64ba0 upstream. + +Add AWCC support for new Alienware Area-51 laptops. + +Cc: stable@vger.kernel.org +Signed-off-by: Kurt Borja +Reviewed-by: Ilpo Järvinen +Link: https://patch.msgid.link/20251205-area-51-v1-1-d2cb13530851@gmail.com +Signed-off-by: Ilpo Järvinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/dell/alienware-wmi-wmax.c | 16 ++++++++++++++++ + 1 file changed, 16 insertions(+) + +--- a/drivers/platform/x86/dell/alienware-wmi-wmax.c ++++ b/drivers/platform/x86/dell/alienware-wmi-wmax.c +@@ -90,6 +90,22 @@ static struct awcc_quirks empty_quirks; + + static const struct dmi_system_id awcc_dmi_table[] __initconst = { + { ++ .ident = "Alienware 16 Area-51", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Alienware"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Alienware 16 Area-51"), ++ }, ++ .driver_data = &g_series_quirks, ++ }, ++ { ++ .ident = "Alienware 18 Area-51", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Alienware"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Alienware 18 Area-51"), ++ }, ++ .driver_data = &g_series_quirks, ++ }, ++ { + .ident = "Alienware 16 Aurora", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Alienware"), diff --git a/queue-6.18/platform-x86-samsung-galaxybook-fix-problematic-pointer-cast.patch b/queue-6.18/platform-x86-samsung-galaxybook-fix-problematic-pointer-cast.patch new file mode 100644 index 0000000000..eaff3f78da --- /dev/null +++ b/queue-6.18/platform-x86-samsung-galaxybook-fix-problematic-pointer-cast.patch @@ -0,0 +1,63 @@ +From d37cd54ebeac37a763fbf303ed25f8a6e98328ff Mon Sep 17 00:00:00 2001 +From: Armin Wolf +Date: Sun, 28 Dec 2025 22:41:31 +0100 +Subject: platform/x86: samsung-galaxybook: Fix problematic pointer cast +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Armin Wolf + +commit d37cd54ebeac37a763fbf303ed25f8a6e98328ff upstream. + +A user reported that reading the charge threshold on his device +results in very strange values (like 78497792) being returned. +The reason for this seems to be the fact that the driver casts +the int pointer to an u8 pointer, leaving the last 3 bytes of +the destination uninitialized. Fix this by using a temporary +variable instead. + +Cc: stable@vger.kernel.org +Fixes: 56f529ce4370 ("platform/x86: samsung-galaxybook: Add samsung-galaxybook driver") +Reported-by: Gianni Ceccarelli +Closes: https://lore.kernel.org/platform-driver-x86/20251228115556.14362d66@thenautilus.net/ +Tested-by: Gianni Ceccarelli +Signed-off-by: Armin Wolf +Link: https://patch.msgid.link/20251228214217.35972-1-W_Armin@gmx.de +Reviewed-by: Ilpo Järvinen +Signed-off-by: Ilpo Järvinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/samsung-galaxybook.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/platform/x86/samsung-galaxybook.c ++++ b/drivers/platform/x86/samsung-galaxybook.c +@@ -442,12 +442,13 @@ static int galaxybook_battery_ext_proper + union power_supply_propval *val) + { + struct samsung_galaxybook *galaxybook = ext_data; ++ u8 value; + int err; + + if (psp != POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD) + return -EINVAL; + +- err = charge_control_end_threshold_acpi_get(galaxybook, (u8 *)&val->intval); ++ err = charge_control_end_threshold_acpi_get(galaxybook, &value); + if (err) + return err; + +@@ -455,8 +456,10 @@ static int galaxybook_battery_ext_proper + * device stores "no end threshold" as 0 instead of 100; + * if device has 0, report 100 + */ +- if (val->intval == 0) +- val->intval = 100; ++ if (value == 0) ++ value = 100; ++ ++ val->intval = value; + + return 0; + } diff --git a/queue-6.18/pmdomain-imx-fix-reference-count-leak-in-imx_gpc_probe.patch b/queue-6.18/pmdomain-imx-fix-reference-count-leak-in-imx_gpc_probe.patch new file mode 100644 index 0000000000..47fa32c7aa --- /dev/null +++ b/queue-6.18/pmdomain-imx-fix-reference-count-leak-in-imx_gpc_probe.patch @@ -0,0 +1,44 @@ +From 73cb5f6eafb0ac7aea8cdeb8ff12981aa741d8fb Mon Sep 17 00:00:00 2001 +From: Wentao Liang +Date: Thu, 11 Dec 2025 04:02:52 +0000 +Subject: pmdomain: imx: Fix reference count leak in imx_gpc_probe() + +From: Wentao Liang + +commit 73cb5f6eafb0ac7aea8cdeb8ff12981aa741d8fb upstream. + +of_get_child_by_name() returns a node pointer with refcount incremented. +Use the __free() attribute to manage the pgc_node reference, ensuring +automatic of_node_put() cleanup when pgc_node goes out of scope. + +This eliminates the need for explicit error handling paths and avoids +reference count leaks. + +Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver") +Cc: stable@vger.kernel.org +Signed-off-by: Wentao Liang +Reviewed-by: Frank Li +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pmdomain/imx/gpc.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/drivers/pmdomain/imx/gpc.c ++++ b/drivers/pmdomain/imx/gpc.c +@@ -402,13 +402,12 @@ clk_err: + static int imx_gpc_probe(struct platform_device *pdev) + { + const struct imx_gpc_dt_data *of_id_data = device_get_match_data(&pdev->dev); +- struct device_node *pgc_node; ++ struct device_node *pgc_node __free(device_node) ++ = of_get_child_by_name(pdev->dev.of_node, "pgc"); + struct regmap *regmap; + void __iomem *base; + int ret; + +- pgc_node = of_get_child_by_name(pdev->dev.of_node, "pgc"); +- + /* bail out if DT too old and doesn't provide the necessary info */ + if (!of_property_present(pdev->dev.of_node, "#power-domain-cells") && + !pgc_node) diff --git a/queue-6.18/pmdomain-mtk-pm-domains-fix-spinlock-recursion-fix-in-probe.patch b/queue-6.18/pmdomain-mtk-pm-domains-fix-spinlock-recursion-fix-in-probe.patch new file mode 100644 index 0000000000..68b6281b72 --- /dev/null +++ b/queue-6.18/pmdomain-mtk-pm-domains-fix-spinlock-recursion-fix-in-probe.patch @@ -0,0 +1,83 @@ +From 305f254727bd379bbed0385afa0162f5bde1f51c Mon Sep 17 00:00:00 2001 +From: Macpaul Lin +Date: Fri, 28 Nov 2025 12:17:22 +0800 +Subject: pmdomain: mtk-pm-domains: Fix spinlock recursion fix in probe + +From: Macpaul Lin + +commit 305f254727bd379bbed0385afa0162f5bde1f51c upstream. + +Remove scpsys_get_legacy_regmap(), replacing its usage with +of_find_node_with_property(). Explicitly call of_node_get(np) before each +of_find_node_with_property() to maintain correct node reference counting. + +The of_find_node_with_property() function "consumes" its input by calling +of_node_put() internally, whether or not it finds a match. Currently, +dev->of_node (np) is passed multiple times in sequence without incrementing +its reference count, causing it to be decremented multiple times and +risking early memory release. + +Adding of_node_get(np) before each call balances the reference count, +preventing premature node release. + +Fixes: c1bac49fe91f ("pmdomains: mtk-pm-domains: Fix spinlock recursion in probe") +Cc: stable@vger.kernel.org +Signed-off-by: Macpaul Lin +Tested-by: Louis-Alexis Eyraud +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pmdomain/mediatek/mtk-pm-domains.c | 21 ++++++--------------- + 1 file changed, 6 insertions(+), 15 deletions(-) + +--- a/drivers/pmdomain/mediatek/mtk-pm-domains.c ++++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c +@@ -748,18 +748,6 @@ static void scpsys_domain_cleanup(struct + } + } + +-static struct device_node *scpsys_get_legacy_regmap(struct device_node *np, const char *pn) +-{ +- struct device_node *local_node; +- +- for_each_child_of_node(np, local_node) { +- if (of_property_present(local_node, pn)) +- return local_node; +- } +- +- return NULL; +-} +- + static int scpsys_get_bus_protection_legacy(struct device *dev, struct scpsys *scpsys) + { + const u8 bp_blocks[3] = { +@@ -781,7 +769,8 @@ static int scpsys_get_bus_protection_leg + * this makes it then possible to allocate the array of bus_prot + * regmaps and convert all to the new style handling. + */ +- node = scpsys_get_legacy_regmap(np, "mediatek,infracfg"); ++ of_node_get(np); ++ node = of_find_node_with_property(np, "mediatek,infracfg"); + if (node) { + regmap[0] = syscon_regmap_lookup_by_phandle(node, "mediatek,infracfg"); + of_node_put(node); +@@ -794,7 +783,8 @@ static int scpsys_get_bus_protection_leg + regmap[0] = NULL; + } + +- node = scpsys_get_legacy_regmap(np, "mediatek,smi"); ++ of_node_get(np); ++ node = of_find_node_with_property(np, "mediatek,smi"); + if (node) { + smi_np = of_parse_phandle(node, "mediatek,smi", 0); + of_node_put(node); +@@ -812,7 +802,8 @@ static int scpsys_get_bus_protection_leg + regmap[1] = NULL; + } + +- node = scpsys_get_legacy_regmap(np, "mediatek,infracfg-nao"); ++ of_node_get(np); ++ node = of_find_node_with_property(np, "mediatek,infracfg-nao"); + if (node) { + regmap[2] = syscon_regmap_lookup_by_phandle(node, "mediatek,infracfg-nao"); + num_regmaps++; diff --git a/queue-6.18/rdma-cm-fix-leaking-the-multicast-gid-table-reference.patch b/queue-6.18/rdma-cm-fix-leaking-the-multicast-gid-table-reference.patch new file mode 100644 index 0000000000..091482d2ef --- /dev/null +++ b/queue-6.18/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 +@@ -2009,6 +2009,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; +@@ -2031,6 +2032,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.18/rdma-core-check-for-the-presence-of-ls_nla_type_dgid-correctly.patch b/queue-6.18/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.18/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.18/rust-maple_tree-rcu_read_lock-in-destructor-to-silence-lockdep.patch b/queue-6.18/rust-maple_tree-rcu_read_lock-in-destructor-to-silence-lockdep.patch new file mode 100644 index 0000000000..aeebecf84d --- /dev/null +++ b/queue-6.18/rust-maple_tree-rcu_read_lock-in-destructor-to-silence-lockdep.patch @@ -0,0 +1,106 @@ +From 6558749ef3405c143711cbdc67ec88cbc1582d91 Mon Sep 17 00:00:00 2001 +From: Alice Ryhl +Date: Wed, 17 Dec 2025 13:10:37 +0000 +Subject: rust: maple_tree: rcu_read_lock() in destructor to silence lockdep +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Alice Ryhl + +commit 6558749ef3405c143711cbdc67ec88cbc1582d91 upstream. + +When running the Rust maple tree kunit tests with lockdep, you may trigger +a warning that looks like this: + + lib/maple_tree.c:780 suspicious rcu_dereference_check() usage! + + other info that might help us debug this: + + rcu_scheduler_active = 2, debug_locks = 1 + no locks held by kunit_try_catch/344. + + stack backtrace: + CPU: 3 UID: 0 PID: 344 Comm: kunit_try_catch Tainted: G N 6.19.0-rc1+ #2 NONE + Tainted: [N]=TEST + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 + Call Trace: + + dump_stack_lvl+0x71/0x90 + lockdep_rcu_suspicious+0x150/0x190 + mas_start+0x104/0x150 + mas_find+0x179/0x240 + _RINvNtCs5QSdWC790r4_4core3ptr13drop_in_placeINtNtCs1cdwasc6FUb_6kernel10maple_tree9MapleTreeINtNtNtBL_5alloc4kbox3BoxlNtNtB1x_9allocator7KmallocEEECsgxAQYCfdR72_25doctests_kernel_generated+0xaf/0x130 + rust_doctest_kernel_maple_tree_rs_0+0x600/0x6b0 + ? lock_release+0xeb/0x2a0 + ? kunit_try_catch_run+0x210/0x210 + kunit_try_run_case+0x74/0x160 + ? kunit_try_catch_run+0x210/0x210 + kunit_generic_run_threadfn_adapter+0x12/0x30 + kthread+0x21c/0x230 + ? __do_trace_sched_kthread_stop_ret+0x40/0x40 + ret_from_fork+0x16c/0x270 + ? __do_trace_sched_kthread_stop_ret+0x40/0x40 + ret_from_fork_asm+0x11/0x20 + + +This is because the destructor of maple tree calls mas_find() without +taking rcu_read_lock() or the spinlock. Doing that is actually ok in this +case since the destructor has exclusive access to the entire maple tree, +but it triggers a lockdep warning. To fix that, take the rcu read lock. + +In the future, it's possible that memory reclaim could gain a feature +where it reallocates entries in maple trees even if no user-code is +touching it. If that feature is added, then this use of rcu read lock +would become load-bearing, so I did not make it conditional on lockdep. + +We have to repeatedly take and release rcu because the destructor of T +might perform operations that sleep. + +Link: https://lkml.kernel.org/r/20251217-maple-drop-rcu-v1-1-702af063573f@google.com +Fixes: da939ef4c494 ("rust: maple_tree: add MapleTree") +Signed-off-by: Alice Ryhl +Reported-by: Andreas Hindborg +Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/564215108 +Reviewed-by: Gary Guo +Reviewed-by: Daniel Almeida +Cc: Andrew Ballance +Cc: Björn Roy Baron +Cc: Boqun Feng +Cc: Danilo Krummrich +Cc: Liam Howlett +Cc: Matthew Wilcox (Oracle) +Cc: Miguel Ojeda +Cc: Trevor Gross +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + rust/kernel/maple_tree.rs | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +diff --git a/rust/kernel/maple_tree.rs b/rust/kernel/maple_tree.rs +index e72eec56bf57..265d6396a78a 100644 +--- a/rust/kernel/maple_tree.rs ++++ b/rust/kernel/maple_tree.rs +@@ -265,7 +265,16 @@ impl MapleTree { + loop { + // This uses the raw accessor because we're destroying pointers without removing them + // from the maple tree, which is only valid because this is the destructor. +- let ptr = ma_state.mas_find_raw(usize::MAX); ++ // ++ // Take the rcu lock because mas_find_raw() requires that you hold either the spinlock ++ // or the rcu read lock. This is only really required if memory reclaim might ++ // reallocate entries in the tree, as we otherwise have exclusive access. That feature ++ // doesn't exist yet, so for now, taking the rcu lock only serves the purpose of ++ // silencing lockdep. ++ let ptr = { ++ let _rcu = kernel::sync::rcu::Guard::new(); ++ ma_state.mas_find_raw(usize::MAX) ++ }; + if ptr.is_null() { + break; + } +-- +2.52.0 + diff --git a/queue-6.18/samples-ftrace-adjust-loongarch-register-restore-order-in-direct-calls.patch b/queue-6.18/samples-ftrace-adjust-loongarch-register-restore-order-in-direct-calls.patch new file mode 100644 index 0000000000..0ece9428d4 --- /dev/null +++ b/queue-6.18/samples-ftrace-adjust-loongarch-register-restore-order-in-direct-calls.patch @@ -0,0 +1,117 @@ +From bb85d206be208bbf834883e948125a35ac59993a Mon Sep 17 00:00:00 2001 +From: Chenghao Duan +Date: Wed, 31 Dec 2025 15:19:25 +0800 +Subject: samples/ftrace: Adjust LoongArch register restore order in direct calls + +From: Chenghao Duan + +commit bb85d206be208bbf834883e948125a35ac59993a upstream. + +Ensure that in the ftrace direct call logic, the CPU register state +(with ra = parent return address) is restored to the correct state after +the execution of the custom trampoline function and before returning to +the traced function. Additionally, guarantee the correctness of the jump +logic for jr t0 (traced function address). + +Cc: stable@vger.kernel.org +Fixes: 9cdc3b6a299c ("LoongArch: ftrace: Add direct call support") +Reported-by: Youling Tang +Acked-by: Steven Rostedt (Google) +Signed-off-by: Chenghao Duan +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + samples/ftrace/ftrace-direct-modify.c | 8 ++++---- + samples/ftrace/ftrace-direct-multi-modify.c | 8 ++++---- + samples/ftrace/ftrace-direct-multi.c | 4 ++-- + samples/ftrace/ftrace-direct-too.c | 4 ++-- + samples/ftrace/ftrace-direct.c | 4 ++-- + 5 files changed, 14 insertions(+), 14 deletions(-) + +--- a/samples/ftrace/ftrace-direct-modify.c ++++ b/samples/ftrace/ftrace-direct-modify.c +@@ -176,8 +176,8 @@ asm ( + " st.d $t0, $sp, 0\n" + " st.d $ra, $sp, 8\n" + " bl my_direct_func1\n" +-" ld.d $t0, $sp, 0\n" +-" ld.d $ra, $sp, 8\n" ++" ld.d $ra, $sp, 0\n" ++" ld.d $t0, $sp, 8\n" + " addi.d $sp, $sp, 16\n" + " jr $t0\n" + " .size my_tramp1, .-my_tramp1\n" +@@ -189,8 +189,8 @@ asm ( + " st.d $t0, $sp, 0\n" + " st.d $ra, $sp, 8\n" + " bl my_direct_func2\n" +-" ld.d $t0, $sp, 0\n" +-" ld.d $ra, $sp, 8\n" ++" ld.d $ra, $sp, 0\n" ++" ld.d $t0, $sp, 8\n" + " addi.d $sp, $sp, 16\n" + " jr $t0\n" + " .size my_tramp2, .-my_tramp2\n" +--- a/samples/ftrace/ftrace-direct-multi-modify.c ++++ b/samples/ftrace/ftrace-direct-multi-modify.c +@@ -199,8 +199,8 @@ asm ( + " move $a0, $t0\n" + " bl my_direct_func1\n" + " ld.d $a0, $sp, 0\n" +-" ld.d $t0, $sp, 8\n" +-" ld.d $ra, $sp, 16\n" ++" ld.d $ra, $sp, 8\n" ++" ld.d $t0, $sp, 16\n" + " addi.d $sp, $sp, 32\n" + " jr $t0\n" + " .size my_tramp1, .-my_tramp1\n" +@@ -215,8 +215,8 @@ asm ( + " move $a0, $t0\n" + " bl my_direct_func2\n" + " ld.d $a0, $sp, 0\n" +-" ld.d $t0, $sp, 8\n" +-" ld.d $ra, $sp, 16\n" ++" ld.d $ra, $sp, 8\n" ++" ld.d $t0, $sp, 16\n" + " addi.d $sp, $sp, 32\n" + " jr $t0\n" + " .size my_tramp2, .-my_tramp2\n" +--- a/samples/ftrace/ftrace-direct-multi.c ++++ b/samples/ftrace/ftrace-direct-multi.c +@@ -131,8 +131,8 @@ asm ( + " move $a0, $t0\n" + " bl my_direct_func\n" + " ld.d $a0, $sp, 0\n" +-" ld.d $t0, $sp, 8\n" +-" ld.d $ra, $sp, 16\n" ++" ld.d $ra, $sp, 8\n" ++" ld.d $t0, $sp, 16\n" + " addi.d $sp, $sp, 32\n" + " jr $t0\n" + " .size my_tramp, .-my_tramp\n" +--- a/samples/ftrace/ftrace-direct-too.c ++++ b/samples/ftrace/ftrace-direct-too.c +@@ -143,8 +143,8 @@ asm ( + " ld.d $a0, $sp, 0\n" + " ld.d $a1, $sp, 8\n" + " ld.d $a2, $sp, 16\n" +-" ld.d $t0, $sp, 24\n" +-" ld.d $ra, $sp, 32\n" ++" ld.d $ra, $sp, 24\n" ++" ld.d $t0, $sp, 32\n" + " addi.d $sp, $sp, 48\n" + " jr $t0\n" + " .size my_tramp, .-my_tramp\n" +--- a/samples/ftrace/ftrace-direct.c ++++ b/samples/ftrace/ftrace-direct.c +@@ -124,8 +124,8 @@ asm ( + " st.d $ra, $sp, 16\n" + " bl my_direct_func\n" + " ld.d $a0, $sp, 0\n" +-" ld.d $t0, $sp, 8\n" +-" ld.d $ra, $sp, 16\n" ++" ld.d $ra, $sp, 8\n" ++" ld.d $t0, $sp, 16\n" + " addi.d $sp, $sp, 32\n" + " jr $t0\n" + " .size my_tramp, .-my_tramp\n" diff --git a/queue-6.18/selftests-mm-fix-thread-state-check-in-uffd-unit-tests.patch b/queue-6.18/selftests-mm-fix-thread-state-check-in-uffd-unit-tests.patch new file mode 100644 index 0000000000..637d3f4326 --- /dev/null +++ b/queue-6.18/selftests-mm-fix-thread-state-check-in-uffd-unit-tests.patch @@ -0,0 +1,66 @@ +From 632b874d59a36caf829ab5790dafb90f9b350fd6 Mon Sep 17 00:00:00 2001 +From: Wake Liu +Date: Wed, 10 Dec 2025 17:14:08 +0800 +Subject: selftests/mm: fix thread state check in uffd-unit-tests + +From: Wake Liu + +commit 632b874d59a36caf829ab5790dafb90f9b350fd6 upstream. + +In the thread_state_get() function, the logic to find the thread's state +character was using `sizeof(header) - 1` to calculate the offset from the +"State:\t" string. + +The `header` variable is a `const char *` pointer. `sizeof()` on a +pointer returns the size of the pointer itself, not the length of the +string literal it points to. This makes the code's behavior dependent on +the architecture's pointer size. + +This bug was identified on a 32-bit ARM build (`gsi_tv_arm`) for Android, +running on an ARMv8-based device, compiled with Clang 19.0.1. + +On this 32-bit architecture, `sizeof(char *)` is 4. The expression +`sizeof(header) - 1` resulted in an incorrect offset of 3, causing the +test to read the wrong character from `/proc/[tid]/status` and fail. + +On 64-bit architectures, `sizeof(char *)` is 8, so the expression +coincidentally evaluates to 7, which matches the length of "State:\t". +This is why the bug likely remained hidden on 64-bit builds. + +To fix this and make the code portable and correct across all +architectures, this patch replaces `sizeof(header) - 1` with +`strlen(header)`. The `strlen()` function correctly calculates the +string's length, ensuring the correct offset is always used. + +Link: https://lkml.kernel.org/r/20251210091408.3781445-1-wakel@google.com +Fixes: f60b6634cd88 ("mm/selftests: add a test to verify mmap_changing race with -EAGAIN") +Signed-off-by: Wake Liu +Acked-by: Peter Xu +Reviewed-by: Mike Rapoport (Microsoft) +Cc: Bill Wendling +Cc: Justin Stitt +Cc: Liam Howlett +Cc: Lorenzo Stoakes +Cc: Michal Hocko +Cc: Nathan Chancellor +Cc: Shuah Khan +Cc: Suren Baghdasaryan +Cc: Vlastimil Babka +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/mm/uffd-unit-tests.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/tools/testing/selftests/mm/uffd-unit-tests.c ++++ b/tools/testing/selftests/mm/uffd-unit-tests.c +@@ -1317,7 +1317,7 @@ static thread_state thread_state_get(pid + p = strstr(tmp, header); + if (p) { + /* For example, "State:\tD (disk sleep)" */ +- c = *(p + sizeof(header) - 1); ++ c = *(p + strlen(header)); + return c == 'D' ? + THR_STATE_UNINTERRUPTIBLE : THR_STATE_UNKNOWN; + } diff --git a/queue-6.18/series b/queue-6.18/series index 0b4cd2fc49..2549552b05 100644 --- a/queue-6.18/series +++ b/queue-6.18/series @@ -214,3 +214,48 @@ mm-damon-tests-core-kunit-handle-alloc-failures-on-damos_test_filter_out.patch mm-damon-tests-core-kunit-handle-alloc-failures-in-damon_test_ops_registration.patch mm-damon-tests-core-kunit-handle-alloc-failure-on-damon_test_set_attrs.patch mm-damon-tests-core-kunit-handle-alloc-failure-on-damos_test_commit_filter.patch +pmdomain-mtk-pm-domains-fix-spinlock-recursion-fix-in-probe.patch +pmdomain-imx-fix-reference-count-leak-in-imx_gpc_probe.patch +af_unix-don-t-post-cmsg-for-so_inq-unless-explicitly-asked-for.patch +compiler_types.h-add-auto-as-a-macro-for-__auto_type.patch +mptcp-fallback-earlier-on-simult-connection.patch +mm-kasan-fix-incorrect-unpoisoning-in-vrealloc-for-kasan.patch +kasan-refactor-pcpu-kasan-vmalloc-unpoison.patch +kasan-unpoison-vms-addresses-with-a-common-tag.patch +kernel-kexec-change-the-prototype-of-kimage_map_segment.patch +kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch +lockd-fix-vfs_test_lock-calls.patch +idr-fix-idr_alloc-returning-an-id-out-of-range.patch +mm-page_alloc-change-all-pageblocks-migrate-type-on-coalescing.patch +mm-page_owner-fix-memory-leak-in-page_owner_stack_fops-release.patch +mm-consider-non-anon-swap-cache-folios-in-folio_expected_ref_count.patch +x86-microcode-amd-fix-entrysign-revision-check-for-zen5-strix-halo.patch +tools-mm-page_owner_sort-fix-timestamp-comparison-for-stable-sorting.patch +selftests-mm-fix-thread-state-check-in-uffd-unit-tests.patch +samples-ftrace-adjust-loongarch-register-restore-order-in-direct-calls.patch +rust-maple_tree-rcu_read_lock-in-destructor-to-silence-lockdep.patch +rdma-core-check-for-the-presence-of-ls_nla_type_dgid-correctly.patch +rdma-cm-fix-leaking-the-multicast-gid-table-reference.patch +wifi-iwlwifi-fix-firmware-version-handling.patch +wifi-mac80211-discard-beacon-frames-to-non-broadcast-address.patch +e1000-fix-oob-in-e1000_tbi_should_accept.patch +erspan-initialize-options_len-before-referencing-options.patch +fjes-add-missing-iounmap-in-fjes_hw_init.patch +gve-defer-interrupt-enabling-until-napi-registration.patch +loongarch-refactor-register-restoration-in-ftrace_common_return.patch +loongarch-bpf-zero-extend-bpf_tail_call-index.patch +loongarch-bpf-sign-extend-kfunc-call-arguments.patch +loongarch-bpf-save-return-address-register-ra-to-t0-before-trampoline.patch +loongarch-bpf-enable-trampoline-based-tracing-for-module-functions.patch +loongarch-bpf-adjust-the-jump-offset-of-tail-calls.patch +nfsd-fix-nfsd_file-reference-leak-in-nfsd4_add_rdaccess_to_wrdeleg.patch +nfsd-use-attr_deleg-in-nfsd4_finalize_deleg_timestamps.patch +nfsd-drop-the-client-reference-in-client_states_open.patch +net-usb-sr9700-fix-incorrect-command-used-to-write-single-register.patch +net-phy-mediatek-fix-nvmem-cell-reference-leak-in-mt798x_phy_calibration.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 +platform-x86-samsung-galaxybook-fix-problematic-pointer-cast.patch +platform-x86-alienware-wmi-wmax-add-support-for-new-area-51-laptops.patch +platform-x86-alienware-wmi-wmax-add-awcc-support-for-alienware-x16.patch +platform-x86-alienware-wmi-wmax-add-support-for-alienware-16x-aurora.patch diff --git a/queue-6.18/tools-mm-page_owner_sort-fix-timestamp-comparison-for-stable-sorting.patch b/queue-6.18/tools-mm-page_owner_sort-fix-timestamp-comparison-for-stable-sorting.patch new file mode 100644 index 0000000000..94fc451058 --- /dev/null +++ b/queue-6.18/tools-mm-page_owner_sort-fix-timestamp-comparison-for-stable-sorting.patch @@ -0,0 +1,40 @@ +From 7013803444dd3bbbe28fd3360c084cec3057c554 Mon Sep 17 00:00:00 2001 +From: Kaushlendra Kumar +Date: Tue, 9 Dec 2025 10:15:52 +0530 +Subject: tools/mm/page_owner_sort: fix timestamp comparison for stable sorting + +From: Kaushlendra Kumar + +commit 7013803444dd3bbbe28fd3360c084cec3057c554 upstream. + +The ternary operator in compare_ts() returns 1 when timestamps are equal, +causing unstable sorting behavior. Replace with explicit three-way +comparison that returns 0 for equal timestamps, ensuring stable qsort +ordering and consistent output. + +Link: https://lkml.kernel.org/r/20251209044552.3396468-1-kaushlendra.kumar@intel.com +Fixes: 8f9c447e2e2b ("tools/vm/page_owner_sort.c: support sorting pid and time") +Signed-off-by: Kaushlendra Kumar +Cc: Chongxi Zhao +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + tools/mm/page_owner_sort.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/tools/mm/page_owner_sort.c ++++ b/tools/mm/page_owner_sort.c +@@ -183,7 +183,11 @@ static int compare_ts(const void *p1, co + { + const struct block_list *l1 = p1, *l2 = p2; + +- return l1->ts_nsec < l2->ts_nsec ? -1 : 1; ++ if (l1->ts_nsec < l2->ts_nsec) ++ return -1; ++ if (l1->ts_nsec > l2->ts_nsec) ++ return 1; ++ return 0; + } + + static int compare_cull_condition(const void *p1, const void *p2) diff --git a/queue-6.18/wifi-iwlwifi-fix-firmware-version-handling.patch b/queue-6.18/wifi-iwlwifi-fix-firmware-version-handling.patch new file mode 100644 index 0000000000..c05735c55e --- /dev/null +++ b/queue-6.18/wifi-iwlwifi-fix-firmware-version-handling.patch @@ -0,0 +1,62 @@ +From ca5898222914f399797cea1aeb0ce77109ca2e62 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Fri, 14 Nov 2025 00:28:52 +0200 +Subject: wifi: iwlwifi: Fix firmware version handling +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit ca5898222914f399797cea1aeb0ce77109ca2e62 upstream. + +On my system the arithmetic done on the firmware numbers +results in a negative number, but since the types are +unsigned it gets interpreted as a large positive number. + +The end result is that the firmware gets rejected and wifi +is defunct. + +Switch to signed types to handle this case correctly. + +iwlwifi 0000:0c:00.0: Driver unable to support your firmware API. Driver supports FW core 4294967294..2, firmware is 2. +iwlwifi 0000:0c:00.0: Direct firmware load for iwlwifi-5000-4.ucode failed with error -2 +iwlwifi 0000:0c:00.0: Direct firmware load for iwlwifi-5000-3.ucode failed with error -2 +iwlwifi 0000:0c:00.0: Direct firmware load for iwlwifi-5000-2.ucode failed with error -2 +iwlwifi 0000:0c:00.0: Direct firmware load for iwlwifi-5000-1.ucode failed with error -2 +iwlwifi 0000:0c:00.0: no suitable firmware found! +iwlwifi 0000:0c:00.0: minimum version required: iwlwifi-5000-1 +iwlwifi 0000:0c:00.0: maximum version supported: iwlwifi-5000-5 +iwlwifi 0000:0c:00.0: check git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git + +Cc: stable@vger.kernel.org +Fixes: 5f708cccde9d ("wifi: iwlwifi: add a new FW file numbering scheme") +Signed-off-by: Ville Syrjälä +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220805 +Link: https://patch.msgid.link/20251113222852.15896-1-ville.syrjala@linux.intel.com +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c ++++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c +@@ -1599,7 +1599,7 @@ static void _iwl_op_mode_stop(struct iwl + */ + static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context) + { +- unsigned int min_core, max_core, loaded_core; ++ int min_core, max_core, loaded_core; + struct iwl_drv *drv = context; + struct iwl_fw *fw = &drv->fw; + const struct iwl_ucode_header *ucode; +@@ -1678,7 +1678,7 @@ static void iwl_req_fw_callback(const st + if (loaded_core < min_core || loaded_core > max_core) { + IWL_ERR(drv, + "Driver unable to support your firmware API. " +- "Driver supports FW core %u..%u, firmware is %u.\n", ++ "Driver supports FW core %d..%d, firmware is %d.\n", + min_core, max_core, loaded_core); + goto try_again; + } diff --git a/queue-6.18/wifi-mac80211-discard-beacon-frames-to-non-broadcast-address.patch b/queue-6.18/wifi-mac80211-discard-beacon-frames-to-non-broadcast-address.patch new file mode 100644 index 0000000000..7678d8041a --- /dev/null +++ b/queue-6.18/wifi-mac80211-discard-beacon-frames-to-non-broadcast-address.patch @@ -0,0 +1,57 @@ +From 193d18f60588e95d62e0f82b6a53893e5f2f19f8 Mon Sep 17 00:00:00 2001 +From: Jouni Malinen +Date: Mon, 15 Dec 2025 17:11:34 +0200 +Subject: wifi: mac80211: Discard Beacon frames to non-broadcast address + +From: Jouni Malinen + +commit 193d18f60588e95d62e0f82b6a53893e5f2f19f8 upstream. + +Beacon frames are required to be sent to the broadcast address, see IEEE +Std 802.11-2020, 11.1.3.1 ("The Address 1 field of the Beacon .. frame +shall be set to the broadcast address"). A unicast Beacon frame might be +used as a targeted attack to get one of the associated STAs to do +something (e.g., using CSA to move it to another channel). As such, it +is better have strict filtering for this on the received side and +discard all Beacon frames that are sent to an unexpected address. + +This is even more important for cases where beacon protection is used. +The current implementation in mac80211 is correctly discarding unicast +Beacon frames if the Protected Frame bit in the Frame Control field is +set to 0. However, if that bit is set to 1, the logic used for checking +for configured BIGTK(s) does not actually work. If the driver does not +have logic for dropping unicast Beacon frames with Protected Frame bit +1, these frames would be accepted in mac80211 processing as valid Beacon +frames even though they are not protected. This would allow beacon +protection to be bypassed. While the logic for checking beacon +protection could be extended to cover this corner case, a more generic +check for discard all Beacon frames based on A1=unicast address covers +this without needing additional changes. + +Address all these issues by dropping received Beacon frames if they are +sent to a non-broadcast address. + +Cc: stable@vger.kernel.org +Fixes: af2d14b01c32 ("mac80211: Beacon protection using the new BIGTK (STA)") +Signed-off-by: Jouni Malinen +Link: https://patch.msgid.link/20251215151134.104501-1-jouni.malinen@oss.qualcomm.com +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + net/mac80211/rx.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/net/mac80211/rx.c ++++ b/net/mac80211/rx.c +@@ -3428,6 +3428,11 @@ ieee80211_rx_h_mgmt_check(struct ieee802 + rx->skb->len < IEEE80211_MIN_ACTION_SIZE) + return RX_DROP_U_RUNT_ACTION; + ++ /* Drop non-broadcast Beacon frames */ ++ if (ieee80211_is_beacon(mgmt->frame_control) && ++ !is_broadcast_ether_addr(mgmt->da)) ++ return RX_DROP; ++ + if (rx->sdata->vif.type == NL80211_IFTYPE_AP && + ieee80211_is_beacon(mgmt->frame_control) && + !(rx->flags & IEEE80211_RX_BEACON_REPORTED)) { diff --git a/queue-6.18/x86-microcode-amd-fix-entrysign-revision-check-for-zen5-strix-halo.patch b/queue-6.18/x86-microcode-amd-fix-entrysign-revision-check-for-zen5-strix-halo.patch new file mode 100644 index 0000000000..67947782f2 --- /dev/null +++ b/queue-6.18/x86-microcode-amd-fix-entrysign-revision-check-for-zen5-strix-halo.patch @@ -0,0 +1,33 @@ +From 150b1b97e27513535dcd3795d5ecd28e61b6cb8c Mon Sep 17 00:00:00 2001 +From: Rong Zhang +Date: Tue, 30 Dec 2025 02:22:21 +0800 +Subject: x86/microcode/AMD: Fix Entrysign revision check for Zen5/Strix Halo + +From: Rong Zhang + +commit 150b1b97e27513535dcd3795d5ecd28e61b6cb8c upstream. + +Zen5 also contains family 1Ah, models 70h-7Fh, which are mistakenly missing +from cpu_has_entrysign(). Add the missing range. + +Fixes: 8a9fb5129e8e ("x86/microcode/AMD: Limit Entrysign signature checking to known generations") +Signed-off-by: Rong Zhang +Signed-off-by: Borislav Petkov (AMD) +Cc: stable@kernel.org +Link: https://patch.msgid.link/20251229182245.152747-1-i@rong.moe +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/microcode/amd.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/cpu/microcode/amd.c ++++ b/arch/x86/kernel/cpu/microcode/amd.c +@@ -258,7 +258,7 @@ static bool cpu_has_entrysign(void) + if (fam == 0x1a) { + if (model <= 0x2f || + (0x40 <= model && model <= 0x4f) || +- (0x60 <= model && model <= 0x6f)) ++ (0x60 <= model && model <= 0x7f)) + return true; + } +