--- /dev/null
+From 320e7efce30e2613c2c7877acc46a8e71192cdcd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <andre.draszik@linaro.org>
+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 <andre.draszik@linaro.org>
+
+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 <andre.draszik@linaro.org>
+Link: https://lore.kernel.org/r/20250603-samsung-clk-fixes-v1-3-49daf1ff4592@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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" };
--- /dev/null
+From ca243e653f71d8c4724a68c9033923f945b1084d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <andre.draszik@linaro.org>
+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 <andre.draszik@linaro.org>
+
+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 <andre.draszik@linaro.org>
+Link: https://lore.kernel.org/r/20250603-samsung-clk-fixes-v1-2-49daf1ff4592@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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",
--- /dev/null
+From 29a9361f0b50be2b16d308695e30ee030fedea2c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <andre.draszik@linaro.org>
+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 <andre.draszik@linaro.org>
+
+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 <andre.draszik@linaro.org>
+Link: https://lore.kernel.org/r/20250603-samsung-clk-fixes-v1-1-49daf1ff4592@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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),
--- /dev/null
+From 04a2c4b4511d186b0fce685da21085a5d4acd370 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 29 Jun 2025 03:40:21 -0400
+Subject: fs: Prevent file descriptor table allocations exceeding INT_MAX
+
+From: Sasha Levin <sashal@kernel.org>
+
+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 <unistd.h>
+ #include <sys/resource.h>
+
+ 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 <sashal@kernel.org>
+Link: https://lore.kernel.org/20250629074021.1038845-1-sashal@kernel.org
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From b41c1d8d07906786c60893980d52688f31d114a6 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@kernel.org>
+Date: Fri, 4 Jul 2025 00:03:22 -0700
+Subject: fscrypt: Don't use problematic non-inline crypto engines
+
+From: Eric Biggers <ebiggers@kernel.org>
+
+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 <ardb@kernel.org>
+Link: https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org
+Signed-off-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <https://eprint.iacr.org/2018/720.pdf>`_.
+
+-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 <inline_encryption>`.
+
+ 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);
--- /dev/null
+From 70a2365e18affc5ebdaab1ca6a0b3c4f3aac2ee8 Mon Sep 17 00:00:00 2001
+From: Yao Zi <ziyao@disroot.org>
+Date: Sun, 3 Aug 2025 22:49:47 +0800
+Subject: LoongArch: Avoid in-place string operation on FDT content
+
+From: Yao Zi <ziyao@disroot.org>
+
+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 <jiaxun.yang@flygoat.com>
+Signed-off-by: Yao Zi <ziyao@disroot.org>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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++)
--- /dev/null
+From cd39d9e6b7e4c58fa77783e7aedf7ada51d02ea3 Mon Sep 17 00:00:00 2001
+From: Haoran Jiang <jianghaoran@kylinos.cn>
+Date: Tue, 5 Aug 2025 19:00:22 +0800
+Subject: LoongArch: BPF: Fix jump offset calculation in tailcall
+
+From: Haoran Jiang <jianghaoran@kylinos.cn>
+
+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 <hengqi.chen@gmail.com>
+Signed-off-by: Haoran Jiang <jianghaoran@kylinos.cn>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/loongarch/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;
+
--- /dev/null
+From 2362e8124ed21445c6886806e5deaee717629ddd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= <thomas.weissschuh@linutronix.de>
+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 <thomas.weissschuh@linutronix.de>
+
+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 <thomas.weissschuh@linutronix.de>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From a1a81b5477196ca1290b367404a461e046e647d5 Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Sun, 3 Aug 2025 22:49:47 +0800
+Subject: LoongArch: Make relocate_new_kernel_size be a .quad value
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+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 <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From d35ec48fa6c8fe0cfa4a03155109fec7677911d4 Mon Sep 17 00:00:00 2001
+From: Wentao Guan <guanwentao@uniontech.com>
+Date: Tue, 5 Aug 2025 19:00:22 +0800
+Subject: LoongArch: vDSO: Remove -nostdlib complier flag
+
+From: Wentao Guan <guanwentao@uniontech.com>
+
+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 <siyanteng@cqsoftware.com.cn>
+Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
+Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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.
--- /dev/null
+From b01f21cacde9f2878492cf318fee61bf4ccad323 Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+Date: Sun, 3 Aug 2025 14:31:59 -0700
+Subject: NFS: Fix the setting of capabilities when automounting a new filesystem
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+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 <bcodding@redhat.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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),
--- /dev/null
+From 9c65001c57164033ad08b654c8b5ae35512ddf4a Mon Sep 17 00:00:00 2001
+From: Dai Ngo <dai.ngo@oracle.com>
+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 <dai.ngo@oracle.com>
+
+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 <petro.pavlov@vastdata.com>
+Fixes: c44c5eeb2c02 ("[PATCH] nfsd4: add open state code for CLAIM_DELEGATE_CUR")
+Cc: stable@vger.kernel.org
+Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 908e4ead7f757504d8b345452730636e298cbf68 Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@kernel.org>
+Date: Wed, 4 Jun 2025 12:01:10 -0400
+Subject: nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()
+
+From: Jeff Layton <jlayton@kernel.org>
+
+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 <llfamsec@gmail.com>
+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 <jlayton@kernel.org>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From a02fd05661d73a8507dd70dd820e9b984490c545 Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Tue, 24 Jun 2025 14:29:27 +0800
+Subject: PCI: Extend isolated function probing to LoongArch
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+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 <chenhuacai@loongson.cn>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20250624062927.4037734-1-chenhuacai@loongson.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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();
+ }
+
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
--- /dev/null
+From 63ce53724637e2e7ba51fe3a4f78351715049905 Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+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 <make24@iscas.ac.cn>
+
+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 <make24@iscas.ac.cn>
+Link: https://lore.kernel.org/r/20250719075856.3447953-1-make24@iscas.ac.cn
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
