From ac27d99b44106de825a1972d3dd7315ae9d0d28c Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 15 Aug 2025 19:03:33 +0200 Subject: [PATCH] 6.15-stable patches added patches: clk-samsung-exynos850-fix-a-comment.patch clk-samsung-gs101-fix-alternate-mout_hsi0_usb20_ref-parent-clock.patch clk-samsung-gs101-fix-clk_dout_cmu_g3d_busd.patch fs-prevent-file-descriptor-table-allocations-exceeding-int_max.patch fscrypt-don-t-use-problematic-non-inline-crypto-engines.patch loongarch-avoid-in-place-string-operation-on-fdt-content.patch loongarch-bpf-fix-jump-offset-calculation-in-tailcall.patch loongarch-don-t-use-pk-through-printk-in-unwinder.patch loongarch-make-relocate_new_kernel_size-be-a-.quad-value.patch loongarch-vdso-remove-nostdlib-complier-flag.patch nfs-fix-the-setting-of-capabilities-when-automounting-a-new-filesystem.patch nfsd-detect-mismatch-of-file-handle-and-delegation-stateid-in-open-op.patch nfsd-handle-get_client_locked-failure-in-nfsd4_setclientid_confirm.patch pci-extend-isolated-function-probing-to-loongarch.patch sunvdc-balance-device-refcount-in-vdc_port_mpgroup_check.patch --- .../clk-samsung-exynos850-fix-a-comment.patch | 35 +++ ...ate-mout_hsi0_usb20_ref-parent-clock.patch | 36 +++ ...sung-gs101-fix-clk_dout_cmu_g3d_busd.patch | 36 +++ ...-table-allocations-exceeding-int_max.patch | 104 ++++++++ ...roblematic-non-inline-crypto-engines.patch | 244 ++++++++++++++++++ ...lace-string-operation-on-fdt-content.patch | 60 +++++ ...-jump-offset-calculation-in-tailcall.patch | 109 ++++++++ ...-t-use-pk-through-printk-in-unwinder.patch | 44 ++++ ...ate_new_kernel_size-be-a-.quad-value.patch | 33 +++ ...h-vdso-remove-nostdlib-complier-flag.patch | 41 +++ ...s-when-automounting-a-new-filesystem.patch | 164 ++++++++++++ ...le-and-delegation-stateid-in-open-op.patch | 54 ++++ ...failure-in-nfsd4_setclientid_confirm.patch | 71 +++++ ...olated-function-probing-to-loongarch.patch | 41 +++ queue-6.15/series | 15 ++ ...e-refcount-in-vdc_port_mpgroup_check.patch | 48 ++++ 16 files changed, 1135 insertions(+) create mode 100644 queue-6.15/clk-samsung-exynos850-fix-a-comment.patch create mode 100644 queue-6.15/clk-samsung-gs101-fix-alternate-mout_hsi0_usb20_ref-parent-clock.patch create mode 100644 queue-6.15/clk-samsung-gs101-fix-clk_dout_cmu_g3d_busd.patch create mode 100644 queue-6.15/fs-prevent-file-descriptor-table-allocations-exceeding-int_max.patch create mode 100644 queue-6.15/fscrypt-don-t-use-problematic-non-inline-crypto-engines.patch create mode 100644 queue-6.15/loongarch-avoid-in-place-string-operation-on-fdt-content.patch create mode 100644 queue-6.15/loongarch-bpf-fix-jump-offset-calculation-in-tailcall.patch create mode 100644 queue-6.15/loongarch-don-t-use-pk-through-printk-in-unwinder.patch create mode 100644 queue-6.15/loongarch-make-relocate_new_kernel_size-be-a-.quad-value.patch create mode 100644 queue-6.15/loongarch-vdso-remove-nostdlib-complier-flag.patch create mode 100644 queue-6.15/nfs-fix-the-setting-of-capabilities-when-automounting-a-new-filesystem.patch create mode 100644 queue-6.15/nfsd-detect-mismatch-of-file-handle-and-delegation-stateid-in-open-op.patch create mode 100644 queue-6.15/nfsd-handle-get_client_locked-failure-in-nfsd4_setclientid_confirm.patch create mode 100644 queue-6.15/pci-extend-isolated-function-probing-to-loongarch.patch create mode 100644 queue-6.15/sunvdc-balance-device-refcount-in-vdc_port_mpgroup_check.patch diff --git a/queue-6.15/clk-samsung-exynos850-fix-a-comment.patch b/queue-6.15/clk-samsung-exynos850-fix-a-comment.patch new file mode 100644 index 0000000000..6fd4bb89da --- /dev/null +++ b/queue-6.15/clk-samsung-exynos850-fix-a-comment.patch @@ -0,0 +1,35 @@ +From 320e7efce30e2613c2c7877acc46a8e71192cdcd Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Andr=C3=A9=20Draszik?= +Date: Tue, 3 Jun 2025 16:43:21 +0100 +Subject: clk: samsung: exynos850: fix a comment +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: André Draszik + +commit 320e7efce30e2613c2c7877acc46a8e71192cdcd upstream. + +The code below the updated comment is for CMU_CPUCL1, not CMU_CPUCL0. + +Fixes: dedf87341ad6 ("clk: samsung: exynos850: Add CMU_CPUCL0 and CMU_CPUCL1") +Cc: stable@vger.kernel.org +Signed-off-by: André Draszik +Link: https://lore.kernel.org/r/20250603-samsung-clk-fixes-v1-3-49daf1ff4592@linaro.org +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/clk/samsung/clk-exynos850.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/clk/samsung/clk-exynos850.c ++++ b/drivers/clk/samsung/clk-exynos850.c +@@ -1360,7 +1360,7 @@ static const unsigned long cpucl1_clk_re + CLK_CON_GAT_GATE_CLK_CPUCL1_CPU, + }; + +-/* List of parent clocks for Muxes in CMU_CPUCL0 */ ++/* List of parent clocks for Muxes in CMU_CPUCL1 */ + PNAME(mout_pll_cpucl1_p) = { "oscclk", "fout_cpucl1_pll" }; + PNAME(mout_cpucl1_switch_user_p) = { "oscclk", "dout_cpucl1_switch" }; + PNAME(mout_cpucl1_dbg_user_p) = { "oscclk", "dout_cpucl1_dbg" }; diff --git a/queue-6.15/clk-samsung-gs101-fix-alternate-mout_hsi0_usb20_ref-parent-clock.patch b/queue-6.15/clk-samsung-gs101-fix-alternate-mout_hsi0_usb20_ref-parent-clock.patch new file mode 100644 index 0000000000..c85539b9c8 --- /dev/null +++ b/queue-6.15/clk-samsung-gs101-fix-alternate-mout_hsi0_usb20_ref-parent-clock.patch @@ -0,0 +1,36 @@ +From ca243e653f71d8c4724a68c9033923f945b1084d Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Andr=C3=A9=20Draszik?= +Date: Tue, 3 Jun 2025 16:43:20 +0100 +Subject: clk: samsung: gs101: fix alternate mout_hsi0_usb20_ref parent clock +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: André Draszik + +commit ca243e653f71d8c4724a68c9033923f945b1084d upstream. + +The alternate parent clock for this mux is mout_pll_usb, not the pll +itself. + +Fixes: 1891e4d48755 ("clk: samsung: gs101: add support for cmu_hsi0") +Cc: stable@vger.kernel.org +Signed-off-by: André Draszik +Link: https://lore.kernel.org/r/20250603-samsung-clk-fixes-v1-2-49daf1ff4592@linaro.org +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/clk/samsung/clk-gs101.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/clk/samsung/clk-gs101.c ++++ b/drivers/clk/samsung/clk-gs101.c +@@ -2129,7 +2129,7 @@ PNAME(mout_hsi0_usbdpdbg_user_p) = { "os + "dout_cmu_hsi0_usbdpdbg" }; + PNAME(mout_hsi0_bus_p) = { "mout_hsi0_bus_user", + "mout_hsi0_alt_user" }; +-PNAME(mout_hsi0_usb20_ref_p) = { "fout_usb_pll", ++PNAME(mout_hsi0_usb20_ref_p) = { "mout_pll_usb", + "mout_hsi0_tcxo_user" }; + PNAME(mout_hsi0_usb31drd_p) = { "fout_usb_pll", + "mout_hsi0_usb31drd_user", diff --git a/queue-6.15/clk-samsung-gs101-fix-clk_dout_cmu_g3d_busd.patch b/queue-6.15/clk-samsung-gs101-fix-clk_dout_cmu_g3d_busd.patch new file mode 100644 index 0000000000..a8ebeaa8e7 --- /dev/null +++ b/queue-6.15/clk-samsung-gs101-fix-clk_dout_cmu_g3d_busd.patch @@ -0,0 +1,36 @@ +From 29a9361f0b50be2b16d308695e30ee030fedea2c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Andr=C3=A9=20Draszik?= +Date: Tue, 3 Jun 2025 16:43:19 +0100 +Subject: clk: samsung: gs101: fix CLK_DOUT_CMU_G3D_BUSD +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: André Draszik + +commit 29a9361f0b50be2b16d308695e30ee030fedea2c upstream. + +Use the correct Linux clock ID when instantiating the G3D_BUSD +div_clock. + +Fixes: 2c597bb7d66a ("clk: samsung: clk-gs101: Add cmu_top, cmu_misc and cmu_apm support") +Cc: stable@vger.kernel.org +Signed-off-by: André Draszik +Link: https://lore.kernel.org/r/20250603-samsung-clk-fixes-v1-1-49daf1ff4592@linaro.org +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/clk/samsung/clk-gs101.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/clk/samsung/clk-gs101.c ++++ b/drivers/clk/samsung/clk-gs101.c +@@ -1154,7 +1154,7 @@ static const struct samsung_div_clock cm + CLK_CON_DIV_CLKCMU_G2D_MSCL, 0, 4), + DIV(CLK_DOUT_CMU_G3AA_G3AA, "dout_cmu_g3aa_g3aa", "gout_cmu_g3aa_g3aa", + CLK_CON_DIV_CLKCMU_G3AA_G3AA, 0, 4), +- DIV(CLK_DOUT_CMU_G3D_SWITCH, "dout_cmu_g3d_busd", "gout_cmu_g3d_busd", ++ DIV(CLK_DOUT_CMU_G3D_BUSD, "dout_cmu_g3d_busd", "gout_cmu_g3d_busd", + CLK_CON_DIV_CLKCMU_G3D_BUSD, 0, 4), + DIV(CLK_DOUT_CMU_G3D_GLB, "dout_cmu_g3d_glb", "gout_cmu_g3d_glb", + CLK_CON_DIV_CLKCMU_G3D_GLB, 0, 4), diff --git a/queue-6.15/fs-prevent-file-descriptor-table-allocations-exceeding-int_max.patch b/queue-6.15/fs-prevent-file-descriptor-table-allocations-exceeding-int_max.patch new file mode 100644 index 0000000000..b1a3cc9767 --- /dev/null +++ b/queue-6.15/fs-prevent-file-descriptor-table-allocations-exceeding-int_max.patch @@ -0,0 +1,104 @@ +From 04a2c4b4511d186b0fce685da21085a5d4acd370 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 29 Jun 2025 03:40:21 -0400 +Subject: fs: Prevent file descriptor table allocations exceeding INT_MAX + +From: Sasha Levin + +commit 04a2c4b4511d186b0fce685da21085a5d4acd370 upstream. + +When sysctl_nr_open is set to a very high value (for example, 1073741816 +as set by systemd), processes attempting to use file descriptors near +the limit can trigger massive memory allocation attempts that exceed +INT_MAX, resulting in a WARNING in mm/slub.c: + + WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288 + +This happens because kvmalloc_array() and kvmalloc() check if the +requested size exceeds INT_MAX and emit a warning when the allocation is +not flagged with __GFP_NOWARN. + +Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a +process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: +- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes +- Multiple bitmaps: ~400MB +- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647) + +Reproducer: +1. Set /proc/sys/fs/nr_open to 1073741816: + # echo 1073741816 > /proc/sys/fs/nr_open + +2. Run a program that uses a high file descriptor: + #include + #include + + int main() { + struct rlimit rlim = {1073741824, 1073741824}; + setrlimit(RLIMIT_NOFILE, &rlim); + dup2(2, 1073741880); // Triggers the warning + return 0; + } + +3. Observe WARNING in dmesg at mm/slub.c:5027 + +systemd commit a8b627a introduced automatic bumping of fs.nr_open to the +maximum possible value. The rationale was that systems with memory +control groups (memcg) no longer need separate file descriptor limits +since memory is properly accounted. However, this change overlooked +that: + +1. The kernel's allocation functions still enforce INT_MAX as a maximum + size regardless of memcg accounting +2. Programs and tests that legitimately test file descriptor limits can + inadvertently trigger massive allocations +3. The resulting allocations (>8GB) are impractical and will always fail + +systemd's algorithm starts with INT_MAX and keeps halving the value +until the kernel accepts it. On most systems, this results in nr_open +being set to 1073741816 (0x3ffffff8), which is just under 1GB of file +descriptors. + +While processes rarely use file descriptors near this limit in normal +operation, certain selftests (like +tools/testing/selftests/core/unshare_test.c) and programs that test file +descriptor limits can trigger this issue. + +Fix this by adding a check in alloc_fdtable() to ensure the requested +allocation size does not exceed INT_MAX. This causes the operation to +fail with -EMFILE instead of triggering a kernel warning and avoids the +impractical >8GB memory allocation request. + +Fixes: 9cfe015aa424 ("get rid of NR_OPEN and introduce a sysctl_nr_open") +Cc: stable@vger.kernel.org +Signed-off-by: Sasha Levin +Link: https://lore.kernel.org/20250629074021.1038845-1-sashal@kernel.org +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman +--- + fs/file.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/fs/file.c ++++ b/fs/file.c +@@ -197,6 +197,21 @@ static struct fdtable *alloc_fdtable(uns + return ERR_PTR(-EMFILE); + } + ++ /* ++ * Check if the allocation size would exceed INT_MAX. kvmalloc_array() ++ * and kvmalloc() will warn if the allocation size is greater than ++ * INT_MAX, as filp_cachep objects are not __GFP_NOWARN. ++ * ++ * This can happen when sysctl_nr_open is set to a very high value and ++ * a process tries to use a file descriptor near that limit. For example, ++ * if sysctl_nr_open is set to 1073741816 (0x3ffffff8) - which is what ++ * systemd typically sets it to - then trying to use a file descriptor ++ * close to that value will require allocating a file descriptor table ++ * that exceeds 8GB in size. ++ */ ++ if (unlikely(nr > INT_MAX / sizeof(struct file *))) ++ return ERR_PTR(-EMFILE); ++ + fdt = kmalloc(sizeof(struct fdtable), GFP_KERNEL_ACCOUNT); + if (!fdt) + goto out; diff --git a/queue-6.15/fscrypt-don-t-use-problematic-non-inline-crypto-engines.patch b/queue-6.15/fscrypt-don-t-use-problematic-non-inline-crypto-engines.patch new file mode 100644 index 0000000000..daf41f2d53 --- /dev/null +++ b/queue-6.15/fscrypt-don-t-use-problematic-non-inline-crypto-engines.patch @@ -0,0 +1,244 @@ +From b41c1d8d07906786c60893980d52688f31d114a6 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Fri, 4 Jul 2025 00:03:22 -0700 +Subject: fscrypt: Don't use problematic non-inline crypto engines + +From: Eric Biggers + +commit b41c1d8d07906786c60893980d52688f31d114a6 upstream. + +Make fscrypt no longer use Crypto API drivers for non-inline crypto +engines, even when the Crypto API prioritizes them over CPU-based code +(which unfortunately it often does). These drivers tend to be really +problematic, especially for fscrypt's workload. This commit has no +effect on inline crypto engines, which are different and do work well. + +Specifically, exclude drivers that have CRYPTO_ALG_KERN_DRIVER_ONLY or +CRYPTO_ALG_ALLOCATES_MEMORY set. (Later, CRYPTO_ALG_ASYNC should be +excluded too. That's omitted for now to keep this commit backportable, +since until recently some CPU-based code had CRYPTO_ALG_ASYNC set.) + +There are two major issues with these drivers: bugs and performance. + +First, these drivers tend to be buggy. They're fundamentally much more +error-prone and harder to test than the CPU-based code. They often +don't get tested before kernel releases, and even if they do, the crypto +self-tests don't properly test these drivers. Released drivers have +en/decrypted or hashed data incorrectly. These bugs cause issues for +fscrypt users who often didn't even want to use these drivers, e.g.: + +- https://github.com/google/fscryptctl/issues/32 +- https://github.com/google/fscryptctl/issues/9 +- https://lore.kernel.org/r/PH0PR02MB731916ECDB6C613665863B6CFFAA2@PH0PR02MB7319.namprd02.prod.outlook.com + +These drivers have also similarly caused issues for dm-crypt users, +including data corruption and deadlocks. Since Linux v5.10, dm-crypt +has disabled most of them by excluding CRYPTO_ALG_ALLOCATES_MEMORY. + +Second, these drivers tend to be *much* slower than the CPU-based code. +This may seem counterintuitive, but benchmarks clearly show it. There's +a *lot* of overhead associated with going to a hardware driver, off the +CPU, and back again. To prove this, I gathered as many systems with +this type of crypto engine as I could, and I measured synchronous +encryption of 4096-byte messages (which matches fscrypt's workload): + +Intel Emerald Rapids server: + AES-256-XTS: + xts-aes-vaes-avx512 16171 MB/s [CPU-based, Vector AES] + qat_aes_xts 289 MB/s [Offload, Intel QuickAssist] + +Qualcomm SM8650 HDK: + AES-256-XTS: + xts-aes-ce 4301 MB/s [CPU-based, ARMv8 Crypto Extensions] + xts-aes-qce 73 MB/s [Offload, Qualcomm Crypto Engine] + +i.MX 8M Nano LPDDR4 EVK: + AES-256-XTS: + xts-aes-ce 647 MB/s [CPU-based, ARMv8 Crypto Extensions] + xts(ecb-aes-caam) 20 MB/s [Offload, CAAM] + AES-128-CBC-ESSIV: + essiv(cbc-aes-caam,sha256-lib) 23 MB/s [Offload, CAAM] + +STM32MP157F-DK2: + AES-256-XTS: + xts-aes-neonbs 13.2 MB/s [CPU-based, ARM NEON] + xts(stm32-ecb-aes) 3.1 MB/s [Offload, STM32 crypto engine] + AES-128-CBC-ESSIV: + essiv(cbc-aes-neonbs,sha256-lib) + 14.7 MB/s [CPU-based, ARM NEON] + essiv(stm32-cbc-aes,sha256-lib) + 3.2 MB/s [Offload, STM32 crypto engine] + Adiantum: + adiantum(xchacha12-arm,aes-arm,nhpoly1305-neon) + 52.8 MB/s [CPU-based, ARM scalar + NEON] + +So, there was no case in which the crypto engine was even *close* to +being faster. On the first three, which have AES instructions in the +CPU, the CPU was 30 to 55 times faster (!). Even on STM32MP157F-DK2 +which has a Cortex-A7 CPU that doesn't have AES instructions, AES was +over 4 times faster on the CPU. And Adiantum encryption, which is what +actually should be used on CPUs like that, was over 17 times faster. + +Other justifications that have been given for these non-inline crypto +engines (almost always coming from the hardware vendors, not actual +users) don't seem very plausible either: + + - The crypto engine throughput could be improved by processing + multiple requests concurrently. Currently irrelevant to fscrypt, + since it doesn't do that. This would also be complex, and unhelpful + in many cases. 2 of the 4 engines I tested even had only one queue. + + - Some of the engines, e.g. STM32, support hardware keys. Also + currently irrelevant to fscrypt, since it doesn't support these. + Interestingly, the STM32 driver itself doesn't support this either. + + - Free up CPU for other tasks and/or reduce energy usage. Not very + plausible considering the "short" message length, driver overhead, + and scheduling overhead. There's just very little time for the CPU + to do something else like run another task or enter low-power state, + before the message finishes and it's time to process the next one. + + - Some of these engines resist power analysis and electromagnetic + attacks, while the CPU-based crypto generally does not. In theory, + this sounds great. In practice, if this benefit requires the use of + an off-CPU offload that massively regresses performance and has a + low-quality, buggy driver, the price for this hardening (which is + not relevant to most fscrypt users, and tends to be incomplete) is + just too high. Inline crypto engines are much more promising here, + as are on-CPU solutions like RISC-V High Assurance Cryptography. + +Fixes: b30ab0e03407 ("ext4 crypto: add ext4 encryption facilities") +Cc: stable@vger.kernel.org +Acked-by: Ard Biesheuvel +Link: https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org +Signed-off-by: Eric Biggers +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/filesystems/fscrypt.rst | 37 +++++++++++++--------------------- + fs/crypto/fscrypt_private.h | 17 +++++++++++++++ + fs/crypto/hkdf.c | 2 - + fs/crypto/keysetup.c | 3 +- + fs/crypto/keysetup_v1.c | 3 +- + 5 files changed, 37 insertions(+), 25 deletions(-) + +--- a/Documentation/filesystems/fscrypt.rst ++++ b/Documentation/filesystems/fscrypt.rst +@@ -140,9 +140,8 @@ However, these ioctls have some limitati + were wiped. To partially solve this, you can add init_on_free=1 to + your kernel command line. However, this has a performance cost. + +-- Secret keys might still exist in CPU registers, in crypto +- accelerator hardware (if used by the crypto API to implement any of +- the algorithms), or in other places not explicitly considered here. ++- Secret keys might still exist in CPU registers or in other places ++ not explicitly considered here. + + Limitations of v1 policies + ~~~~~~~~~~~~~~~~~~~~~~~~~~ +@@ -377,9 +376,12 @@ the work is done by XChaCha12, which is + acceleration is unavailable. For more information about Adiantum, see + `the Adiantum paper `_. + +-The (AES-128-CBC-ESSIV, AES-128-CBC-CTS) pair exists only to support +-systems whose only form of AES acceleration is an off-CPU crypto +-accelerator such as CAAM or CESA that does not support XTS. ++The (AES-128-CBC-ESSIV, AES-128-CBC-CTS) pair was added to try to ++provide a more efficient option for systems that lack AES instructions ++in the CPU but do have a non-inline crypto engine such as CAAM or CESA ++that supports AES-CBC (and not AES-XTS). This is deprecated. It has ++been shown that just doing AES on the CPU is actually faster. ++Moreover, Adiantum is faster still and is recommended on such systems. + + The remaining mode pairs are the "national pride ciphers": + +@@ -1285,22 +1287,13 @@ this by validating all top-level encrypt + Inline encryption support + ========================= + +-By default, fscrypt uses the kernel crypto API for all cryptographic +-operations (other than HKDF, which fscrypt partially implements +-itself). The kernel crypto API supports hardware crypto accelerators, +-but only ones that work in the traditional way where all inputs and +-outputs (e.g. plaintexts and ciphertexts) are in memory. fscrypt can +-take advantage of such hardware, but the traditional acceleration +-model isn't particularly efficient and fscrypt hasn't been optimized +-for it. +- +-Instead, many newer systems (especially mobile SoCs) have *inline +-encryption hardware* that can encrypt/decrypt data while it is on its +-way to/from the storage device. Linux supports inline encryption +-through a set of extensions to the block layer called *blk-crypto*. +-blk-crypto allows filesystems to attach encryption contexts to bios +-(I/O requests) to specify how the data will be encrypted or decrypted +-in-line. For more information about blk-crypto, see ++Many newer systems (especially mobile SoCs) have *inline encryption ++hardware* that can encrypt/decrypt data while it is on its way to/from ++the storage device. Linux supports inline encryption through a set of ++extensions to the block layer called *blk-crypto*. blk-crypto allows ++filesystems to attach encryption contexts to bios (I/O requests) to ++specify how the data will be encrypted or decrypted in-line. For more ++information about blk-crypto, see + :ref:`Documentation/block/inline-encryption.rst `. + + On supported filesystems (currently ext4 and f2fs), fscrypt can use +--- a/fs/crypto/fscrypt_private.h ++++ b/fs/crypto/fscrypt_private.h +@@ -27,6 +27,23 @@ + */ + #define FSCRYPT_MIN_KEY_SIZE 16 + ++/* ++ * This mask is passed as the third argument to the crypto_alloc_*() functions ++ * to prevent fscrypt from using the Crypto API drivers for non-inline crypto ++ * engines. Those drivers have been problematic for fscrypt. fscrypt users ++ * have reported hangs and even incorrect en/decryption with these drivers. ++ * Since going to the driver, off CPU, and back again is really slow, such ++ * drivers can be over 50 times slower than the CPU-based code for fscrypt's ++ * workload. Even on platforms that lack AES instructions on the CPU, using the ++ * offloads has been shown to be slower, even staying with AES. (Of course, ++ * Adiantum is faster still, and is the recommended option on such platforms...) ++ * ++ * Note that fscrypt also supports inline crypto engines. Those don't use the ++ * Crypto API and work much better than the old-style (non-inline) engines. ++ */ ++#define FSCRYPT_CRYPTOAPI_MASK \ ++ (CRYPTO_ALG_ALLOCATES_MEMORY | CRYPTO_ALG_KERN_DRIVER_ONLY) ++ + #define FSCRYPT_CONTEXT_V1 1 + #define FSCRYPT_CONTEXT_V2 2 + +--- a/fs/crypto/hkdf.c ++++ b/fs/crypto/hkdf.c +@@ -56,7 +56,7 @@ int fscrypt_init_hkdf(struct fscrypt_hkd + u8 prk[HKDF_HASHLEN]; + int err; + +- hmac_tfm = crypto_alloc_shash(HKDF_HMAC_ALG, 0, 0); ++ hmac_tfm = crypto_alloc_shash(HKDF_HMAC_ALG, 0, FSCRYPT_CRYPTOAPI_MASK); + if (IS_ERR(hmac_tfm)) { + fscrypt_err(NULL, "Error allocating " HKDF_HMAC_ALG ": %ld", + PTR_ERR(hmac_tfm)); +--- a/fs/crypto/keysetup.c ++++ b/fs/crypto/keysetup.c +@@ -103,7 +103,8 @@ fscrypt_allocate_skcipher(struct fscrypt + struct crypto_skcipher *tfm; + int err; + +- tfm = crypto_alloc_skcipher(mode->cipher_str, 0, 0); ++ tfm = crypto_alloc_skcipher(mode->cipher_str, 0, ++ FSCRYPT_CRYPTOAPI_MASK); + if (IS_ERR(tfm)) { + if (PTR_ERR(tfm) == -ENOENT) { + fscrypt_warn(inode, +--- a/fs/crypto/keysetup_v1.c ++++ b/fs/crypto/keysetup_v1.c +@@ -52,7 +52,8 @@ static int derive_key_aes(const u8 *mast + struct skcipher_request *req = NULL; + DECLARE_CRYPTO_WAIT(wait); + struct scatterlist src_sg, dst_sg; +- struct crypto_skcipher *tfm = crypto_alloc_skcipher("ecb(aes)", 0, 0); ++ struct crypto_skcipher *tfm = ++ crypto_alloc_skcipher("ecb(aes)", 0, FSCRYPT_CRYPTOAPI_MASK); + + if (IS_ERR(tfm)) { + res = PTR_ERR(tfm); diff --git a/queue-6.15/loongarch-avoid-in-place-string-operation-on-fdt-content.patch b/queue-6.15/loongarch-avoid-in-place-string-operation-on-fdt-content.patch new file mode 100644 index 0000000000..058322a26f --- /dev/null +++ b/queue-6.15/loongarch-avoid-in-place-string-operation-on-fdt-content.patch @@ -0,0 +1,60 @@ +From 70a2365e18affc5ebdaab1ca6a0b3c4f3aac2ee8 Mon Sep 17 00:00:00 2001 +From: Yao Zi +Date: Sun, 3 Aug 2025 22:49:47 +0800 +Subject: LoongArch: Avoid in-place string operation on FDT content + +From: Yao Zi + +commit 70a2365e18affc5ebdaab1ca6a0b3c4f3aac2ee8 upstream. + +In init_cpu_fullname(), a constant pointer to "model" property is +retrieved. It's later modified by the strsep() function, which is +illegal and corrupts kernel's FDT copy. This is shown by dmesg, + + OF: fdt: not creating '/sys/firmware/fdt': CRC check failed + +Create a mutable copy of the model property and do in-place operations +on the mutable copy instead. loongson_sysconf.cpuname lives across the +kernel lifetime, thus manually releasing isn't necessary. + +Also move the of_node_put() call for the root node after the usage of +its property, since of_node_put() decreases the reference counter thus +usage after the call is unsafe. + +Cc: stable@vger.kernel.org +Fixes: 44a01f1f726a ("LoongArch: Parsing CPU-related information from DTS") +Reviewed-by: Jiaxun Yang +Signed-off-by: Yao Zi +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kernel/env.c | 13 ++++++++----- + 1 file changed, 8 insertions(+), 5 deletions(-) + +--- a/arch/loongarch/kernel/env.c ++++ b/arch/loongarch/kernel/env.c +@@ -39,16 +39,19 @@ void __init init_environ(void) + + static int __init init_cpu_fullname(void) + { +- struct device_node *root; + int cpu, ret; +- char *model; ++ char *cpuname; ++ const char *model; ++ struct device_node *root; + + /* Parsing cpuname from DTS model property */ + root = of_find_node_by_path("/"); +- ret = of_property_read_string(root, "model", (const char **)&model); ++ ret = of_property_read_string(root, "model", &model); ++ if (ret == 0) { ++ cpuname = kstrdup(model, GFP_KERNEL); ++ loongson_sysconf.cpuname = strsep(&cpuname, " "); ++ } + of_node_put(root); +- if (ret == 0) +- loongson_sysconf.cpuname = strsep(&model, " "); + + if (loongson_sysconf.cpuname && !strncmp(loongson_sysconf.cpuname, "Loongson", 8)) { + for (cpu = 0; cpu < NR_CPUS; cpu++) diff --git a/queue-6.15/loongarch-bpf-fix-jump-offset-calculation-in-tailcall.patch b/queue-6.15/loongarch-bpf-fix-jump-offset-calculation-in-tailcall.patch new file mode 100644 index 0000000000..cfafe766ab --- /dev/null +++ b/queue-6.15/loongarch-bpf-fix-jump-offset-calculation-in-tailcall.patch @@ -0,0 +1,109 @@ +From cd39d9e6b7e4c58fa77783e7aedf7ada51d02ea3 Mon Sep 17 00:00:00 2001 +From: Haoran Jiang +Date: Tue, 5 Aug 2025 19:00:22 +0800 +Subject: LoongArch: BPF: Fix jump offset calculation in tailcall + +From: Haoran Jiang + +commit cd39d9e6b7e4c58fa77783e7aedf7ada51d02ea3 upstream. + +The extra pass of bpf_int_jit_compile() skips JIT context initialization +which essentially skips offset calculation leaving out_offset = -1, so +the jmp_offset in emit_bpf_tail_call is calculated by + +"#define jmp_offset (out_offset - (cur_offset))" + +is a negative number, which is wrong. The final generated assembly are +as follow. + +54: bgeu $a2, $t1, -8 # 0x0000004c +58: addi.d $a6, $s5, -1 +5c: bltz $a6, -16 # 0x0000004c +60: alsl.d $t2, $a2, $a1, 0x3 +64: ld.d $t2, $t2, 264 +68: beq $t2, $zero, -28 # 0x0000004c + +Before apply this patch, the follow test case will reveal soft lock issues. + +cd tools/testing/selftests/bpf/ +./test_progs --allow=tailcalls/tailcall_bpf2bpf_1 + +dmesg: +watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [test_progs:25056] + +Cc: stable@vger.kernel.org +Fixes: 5dc615520c4d ("LoongArch: Add BPF JIT support") +Reviewed-by: Hengqi Chen +Signed-off-by: Haoran Jiang +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/net/bpf_jit.c | 21 +++++---------------- + 1 file changed, 5 insertions(+), 16 deletions(-) + +--- a/arch/loongarch/net/bpf_jit.c ++++ b/arch/loongarch/net/bpf_jit.c +@@ -208,11 +208,9 @@ bool bpf_jit_supports_far_kfunc_call(voi + return true; + } + +-/* initialized on the first pass of build_body() */ +-static int out_offset = -1; +-static int emit_bpf_tail_call(struct jit_ctx *ctx) ++static int emit_bpf_tail_call(struct jit_ctx *ctx, int insn) + { +- int off; ++ int off, tc_ninsn = 0; + u8 tcc = tail_call_reg(ctx); + u8 a1 = LOONGARCH_GPR_A1; + u8 a2 = LOONGARCH_GPR_A2; +@@ -222,7 +220,7 @@ static int emit_bpf_tail_call(struct jit + const int idx0 = ctx->idx; + + #define cur_offset (ctx->idx - idx0) +-#define jmp_offset (out_offset - (cur_offset)) ++#define jmp_offset (tc_ninsn - (cur_offset)) + + /* + * a0: &ctx +@@ -232,6 +230,7 @@ static int emit_bpf_tail_call(struct jit + * if (index >= array->map.max_entries) + * goto out; + */ ++ tc_ninsn = insn ? ctx->offset[insn+1] - ctx->offset[insn] : ctx->offset[0]; + off = offsetof(struct bpf_array, map.max_entries); + emit_insn(ctx, ldwu, t1, a1, off); + /* bgeu $a2, $t1, jmp_offset */ +@@ -263,15 +262,6 @@ static int emit_bpf_tail_call(struct jit + emit_insn(ctx, ldd, t3, t2, off); + __build_epilogue(ctx, true); + +- /* out: */ +- if (out_offset == -1) +- out_offset = cur_offset; +- if (cur_offset != out_offset) { +- pr_err_once("tail_call out_offset = %d, expected %d!\n", +- cur_offset, out_offset); +- return -1; +- } +- + return 0; + + toofar: +@@ -916,7 +906,7 @@ static int build_insn(const struct bpf_i + /* tail call */ + case BPF_JMP | BPF_TAIL_CALL: + mark_tail_call(ctx); +- if (emit_bpf_tail_call(ctx) < 0) ++ if (emit_bpf_tail_call(ctx, i) < 0) + return -EINVAL; + break; + +@@ -1342,7 +1332,6 @@ out: + if (tmp_blinded) + bpf_jit_prog_release_other(prog, prog == orig_prog ? tmp : orig_prog); + +- out_offset = -1; + + return prog; + diff --git a/queue-6.15/loongarch-don-t-use-pk-through-printk-in-unwinder.patch b/queue-6.15/loongarch-don-t-use-pk-through-printk-in-unwinder.patch new file mode 100644 index 0000000000..5b42151c27 --- /dev/null +++ b/queue-6.15/loongarch-don-t-use-pk-through-printk-in-unwinder.patch @@ -0,0 +1,44 @@ +From 2362e8124ed21445c6886806e5deaee717629ddd Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= +Date: Sun, 3 Aug 2025 22:49:47 +0800 +Subject: LoongArch: Don't use %pK through printk() in unwinder +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Thomas Weißschuh + +commit 2362e8124ed21445c6886806e5deaee717629ddd upstream. + +In the past %pK was preferable to %p as it would not leak raw pointer +values into the kernel log. + +Since commit ad67b74d2469 ("printk: hash addresses printed with %p") +the regular %p has been improved to avoid this issue. + +Furthermore, restricted pointers ("%pK") were never meant to be used +through printk(). They can still unintentionally leak raw pointers or +acquire sleeping locks in atomic contexts. + +Switch to the regular pointer formatting which is safer and easier to +reason about. + +Cc: stable@vger.kernel.org +Signed-off-by: Thomas Weißschuh +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kernel/unwind_orc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/loongarch/kernel/unwind_orc.c ++++ b/arch/loongarch/kernel/unwind_orc.c +@@ -507,7 +507,7 @@ bool unwind_next_frame(struct unwind_sta + + state->pc = bt_address(pc); + if (!state->pc) { +- pr_err("cannot find unwind pc at %pK\n", (void *)pc); ++ pr_err("cannot find unwind pc at %p\n", (void *)pc); + goto err; + } + diff --git a/queue-6.15/loongarch-make-relocate_new_kernel_size-be-a-.quad-value.patch b/queue-6.15/loongarch-make-relocate_new_kernel_size-be-a-.quad-value.patch new file mode 100644 index 0000000000..d1d8cd244f --- /dev/null +++ b/queue-6.15/loongarch-make-relocate_new_kernel_size-be-a-.quad-value.patch @@ -0,0 +1,33 @@ +From a1a81b5477196ca1290b367404a461e046e647d5 Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Sun, 3 Aug 2025 22:49:47 +0800 +Subject: LoongArch: Make relocate_new_kernel_size be a .quad value + +From: Huacai Chen + +commit a1a81b5477196ca1290b367404a461e046e647d5 upstream. + +Now relocate_new_kernel_size is a .long value, which means 32bit, so its +high 32bit is undefined. This causes memcpy((void *)reboot_code_buffer, +relocate_new_kernel, relocate_new_kernel_size) in machine_kexec_prepare() +access out of range memories in some cases, and then end up with an ADE +exception. + +So make relocate_new_kernel_size be a .quad value, which means 64bit, to +avoid such errors. + +Cc: stable@vger.kernel.org +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kernel/relocate_kernel.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/loongarch/kernel/relocate_kernel.S ++++ b/arch/loongarch/kernel/relocate_kernel.S +@@ -109,4 +109,4 @@ SYM_CODE_END(kexec_smp_wait) + relocate_new_kernel_end: + + .section ".data" +-SYM_DATA(relocate_new_kernel_size, .long relocate_new_kernel_end - relocate_new_kernel) ++SYM_DATA(relocate_new_kernel_size, .quad relocate_new_kernel_end - relocate_new_kernel) diff --git a/queue-6.15/loongarch-vdso-remove-nostdlib-complier-flag.patch b/queue-6.15/loongarch-vdso-remove-nostdlib-complier-flag.patch new file mode 100644 index 0000000000..24904769ff --- /dev/null +++ b/queue-6.15/loongarch-vdso-remove-nostdlib-complier-flag.patch @@ -0,0 +1,41 @@ +From d35ec48fa6c8fe0cfa4a03155109fec7677911d4 Mon Sep 17 00:00:00 2001 +From: Wentao Guan +Date: Tue, 5 Aug 2025 19:00:22 +0800 +Subject: LoongArch: vDSO: Remove -nostdlib complier flag + +From: Wentao Guan + +commit d35ec48fa6c8fe0cfa4a03155109fec7677911d4 upstream. + +Since $(LD) is directly used, hence -nostdlib is unneeded, MIPS has +removed this, we should remove it too. + +bdbf2038fbf4 ("MIPS: VDSO: remove -nostdlib compiler flag"). + +In fact, other architectures also use $(LD) now. + +fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO") +691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO") +2ff906994b6c ("MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO") +2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO") + +Cc: stable@vger.kernel.org +Reviewed-by: Yanteng Si +Signed-off-by: Wentao Guan +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/vdso/Makefile | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/loongarch/vdso/Makefile ++++ b/arch/loongarch/vdso/Makefile +@@ -36,7 +36,7 @@ endif + + # VDSO linker flags. + ldflags-y := -Bsymbolic --no-undefined -soname=linux-vdso.so.1 \ +- $(filter -E%,$(KBUILD_CFLAGS)) -nostdlib -shared --build-id -T ++ $(filter -E%,$(KBUILD_CFLAGS)) -shared --build-id -T + + # + # Shared build commands. diff --git a/queue-6.15/nfs-fix-the-setting-of-capabilities-when-automounting-a-new-filesystem.patch b/queue-6.15/nfs-fix-the-setting-of-capabilities-when-automounting-a-new-filesystem.patch new file mode 100644 index 0000000000..0c1995de46 --- /dev/null +++ b/queue-6.15/nfs-fix-the-setting-of-capabilities-when-automounting-a-new-filesystem.patch @@ -0,0 +1,164 @@ +From b01f21cacde9f2878492cf318fee61bf4ccad323 Mon Sep 17 00:00:00 2001 +From: Trond Myklebust +Date: Sun, 3 Aug 2025 14:31:59 -0700 +Subject: NFS: Fix the setting of capabilities when automounting a new filesystem + +From: Trond Myklebust + +commit b01f21cacde9f2878492cf318fee61bf4ccad323 upstream. + +Capabilities cannot be inherited when we cross into a new filesystem. +They need to be reset to the minimal defaults, and then probed for +again. + +Fixes: 54ceac451598 ("NFS: Share NFS superblocks per-protocol per-server per-FSID") +Cc: stable@vger.kernel.org +Reviewed-by: Benjamin Coddington +Signed-off-by: Trond Myklebust +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfs/client.c | 44 ++++++++++++++++++++++++++++++++++++++++++-- + fs/nfs/internal.h | 2 +- + fs/nfs/nfs4client.c | 20 +------------------- + fs/nfs/nfs4proc.c | 2 +- + 4 files changed, 45 insertions(+), 23 deletions(-) + +--- a/fs/nfs/client.c ++++ b/fs/nfs/client.c +@@ -682,6 +682,44 @@ struct nfs_client *nfs_init_client(struc + } + EXPORT_SYMBOL_GPL(nfs_init_client); + ++static void nfs4_server_set_init_caps(struct nfs_server *server) ++{ ++#if IS_ENABLED(CONFIG_NFS_V4) ++ /* Set the basic capabilities */ ++ server->caps = server->nfs_client->cl_mvops->init_caps; ++ if (server->flags & NFS_MOUNT_NORDIRPLUS) ++ server->caps &= ~NFS_CAP_READDIRPLUS; ++ if (server->nfs_client->cl_proto == XPRT_TRANSPORT_RDMA) ++ server->caps &= ~NFS_CAP_READ_PLUS; ++ ++ /* ++ * Don't use NFS uid/gid mapping if we're using AUTH_SYS or lower ++ * authentication. ++ */ ++ if (nfs4_disable_idmapping && ++ server->client->cl_auth->au_flavor == RPC_AUTH_UNIX) ++ server->caps |= NFS_CAP_UIDGID_NOMAP; ++#endif ++} ++ ++void nfs_server_set_init_caps(struct nfs_server *server) ++{ ++ switch (server->nfs_client->rpc_ops->version) { ++ case 2: ++ server->caps = NFS_CAP_HARDLINKS | NFS_CAP_SYMLINKS; ++ break; ++ case 3: ++ server->caps = NFS_CAP_HARDLINKS | NFS_CAP_SYMLINKS; ++ if (!(server->flags & NFS_MOUNT_NORDIRPLUS)) ++ server->caps |= NFS_CAP_READDIRPLUS; ++ break; ++ default: ++ nfs4_server_set_init_caps(server); ++ break; ++ } ++} ++EXPORT_SYMBOL_GPL(nfs_server_set_init_caps); ++ + /* + * Create a version 2 or 3 client + */ +@@ -726,7 +764,6 @@ static int nfs_init_server(struct nfs_se + /* Initialise the client representation from the mount data */ + server->flags = ctx->flags; + server->options = ctx->options; +- server->caps |= NFS_CAP_HARDLINKS | NFS_CAP_SYMLINKS; + + switch (clp->rpc_ops->version) { + case 2: +@@ -762,6 +799,8 @@ static int nfs_init_server(struct nfs_se + if (error < 0) + goto error; + ++ nfs_server_set_init_caps(server); ++ + /* Preserve the values of mount_server-related mount options */ + if (ctx->mount_server.addrlen) { + memcpy(&server->mountd_address, &ctx->mount_server.address, +@@ -936,7 +975,6 @@ void nfs_server_copy_userdata(struct nfs + target->acregmax = source->acregmax; + target->acdirmin = source->acdirmin; + target->acdirmax = source->acdirmax; +- target->caps = source->caps; + target->options = source->options; + target->auth_info = source->auth_info; + target->port = source->port; +@@ -1170,6 +1208,8 @@ struct nfs_server *nfs_clone_server(stru + if (error < 0) + goto out_free_server; + ++ nfs_server_set_init_caps(server); ++ + /* probe the filesystem info for this server filesystem */ + error = nfs_probe_server(server, fh); + if (error < 0) +--- a/fs/nfs/internal.h ++++ b/fs/nfs/internal.h +@@ -232,7 +232,7 @@ extern struct nfs_client * + nfs4_find_client_sessionid(struct net *, const struct sockaddr *, + struct nfs4_sessionid *, u32); + extern struct nfs_server *nfs_create_server(struct fs_context *); +-extern void nfs4_server_set_init_caps(struct nfs_server *); ++extern void nfs_server_set_init_caps(struct nfs_server *); + extern struct nfs_server *nfs4_create_server(struct fs_context *); + extern struct nfs_server *nfs4_create_referral_server(struct fs_context *); + extern int nfs4_update_server(struct nfs_server *server, const char *hostname, +--- a/fs/nfs/nfs4client.c ++++ b/fs/nfs/nfs4client.c +@@ -1088,24 +1088,6 @@ static void nfs4_session_limit_xasize(st + #endif + } + +-void nfs4_server_set_init_caps(struct nfs_server *server) +-{ +- /* Set the basic capabilities */ +- server->caps |= server->nfs_client->cl_mvops->init_caps; +- if (server->flags & NFS_MOUNT_NORDIRPLUS) +- server->caps &= ~NFS_CAP_READDIRPLUS; +- if (server->nfs_client->cl_proto == XPRT_TRANSPORT_RDMA) +- server->caps &= ~NFS_CAP_READ_PLUS; +- +- /* +- * Don't use NFS uid/gid mapping if we're using AUTH_SYS or lower +- * authentication. +- */ +- if (nfs4_disable_idmapping && +- server->client->cl_auth->au_flavor == RPC_AUTH_UNIX) +- server->caps |= NFS_CAP_UIDGID_NOMAP; +-} +- + static int nfs4_server_common_setup(struct nfs_server *server, + struct nfs_fh *mntfh, bool auth_probe) + { +@@ -1120,7 +1102,7 @@ static int nfs4_server_common_setup(stru + if (error < 0) + goto out; + +- nfs4_server_set_init_caps(server); ++ nfs_server_set_init_caps(server); + + /* Probe the root fh to retrieve its FSID and filehandle */ + error = nfs4_get_rootfh(server, mntfh, auth_probe); +--- a/fs/nfs/nfs4proc.c ++++ b/fs/nfs/nfs4proc.c +@@ -4083,7 +4083,7 @@ int nfs4_server_capabilities(struct nfs_ + }; + int err; + +- nfs4_server_set_init_caps(server); ++ nfs_server_set_init_caps(server); + do { + err = nfs4_handle_exception(server, + _nfs4_server_capabilities(server, fhandle), diff --git a/queue-6.15/nfsd-detect-mismatch-of-file-handle-and-delegation-stateid-in-open-op.patch b/queue-6.15/nfsd-detect-mismatch-of-file-handle-and-delegation-stateid-in-open-op.patch new file mode 100644 index 0000000000..08c81c7d84 --- /dev/null +++ b/queue-6.15/nfsd-detect-mismatch-of-file-handle-and-delegation-stateid-in-open-op.patch @@ -0,0 +1,54 @@ +From 9c65001c57164033ad08b654c8b5ae35512ddf4a Mon Sep 17 00:00:00 2001 +From: Dai Ngo +Date: Tue, 10 Jun 2025 08:35:28 -0700 +Subject: NFSD: detect mismatch of file handle and delegation stateid in OPEN op + +From: Dai Ngo + +commit 9c65001c57164033ad08b654c8b5ae35512ddf4a upstream. + +When the client sends an OPEN with claim type CLAIM_DELEG_CUR_FH or +CLAIM_DELEGATION_CUR, the delegation stateid and the file handle +must belong to the same file, otherwise return NFS4ERR_INVAL. + +Note that RFC8881, section 8.2.4, mandates the server to return +NFS4ERR_BAD_STATEID if the selected table entry does not match the +current filehandle. However returning NFS4ERR_BAD_STATEID in the +OPEN causes the client to retry the operation and therefor get the +client into a loop. To avoid this situation we return NFS4ERR_INVAL +instead. + +Reported-by: Petro Pavlov +Fixes: c44c5eeb2c02 ("[PATCH] nfsd4: add open state code for CLAIM_DELEGATE_CUR") +Cc: stable@vger.kernel.org +Signed-off-by: Dai Ngo +Reviewed-by: Jeff Layton +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + fs/nfsd/nfs4state.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -6328,6 +6328,20 @@ nfsd4_process_open2(struct svc_rqst *rqs + status = nfs4_check_deleg(cl, open, &dp); + if (status) + goto out; ++ if (dp && nfsd4_is_deleg_cur(open) && ++ (dp->dl_stid.sc_file != fp)) { ++ /* ++ * RFC8881 section 8.2.4 mandates the server to return ++ * NFS4ERR_BAD_STATEID if the selected table entry does ++ * not match the current filehandle. However returning ++ * NFS4ERR_BAD_STATEID in the OPEN can cause the client ++ * to repeatedly retry the operation with the same ++ * stateid, since the stateid itself is valid. To avoid ++ * this situation NFSD returns NFS4ERR_INVAL instead. ++ */ ++ status = nfserr_inval; ++ goto out; ++ } + stp = nfsd4_find_and_lock_existing_open(fp, open); + } else { + open->op_file = NULL; diff --git a/queue-6.15/nfsd-handle-get_client_locked-failure-in-nfsd4_setclientid_confirm.patch b/queue-6.15/nfsd-handle-get_client_locked-failure-in-nfsd4_setclientid_confirm.patch new file mode 100644 index 0000000000..de5494323c --- /dev/null +++ b/queue-6.15/nfsd-handle-get_client_locked-failure-in-nfsd4_setclientid_confirm.patch @@ -0,0 +1,71 @@ +From 908e4ead7f757504d8b345452730636e298cbf68 Mon Sep 17 00:00:00 2001 +From: Jeff Layton +Date: Wed, 4 Jun 2025 12:01:10 -0400 +Subject: nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm() + +From: Jeff Layton + +commit 908e4ead7f757504d8b345452730636e298cbf68 upstream. + +Lei Lu recently reported that nfsd4_setclientid_confirm() did not check +the return value from get_client_locked(). a SETCLIENTID_CONFIRM could +race with a confirmed client expiring and fail to get a reference. That +could later lead to a UAF. + +Fix this by getting a reference early in the case where there is an +extant confirmed client. If that fails then treat it as if there were no +confirmed client found at all. + +In the case where the unconfirmed client is expiring, just fail and +return the result from get_client_locked(). + +Reported-by: lei lu +Closes: https://lore.kernel.org/linux-nfs/CAEBF3_b=UvqzNKdnfD_52L05Mqrqui9vZ2eFamgAbV0WG+FNWQ@mail.gmail.com/ +Fixes: d20c11d86d8f ("nfsd: Protect session creation and client confirm using client_lock") +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 | 20 +++++++++++++++----- + 1 file changed, 15 insertions(+), 5 deletions(-) + +--- a/fs/nfsd/nfs4state.c ++++ b/fs/nfsd/nfs4state.c +@@ -4693,10 +4693,16 @@ nfsd4_setclientid_confirm(struct svc_rqs + } + status = nfs_ok; + if (conf) { +- old = unconf; +- unhash_client_locked(old); +- nfsd4_change_callback(conf, &unconf->cl_cb_conn); +- } else { ++ if (get_client_locked(conf) == nfs_ok) { ++ old = unconf; ++ unhash_client_locked(old); ++ nfsd4_change_callback(conf, &unconf->cl_cb_conn); ++ } else { ++ conf = NULL; ++ } ++ } ++ ++ if (!conf) { + old = find_confirmed_client_by_name(&unconf->cl_name, nn); + if (old) { + status = nfserr_clid_inuse; +@@ -4713,10 +4719,14 @@ nfsd4_setclientid_confirm(struct svc_rqs + } + trace_nfsd_clid_replaced(&old->cl_clientid); + } ++ status = get_client_locked(unconf); ++ if (status != nfs_ok) { ++ old = NULL; ++ goto out; ++ } + move_to_confirmed(unconf); + conf = unconf; + } +- get_client_locked(conf); + spin_unlock(&nn->client_lock); + if (conf == unconf) + fsnotify_dentry(conf->cl_nfsd_info_dentry, FS_MODIFY); diff --git a/queue-6.15/pci-extend-isolated-function-probing-to-loongarch.patch b/queue-6.15/pci-extend-isolated-function-probing-to-loongarch.patch new file mode 100644 index 0000000000..c175f4f2d2 --- /dev/null +++ b/queue-6.15/pci-extend-isolated-function-probing-to-loongarch.patch @@ -0,0 +1,41 @@ +From a02fd05661d73a8507dd70dd820e9b984490c545 Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Tue, 24 Jun 2025 14:29:27 +0800 +Subject: PCI: Extend isolated function probing to LoongArch + +From: Huacai Chen + +commit a02fd05661d73a8507dd70dd820e9b984490c545 upstream. + +Like s390 and the jailhouse hypervisor, LoongArch's PCI architecture allows +passing isolated PCI functions to a guest OS instance. So it is possible +that there is a multi-function device without function 0 for the host or +guest. + +Allow probing such functions by adding a IS_ENABLED(CONFIG_LOONGARCH) case +in the hypervisor_isolated_pci_functions() helper. + +This is similar to commit 189c6c33ff42 ("PCI: Extend isolated function +probing to s390"). + +Signed-off-by: Huacai Chen +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20250624062927.4037734-1-chenhuacai@loongson.cn +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/hypervisor.h | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/include/linux/hypervisor.h ++++ b/include/linux/hypervisor.h +@@ -37,6 +37,9 @@ static inline bool hypervisor_isolated_p + if (IS_ENABLED(CONFIG_S390)) + return true; + ++ if (IS_ENABLED(CONFIG_LOONGARCH)) ++ return true; ++ + return jailhouse_paravirt(); + } + diff --git a/queue-6.15/series b/queue-6.15/series index d5b071072b..1541569118 100644 --- a/queue-6.15/series +++ b/queue-6.15/series @@ -27,3 +27,18 @@ net-dpaa-fix-device-leak-when-querying-time-stamp-info.patch net-usb-asix_devices-add-phy_mask-for-ax88772-mdio-bus.patch net-usb-qmi_wwan-add-telit-cinterion-fn990a-w-audio-composition.patch fhandle-raise-fileid_is_dir-in-handle_type.patch +nfsd-handle-get_client_locked-failure-in-nfsd4_setclientid_confirm.patch +nfsd-detect-mismatch-of-file-handle-and-delegation-stateid-in-open-op.patch +nfs-fix-the-setting-of-capabilities-when-automounting-a-new-filesystem.patch +pci-extend-isolated-function-probing-to-loongarch.patch +loongarch-bpf-fix-jump-offset-calculation-in-tailcall.patch +loongarch-don-t-use-pk-through-printk-in-unwinder.patch +loongarch-make-relocate_new_kernel_size-be-a-.quad-value.patch +loongarch-avoid-in-place-string-operation-on-fdt-content.patch +loongarch-vdso-remove-nostdlib-complier-flag.patch +sunvdc-balance-device-refcount-in-vdc_port_mpgroup_check.patch +clk-samsung-exynos850-fix-a-comment.patch +clk-samsung-gs101-fix-clk_dout_cmu_g3d_busd.patch +clk-samsung-gs101-fix-alternate-mout_hsi0_usb20_ref-parent-clock.patch +fscrypt-don-t-use-problematic-non-inline-crypto-engines.patch +fs-prevent-file-descriptor-table-allocations-exceeding-int_max.patch diff --git a/queue-6.15/sunvdc-balance-device-refcount-in-vdc_port_mpgroup_check.patch b/queue-6.15/sunvdc-balance-device-refcount-in-vdc_port_mpgroup_check.patch new file mode 100644 index 0000000000..e392b6c140 --- /dev/null +++ b/queue-6.15/sunvdc-balance-device-refcount-in-vdc_port_mpgroup_check.patch @@ -0,0 +1,48 @@ +From 63ce53724637e2e7ba51fe3a4f78351715049905 Mon Sep 17 00:00:00 2001 +From: Ma Ke +Date: Sat, 19 Jul 2025 15:58:56 +0800 +Subject: sunvdc: Balance device refcount in vdc_port_mpgroup_check +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ma Ke + +commit 63ce53724637e2e7ba51fe3a4f78351715049905 upstream. + +Using device_find_child() to locate a probed virtual-device-port node +causes a device refcount imbalance, as device_find_child() internally +calls get_device() to increment the device’s reference count before +returning its pointer. vdc_port_mpgroup_check() directly returns true +upon finding a matching device without releasing the reference via +put_device(). We should call put_device() to decrement refcount. + +As comment of device_find_child() says, 'NOTE: you will need to drop +the reference with put_device() after use'. + +Found by code review. + +Cc: stable@vger.kernel.org +Fixes: 3ee70591d6c4 ("sunvdc: prevent sunvdc panic when mpgroup disk added to guest domain") +Signed-off-by: Ma Ke +Link: https://lore.kernel.org/r/20250719075856.3447953-1-make24@iscas.ac.cn +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/block/sunvdc.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/block/sunvdc.c ++++ b/drivers/block/sunvdc.c +@@ -957,8 +957,10 @@ static bool vdc_port_mpgroup_check(struc + dev = device_find_child(vdev->dev.parent, &port_data, + vdc_device_probed); + +- if (dev) ++ if (dev) { ++ put_device(dev); + return true; ++ } + + return false; + } -- 2.47.3