--- /dev/null
+From 1b1937eb08f51319bf71575484cde2b8c517aedc Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Tue, 2 Jun 2026 13:34:46 +0930
+Subject: btrfs: do not trim a device which is not writeable
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit 1b1937eb08f51319bf71575484cde2b8c517aedc upstream.
+
+[BUG]
+There is a bug report that btrfs/242 can randomly fail with the
+following NULL pointer dereference:
+
+ run fstests btrfs/242 at 2026-06-01 10:25:08
+ BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609)
+ BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874
+ BTRFS info (device sdc): using crc32c checksum algorithm
+ BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing
+ BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing
+ BTRFS info (device sdc): allowing degraded mounts
+ BTRFS info (device sdc): turning on async discard
+ BTRFS info (device sdc): enabling free space tree
+ Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
+ user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000
+ CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd
+ Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025
+ pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
+ pc : btrfs_trim_fs+0x34c/0xa00 [btrfs]
+ lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs]
+ Call trace:
+ btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P)
+ btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840]
+ btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840]
+ __arm64_sys_ioctl+0xac/0x108
+ invoke_syscall.constprop.0+0x5c/0xd0
+ el0_svc_common.constprop.0+0x40/0xf0
+ do_el0_svc+0x24/0x40
+ el0_svc+0x40/0x1d0
+ el0t_64_sync_handler+0xa0/0xe8
+ el0t_64_sync+0x1b0/0x1b8
+ Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00)
+ ---[ end trace 0000000000000000 ]---
+
+Also the reporter is very kind to test the following ASSERT() added to
+btrfs_trim_free_extents_throttle():
+
+ ASSERT(device->bdev,
+ "devid=%llu path=%s dev_state=0x%lx\n",
+ device->devid, btrfs_dev_name(device), device->dev_state);
+
+And it shows the following output:
+
+ assertion failed: device->bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82)
+
+Which means the device->bdev is NULL, and the dev_state is
+BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without
+BTRFS_DEV_STATE_WRITEABLE flag set.
+
+[CAUSE]
+The pc points to the following call chain:
+
+ btrfs_trim_fs()
+ |- btrfs_trim_free_extents()
+ |- btrfs_trim_free_extents_throttle()
+ |- bdev_max_discard_sectors(device->bdev)
+
+So the NULL pointer dereference is caused by device->bdev being NULL.
+
+This looks impossible by a quick glance, as just before calling
+btrfs_trim_free_extents_throttle(), we have skipped any device that has
+BTRFS_DEV_STATE_MISSING flag set.
+
+However in this particular case, there is a window where the missing
+device is later re-scanned, causing btrfs to remove the
+BTRFS_DEV_STATE_MISSING flag:
+
+ btrfs_control_ioctl()
+ |- btrfs_scan_one_device()
+ |- device_list_add()
+ |- rcu_assign_pointer(device->name, name);
+ | This updates the missing device's path to the new good path.
+ |
+ |- clear_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state)
+ This removes the BTRFS_DEV_STATE_MISSING flag.
+
+This allows the missing device to re-appear and clear the
+BTRFS_DEV_STATE_MISSING flag. However the device still does not have
+the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated.
+
+The bdev pointer remains NULL, triggering the crash later.
+
+[FIX]
+This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and
+device->bdev pointer, and shows a gap in btrfs's re-appearing-device
+handling.
+
+The proper handling of re-appearing device will need quite some extra
+work, which is out of the context of this small fix.
+
+Thankfully the regular bbio submission path has already handled it well
+by checking if the device->bdev is NULL before submitting.
+
+So here we just fix the crash by checking if the device is writeable and
+has a bdev pointer before calling bdev_max_discard_sectors().
+
+Reported-by: Su Yue <glass.su@suse.com>
+Link: https://lore.kernel.org/linux-btrfs/wlwir19t.fsf@damenly.org/
+Fixes: 499f377f49f0 ("btrfs: iterate over unused chunk space in FITRIM")
+CC: stable@vger.kernel.org # 5.10+
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/extent-tree.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/fs/btrfs/extent-tree.c
++++ b/fs/btrfs/extent-tree.c
+@@ -6405,12 +6405,16 @@ static int btrfs_trim_free_extents(struc
+
+ *trimmed = 0;
+
+- /* Discard not supported = nothing to do. */
+- if (!bdev_max_discard_sectors(device->bdev))
++ /*
++ * The caller only filters out MISSING devices, but a device that was
++ * missing at mount and later rescanned has MISSING cleared while bdev
++ * is still NULL and WRITEABLE is still unset. Skip those here.
++ */
++ if (!test_bit(BTRFS_DEV_STATE_WRITEABLE, &device->dev_state) || !device->bdev)
+ return 0;
+
+- /* Not writable = nothing to do. */
+- if (!test_bit(BTRFS_DEV_STATE_WRITEABLE, &device->dev_state))
++ /* Discard not supported = nothing to do. */
++ if (!bdev_max_discard_sectors(device->bdev))
+ return 0;
+
+ /* No free space = nothing to do. */
--- /dev/null
+From ffdd2bc378953b525aca61902534e753f1f8e734 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@kernel.org>
+Date: Mon, 4 May 2026 15:53:28 -0700
+Subject: crypto: af_alg - Remove zero-copy support from skcipher and aead
+
+From: Eric Biggers <ebiggers@kernel.org>
+
+commit ffdd2bc378953b525aca61902534e753f1f8e734 upstream.
+
+The zero-copy support is one of the riskiest aspects of AF_ALG. It
+allows userspace to request cryptographic operations directly on
+pagecache pages of files like the 'su' binary. It also allows userspace
+to concurrently modify the memory which is being operated on, a recipe
+for TOCTOU vulnerabilities.
+
+While zero-copy support is more valuable in other areas of the kernel
+like the frequently used networking and file I/O code, it has far less
+value in AF_ALG, which is a niche UAPI. AF_ALG primarily just exists
+for backwards compatibility with a small set of userspace programs such
+as 'iwd' that haven't yet been fixed to use userspace crypto code.
+
+Originally AF_ALG was intended to be used to access hardware crypto
+accelerators. However, it isn't an efficient interface for that anyway,
+and it turned out to be rarely used in this way in practice.
+
+Thus, the risks of the zero-copy support in AF_ALG vastly outweigh its
+benefits. Let's just remove it.
+
+This commit removes it from the "skcipher" and "aead" algorithm types.
+"hash" will be handled separately.
+
+This is a soft break, not a hard break. Even after this commit, it
+still works to use splice() or sendfile() to transfer data to an AF_ALG
+request socket from a pipe or any file, respectively. What changes is
+just that the kernel now makes an internal, stable copy of the data
+before doing the crypto operation. So performance is slightly reduced,
+but the UAPI isn't broken. And, very importantly, it's much safer.
+
+Tested with libkcapi/test.sh. All its test cases still pass. I also
+verified that this would have prevented the copy.fail exploit as well.
+I also used a custom test program to verify that sendfile() still works.
+
+Fixes: 8ff590903d5f ("crypto: algif_skcipher - User-space interface for skcipher operations")
+Fixes: 400c40cf78da ("crypto: algif - add AEAD support")
+Reported-by: Taeyang Lee <0wn@theori.io>
+Link: https://copy.fail/
+Reported-by: Feng Ning <feng@innora.ai>
+Closes: https://lore.kernel.org/r/afYcc-tZFwvZZo76@ans-MacBook-Pro.local
+Reviewed-by: Demi Marie Obenour <demiobenour@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/crypto/userspace-if.rst | 31 +-------------
+ crypto/af_alg.c | 71 +++++++++++-----------------------
+ crypto/algif_aead.c | 8 +--
+ 3 files changed, 32 insertions(+), 78 deletions(-)
+
+--- a/Documentation/crypto/userspace-if.rst
++++ b/Documentation/crypto/userspace-if.rst
+@@ -328,33 +328,10 @@ CRYPTO_USER_API_RNG_CAVP option:
+ Zero-Copy Interface
+ -------------------
+
+-In addition to the send/write/read/recv system call family, the AF_ALG
+-interface can be accessed with the zero-copy interface of
+-splice/vmsplice. As the name indicates, the kernel tries to avoid a copy
+-operation into kernel space.
+-
+-The zero-copy operation requires data to be aligned at the page
+-boundary. Non-aligned data can be used as well, but may require more
+-operations of the kernel which would defeat the speed gains obtained
+-from the zero-copy interface.
+-
+-The system-inherent limit for the size of one zero-copy operation is 16
+-pages. If more data is to be sent to AF_ALG, user space must slice the
+-input into segments with a maximum size of 16 pages.
+-
+-Zero-copy can be used with the following code example (a complete
+-working example is provided with libkcapi):
+-
+-::
+-
+- int pipes[2];
+-
+- pipe(pipes);
+- /* input data in iov */
+- vmsplice(pipes[1], iov, iovlen, SPLICE_F_GIFT);
+- /* opfd is the file descriptor returned from accept() system call */
+- splice(pipes[0], NULL, opfd, NULL, ret, 0);
+- read(opfd, out, outlen);
++AF_ALG used to have zero-copy support, but it was removed due to it being a
++frequent source of vulnerabilities. For backwards compatibility the splice()
++and sendfile() system calls are still supported, but the kernel will make an
++internal copy of the data before passing it to the crypto code.
+
+
+ Setsockopt Interface
+--- a/crypto/af_alg.c
++++ b/crypto/af_alg.c
+@@ -977,7 +977,7 @@ int af_alg_sendmsg(struct socket *sock,
+ ssize_t plen;
+
+ /* use the existing memory in an allocated page */
+- if (ctx->merge && !(msg->msg_flags & MSG_SPLICE_PAGES)) {
++ if (ctx->merge) {
+ sgl = list_entry(ctx->tsgl_list.prev,
+ struct af_alg_tsgl, list);
+ sg = sgl->sg + sgl->cur - 1;
+@@ -1021,60 +1021,37 @@ int af_alg_sendmsg(struct socket *sock,
+ if (sgl->cur)
+ sg_unmark_end(sg + sgl->cur - 1);
+
+- if (msg->msg_flags & MSG_SPLICE_PAGES) {
+- struct sg_table sgtable = {
+- .sgl = sg,
+- .nents = sgl->cur,
+- .orig_nents = sgl->cur,
+- };
+-
+- plen = extract_iter_to_sg(&msg->msg_iter, len, &sgtable,
+- MAX_SGL_ENTS - sgl->cur, 0);
+- if (plen < 0) {
+- err = plen;
++ do {
++ struct page *pg;
++ unsigned int i = sgl->cur;
++
++ plen = min_t(size_t, len, PAGE_SIZE);
++
++ pg = alloc_page(GFP_KERNEL);
++ if (!pg) {
++ err = -ENOMEM;
+ goto unlock;
+ }
+
+- for (; sgl->cur < sgtable.nents; sgl->cur++)
+- get_page(sg_page(&sg[sgl->cur]));
++ sg_assign_page(sg + i, pg);
++
++ err = memcpy_from_msg(page_address(sg_page(sg + i)),
++ msg, plen);
++ if (err) {
++ __free_page(sg_page(sg + i));
++ sg_assign_page(sg + i, NULL);
++ goto unlock;
++ }
++
++ sg[i].length = plen;
+ len -= plen;
+ ctx->used += plen;
+ copied += plen;
+ size -= plen;
+- } else {
+- do {
+- struct page *pg;
+- unsigned int i = sgl->cur;
+-
+- plen = min_t(size_t, len, PAGE_SIZE);
+-
+- pg = alloc_page(GFP_KERNEL);
+- if (!pg) {
+- err = -ENOMEM;
+- goto unlock;
+- }
+-
+- sg_assign_page(sg + i, pg);
+-
+- err = memcpy_from_msg(
+- page_address(sg_page(sg + i)),
+- msg, plen);
+- if (err) {
+- __free_page(sg_page(sg + i));
+- sg_assign_page(sg + i, NULL);
+- goto unlock;
+- }
+-
+- sg[i].length = plen;
+- len -= plen;
+- ctx->used += plen;
+- copied += plen;
+- size -= plen;
+- sgl->cur++;
+- } while (len && sgl->cur < MAX_SGL_ENTS);
++ sgl->cur++;
++ } while (len && sgl->cur < MAX_SGL_ENTS);
+
+- ctx->merge = plen & (PAGE_SIZE - 1);
+- }
++ ctx->merge = plen & (PAGE_SIZE - 1);
+
+ if (!size)
+ sg_mark_end(sg + sgl->cur - 1);
+--- a/crypto/algif_aead.c
++++ b/crypto/algif_aead.c
+@@ -9,10 +9,10 @@
+ * The following concept of the memory management is used:
+ *
+ * The kernel maintains two SGLs, the TX SGL and the RX SGL. The TX SGL is
+- * filled by user space with the data submitted via sendmsg (maybe with
+- * MSG_SPLICE_PAGES). Filling up the TX SGL does not cause a crypto operation
+- * -- the data will only be tracked by the kernel. Upon receipt of one recvmsg
+- * call, the caller must provide a buffer which is tracked with the RX SGL.
++ * filled by user space with the data submitted via sendmsg. Filling up the TX
++ * SGL does not cause a crypto operation -- the data will only be tracked by the
++ * kernel. Upon receipt of one recvmsg call, the caller must provide a buffer
++ * which is tracked with the RX SGL.
+ *
+ * During the processing of the recvmsg operation, the cipher request is
+ * allocated and prepared. As part of the recvmsg operation, the processed
--- /dev/null
+From 8005dc808bcce7d6cc2ae015a3cde1683bee602d Mon Sep 17 00:00:00 2001
+From: Thorsten Blum <thorsten.blum@linux.dev>
+Date: Mon, 27 Apr 2026 18:39:39 +0200
+Subject: crypto: caam - use print_hex_dump_devel to guard key hex dumps again
+
+From: Thorsten Blum <thorsten.blum@linux.dev>
+
+commit 8005dc808bcce7d6cc2ae015a3cde1683bee602d upstream.
+
+Use print_hex_dump_devel() for dumping sensitive key material in
+*_setkey() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG
+is enabled.
+
+Fixes: 8d818c105501 ("crypto: caam/qi2 - add DPAA2-CAAM driver")
+Fixes: 226853ac3ebe ("crypto: caam/qi2 - add skcipher algorithms")
+Cc: stable@vger.kernel.org
+Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/caam/caamalg_qi2.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/drivers/crypto/caam/caamalg_qi2.c
++++ b/drivers/crypto/caam/caamalg_qi2.c
+@@ -299,7 +299,7 @@ static int aead_setkey(struct crypto_aea
+ dev_dbg(dev, "keylen %d enckeylen %d authkeylen %d\n",
+ keys.authkeylen + keys.enckeylen, keys.enckeylen,
+ keys.authkeylen);
+- print_hex_dump_debug("key in @" __stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ ctx->adata.keylen = keys.authkeylen;
+@@ -313,7 +313,7 @@ static int aead_setkey(struct crypto_aea
+ memcpy(ctx->key + ctx->adata.keylen_pad, keys.enckey, keys.enckeylen);
+ dma_sync_single_for_device(dev, ctx->key_dma, ctx->adata.keylen_pad +
+ keys.enckeylen, ctx->dir);
+- print_hex_dump_debug("ctx.key@" __stringify(__LINE__)": ",
++ print_hex_dump_devel("ctx.key@" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, ctx->key,
+ ctx->adata.keylen_pad + keys.enckeylen, 1);
+
+@@ -730,7 +730,7 @@ static int gcm_setkey(struct crypto_aead
+ ret = aes_check_keylen(keylen);
+ if (ret)
+ return ret;
+- print_hex_dump_debug("key in @" __stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ memcpy(ctx->key, key, keylen);
+@@ -826,7 +826,7 @@ static int rfc4106_setkey(struct crypto_
+ if (ret)
+ return ret;
+
+- print_hex_dump_debug("key in @" __stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ memcpy(ctx->key, key, keylen);
+@@ -925,7 +925,7 @@ static int rfc4543_setkey(struct crypto_
+ if (ret)
+ return ret;
+
+- print_hex_dump_debug("key in @" __stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ memcpy(ctx->key, key, keylen);
+@@ -953,7 +953,7 @@ static int skcipher_setkey(struct crypto
+ u32 *desc;
+ const bool is_rfc3686 = alg->caam.rfc3686;
+
+- print_hex_dump_debug("key in @" __stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ ctx->cdata.keylen = keylen;
--- /dev/null
+From 3f57657b6ea23f933371f2c2846322f441773cee Mon Sep 17 00:00:00 2001
+From: Thorsten Blum <thorsten.blum@linux.dev>
+Date: Mon, 27 Apr 2026 18:39:37 +0200
+Subject: crypto: caam - use print_hex_dump_devel to guard key hex dumps
+
+From: Thorsten Blum <thorsten.blum@linux.dev>
+
+commit 3f57657b6ea23f933371f2c2846322f441773cee upstream.
+
+Use print_hex_dump_devel() for dumping sensitive key material in
+*_setkey() and gen_split_key() to avoid leaking secrets at runtime when
+CONFIG_DYNAMIC_DEBUG is enabled.
+
+Fixes: 6e005503199b ("crypto: caam - print debug messages at debug level")
+Cc: stable@vger.kernel.org
+Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/caam/caamalg.c | 12 ++++++------
+ drivers/crypto/caam/caamalg_qi.c | 12 ++++++------
+ drivers/crypto/caam/caamhash.c | 4 ++--
+ drivers/crypto/caam/key_gen.c | 4 ++--
+ 4 files changed, 16 insertions(+), 16 deletions(-)
+
+--- a/drivers/crypto/caam/caamalg.c
++++ b/drivers/crypto/caam/caamalg.c
+@@ -597,7 +597,7 @@ static int aead_setkey(struct crypto_aea
+ dev_dbg(jrdev, "keylen %d enckeylen %d authkeylen %d\n",
+ keys.authkeylen + keys.enckeylen, keys.enckeylen,
+ keys.authkeylen);
+- print_hex_dump_debug("key in @"__stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ /*
+@@ -633,7 +633,7 @@ static int aead_setkey(struct crypto_aea
+ dma_sync_single_for_device(jrdev, ctx->key_dma, ctx->adata.keylen_pad +
+ keys.enckeylen, ctx->dir);
+
+- print_hex_dump_debug("ctx.key@"__stringify(__LINE__)": ",
++ print_hex_dump_devel("ctx.key@"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, ctx->key,
+ ctx->adata.keylen_pad + keys.enckeylen, 1);
+
+@@ -674,7 +674,7 @@ static int gcm_setkey(struct crypto_aead
+ if (err)
+ return err;
+
+- print_hex_dump_debug("key in @"__stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ memcpy(ctx->key, key, keylen);
+@@ -695,7 +695,7 @@ static int rfc4106_setkey(struct crypto_
+ if (err)
+ return err;
+
+- print_hex_dump_debug("key in @"__stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ memcpy(ctx->key, key, keylen);
+@@ -721,7 +721,7 @@ static int rfc4543_setkey(struct crypto_
+ if (err)
+ return err;
+
+- print_hex_dump_debug("key in @"__stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ memcpy(ctx->key, key, keylen);
+@@ -748,7 +748,7 @@ static int skcipher_setkey(struct crypto
+ u32 *desc;
+ const bool is_rfc3686 = alg->caam.rfc3686;
+
+- print_hex_dump_debug("key in @"__stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ ctx->cdata.keylen = keylen;
+--- a/drivers/crypto/caam/caamalg_qi.c
++++ b/drivers/crypto/caam/caamalg_qi.c
+@@ -212,7 +212,7 @@ static int aead_setkey(struct crypto_aea
+ dev_dbg(jrdev, "keylen %d enckeylen %d authkeylen %d\n",
+ keys.authkeylen + keys.enckeylen, keys.enckeylen,
+ keys.authkeylen);
+- print_hex_dump_debug("key in @" __stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ /*
+@@ -248,7 +248,7 @@ static int aead_setkey(struct crypto_aea
+ ctx->adata.keylen_pad + keys.enckeylen,
+ ctx->dir);
+
+- print_hex_dump_debug("ctx.key@" __stringify(__LINE__)": ",
++ print_hex_dump_devel("ctx.key@" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, ctx->key,
+ ctx->adata.keylen_pad + keys.enckeylen, 1);
+
+@@ -371,7 +371,7 @@ static int gcm_setkey(struct crypto_aead
+ if (ret)
+ return ret;
+
+- print_hex_dump_debug("key in @" __stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ memcpy(ctx->key, key, keylen);
+@@ -475,7 +475,7 @@ static int rfc4106_setkey(struct crypto_
+ if (ret)
+ return ret;
+
+- print_hex_dump_debug("key in @" __stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ memcpy(ctx->key, key, keylen);
+@@ -581,7 +581,7 @@ static int rfc4543_setkey(struct crypto_
+ if (ret)
+ return ret;
+
+- print_hex_dump_debug("key in @" __stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ memcpy(ctx->key, key, keylen);
+@@ -631,7 +631,7 @@ static int skcipher_setkey(struct crypto
+ const bool is_rfc3686 = alg->caam.rfc3686;
+ int ret = 0;
+
+- print_hex_dump_debug("key in @" __stringify(__LINE__)": ",
++ print_hex_dump_devel("key in @" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ ctx->cdata.keylen = keylen;
+--- a/drivers/crypto/caam/caamhash.c
++++ b/drivers/crypto/caam/caamhash.c
+@@ -505,7 +505,7 @@ static int axcbc_setkey(struct crypto_ah
+ DMA_TO_DEVICE);
+ ctx->adata.keylen = keylen;
+
+- print_hex_dump_debug("axcbc ctx.key@" __stringify(__LINE__)" : ",
++ print_hex_dump_devel("axcbc ctx.key@" __stringify(__LINE__)" : ",
+ DUMP_PREFIX_ADDRESS, 16, 4, ctx->key, keylen, 1);
+
+ return axcbc_set_sh_desc(ahash);
+@@ -525,7 +525,7 @@ static int acmac_setkey(struct crypto_ah
+ ctx->adata.key_virt = key;
+ ctx->adata.keylen = keylen;
+
+- print_hex_dump_debug("acmac ctx.key@" __stringify(__LINE__)" : ",
++ print_hex_dump_devel("acmac ctx.key@" __stringify(__LINE__)" : ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key, keylen, 1);
+
+ return acmac_set_sh_desc(ahash);
+--- a/drivers/crypto/caam/key_gen.c
++++ b/drivers/crypto/caam/key_gen.c
+@@ -58,7 +58,7 @@ int gen_split_key(struct device *jrdev,
+
+ dev_dbg(jrdev, "split keylen %d split keylen padded %d\n",
+ adata->keylen, adata->keylen_pad);
+- print_hex_dump_debug("ctx.key@" __stringify(__LINE__)": ",
++ print_hex_dump_devel("ctx.key@" __stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key_in, keylen, 1);
+
+ if (local_max > max_keylen)
+@@ -113,7 +113,7 @@ int gen_split_key(struct device *jrdev,
+ wait_for_completion(&result.completion);
+ ret = result.err;
+
+- print_hex_dump_debug("ctx.key@"__stringify(__LINE__)": ",
++ print_hex_dump_devel("ctx.key@"__stringify(__LINE__)": ",
+ DUMP_PREFIX_ADDRESS, 16, 4, key_out,
+ adata->keylen_pad, 1);
+ }
--- /dev/null
+From 5a1364da2f04217a36e2fdfa2db4ee025b383a20 Mon Sep 17 00:00:00 2001
+From: "Tycho Andersen (AMD)" <tycho@kernel.org>
+Date: Mon, 4 May 2026 10:51:45 -0600
+Subject: crypto: ccp - Do not initialize SNP for ioctl(SNP_COMMIT)
+
+From: Tycho Andersen (AMD) <tycho@kernel.org>
+
+commit 5a1364da2f04217a36e2fdfa2db4ee025b383a20 upstream.
+
+Sashiko notes:
+
+> if SEV initialization fails and KVM is actively running normal VMs, could a
+> userspace process trigger this code path via /dev/sev ioctls (e.g.,
+> SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN
+> execution for an active VM trigger a general protection fault and crash the
+> host?
+
+The SNP_COMMIT command does not require the firmware to be in any
+particular state. Skip initializing it if it was previously uninitialized.
+
+The SEV-SNP firmware specification doc 56860 does not mention SNP_COMMIT in
+Table 5 as a command that is allowed in the UNINIT state, but it is in fact
+allowed and a future documentation update will reflect that.
+
+Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls")
+Reported-by: Sashiko
+Assisted-by: Gemini:gemini-3.1-pro-preview
+Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org
+CC: <stable@vger.kernel.org>
+Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
+Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/ccp/sev-dev.c | 13 +------------
+ 1 file changed, 1 insertion(+), 12 deletions(-)
+
+--- a/drivers/crypto/ccp/sev-dev.c
++++ b/drivers/crypto/ccp/sev-dev.c
+@@ -2092,24 +2092,13 @@ cleanup:
+
+ static int sev_ioctl_do_snp_commit(struct sev_issue_cmd *argp)
+ {
+- struct sev_device *sev = psp_master->sev_data;
+ struct sev_data_snp_commit buf;
+- bool shutdown_required = false;
+- int ret, error;
+-
+- if (!sev->snp_initialized) {
+- ret = snp_move_to_init_state(argp, &shutdown_required);
+- if (ret)
+- return ret;
+- }
++ int ret;
+
+ buf.len = sizeof(buf);
+
+ ret = __sev_do_cmd_locked(SEV_CMD_SNP_COMMIT, &buf, &argp->error);
+
+- if (shutdown_required)
+- __sev_snp_shutdown_locked(&error, false);
+-
+ return ret;
+ }
+
--- /dev/null
+From f91e9dbb5845d1e5abf1028e6df57dcf61583e1b Mon Sep 17 00:00:00 2001
+From: "Tycho Andersen (AMD)" <tycho@kernel.org>
+Date: Mon, 4 May 2026 10:51:46 -0600
+Subject: crypto: ccp - Do not initialize SNP for ioctl(SNP_VLEK_LOAD)
+
+From: Tycho Andersen (AMD) <tycho@kernel.org>
+
+commit f91e9dbb5845d1e5abf1028e6df57dcf61583e1b upstream.
+
+Sashiko notes:
+
+> if SEV initialization fails and KVM is actively running normal VMs, could a
+> userspace process trigger this code path via /dev/sev ioctls (e.g.,
+> SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN
+> execution for an active VM trigger a general protection fault and crash the
+> host?
+
+The SEV firmware docs for SNP_VLEK_LOAD note:
+
+> On SNP_SHUTDOWN, the VLEK is deleted.
+
+That is, the initialization/shutdown wrapper here is pointless, because the
+firmware immediately throws away the key anyway. Instead, refuse to do
+anything if SNP has not been previously initialized.
+
+This is an ABI break: before, this was a no-op and almost certainly a
+mistake by userspace, and now it returns -ENODEV. ABI compatibility could be
+maintained here by simply returning 0 in the check instead.
+
+Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls")
+Reported-by: Sashiko
+Assisted-by: Gemini:gemini-3.1-pro-preview
+Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org
+CC: <stable@vger.kernel.org>
+Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
+Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/ccp/sev-dev.c | 17 ++++-------------
+ 1 file changed, 4 insertions(+), 13 deletions(-)
+
+--- a/drivers/crypto/ccp/sev-dev.c
++++ b/drivers/crypto/ccp/sev-dev.c
+@@ -2136,9 +2136,8 @@ static int sev_ioctl_do_snp_vlek_load(st
+ {
+ struct sev_device *sev = psp_master->sev_data;
+ struct sev_user_data_snp_vlek_load input;
+- bool shutdown_required = false;
+- int ret, error;
+ void *blob;
++ int ret;
+
+ if (!argp->data)
+ return -EINVAL;
+@@ -2146,6 +2145,9 @@ static int sev_ioctl_do_snp_vlek_load(st
+ if (!writable)
+ return -EPERM;
+
++ if (!sev->snp_initialized)
++ return -ENODEV;
++
+ if (copy_from_user(&input, u64_to_user_ptr(argp->data), sizeof(input)))
+ return -EFAULT;
+
+@@ -2159,18 +2161,7 @@ static int sev_ioctl_do_snp_vlek_load(st
+
+ input.vlek_wrapped_address = __psp_pa(blob);
+
+- if (!sev->snp_initialized) {
+- ret = snp_move_to_init_state(argp, &shutdown_required);
+- if (ret)
+- goto cleanup;
+- }
+-
+ ret = __sev_do_cmd_locked(SEV_CMD_SNP_VLEK_LOAD, &input, &argp->error);
+-
+- if (shutdown_required)
+- __sev_snp_shutdown_locked(&error, false);
+-
+-cleanup:
+ kfree(blob);
+
+ return ret;
--- /dev/null
+From fb1758e74b8061aacfbce7bbb7a7cc650537e167 Mon Sep 17 00:00:00 2001
+From: "Tycho Andersen (AMD)" <tycho@kernel.org>
+Date: Mon, 4 May 2026 10:51:44 -0600
+Subject: crypto: ccp - Do not initialize SNP for SEV ioctls
+
+From: Tycho Andersen (AMD) <tycho@kernel.org>
+
+commit fb1758e74b8061aacfbce7bbb7a7cc650537e167 upstream.
+
+Sashiko notes:
+
+> if SEV initialization fails and KVM is actively running normal VMs, could a
+> userspace process trigger this code path via /dev/sev ioctls (e.g.,
+> SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN
+> execution for an active VM trigger a general protection fault and crash the
+> host?
+
+sev_move_to_init_state() is called for ioctls requiring only SEV firmware:
+SEV_PEK_GEN, SEV_PDH_GEN, SEV_PEK_CSR, SEV_PEK_CERT_IMPORT, and
+SEV_PDH_CERT_EXPORT. After the firmware command, it does SEV_SHUTDOWN on
+the SEV firmware. Since these commands do not require SNP to be
+initialized, skip it by calling __sev_platform_init_locked() which only
+initializes the SEV firmware. This way SNP is not Initialized at all, and
+HSAVE_PA is not cleared.
+
+The previous code saved any SEV initialization firmware error to
+init_args.error and then threw it away and hardcoded the return value of
+INVALID_PLATFORM_STATE regardless of the real firmware error. This patch
+changes it to surface the underlying error, which is hopefully both more
+useful and doesn't cause any problems.
+
+Note that it is still safe to call __sev_firmware_shutdown() directly: it
+calls __sev_snp_shutdown_locked(), which skips SNP shutdown if SNP was not
+initialized.
+
+Fixes: ceac7fb89e8d ("crypto: ccp - Ensure implicit SEV/SNP init and shutdown in ioctls")
+Reported-by: Sashiko
+Assisted-by: Gemini:gemini-3.1-pro-preview
+Link: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org
+CC: <stable@vger.kernel.org>
+Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org>
+Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/ccp/sev-dev.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+--- a/drivers/crypto/ccp/sev-dev.c
++++ b/drivers/crypto/ccp/sev-dev.c
+@@ -1397,14 +1397,11 @@ static int sev_get_platform_state(int *s
+
+ static int sev_move_to_init_state(struct sev_issue_cmd *argp, bool *shutdown_required)
+ {
+- struct sev_platform_init_args init_args = {0};
+ int rc;
+
+- rc = _sev_platform_init_locked(&init_args);
+- if (rc) {
+- argp->error = SEV_RET_INVALID_PLATFORM_STATE;
++ rc = __sev_platform_init_locked(&argp->error);
++ if (rc)
+ return rc;
+- }
+
+ *shutdown_required = true;
+
--- /dev/null
+From 6f49f00c981bbb9ef602966f19bfdbef46b681d2 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@kernel.org>
+Date: Sun, 19 Apr 2026 23:33:48 -0700
+Subject: crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels
+
+From: Eric Biggers <ebiggers@kernel.org>
+
+commit 6f49f00c981bbb9ef602966f19bfdbef46b681d2 upstream.
+
+On 64-bit kernels, drbg_max_addtl() returns 2**35 bytes. That's too
+large, for two reasons:
+
+1. SP800-90A says the maximum limit is 2**35 *bits*, not 2**35 bytes.
+ So the implemented limit has confused bits and bytes.
+
+2. When drbg_kcapi_hash() calls crypto_shash_update() on the additional
+ information string, the length is implicitly cast to 'unsigned int'.
+ That truncates the additional information string to U32_MAX bytes.
+
+Fix the maximum additional information string length to always be
+U32_MAX - 1, causing an error to be returned for any longer lengths.
+
+Fixes: 541af946fe13 ("crypto: drbg - SP800-90A Deterministic Random Bit Generator")
+Cc: stable@vger.kernel.org
+Signed-off-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/crypto/drbg.h | 18 +++++++-----------
+ 1 file changed, 7 insertions(+), 11 deletions(-)
+
+--- a/include/crypto/drbg.h
++++ b/include/crypto/drbg.h
+@@ -171,19 +171,15 @@ static inline size_t drbg_max_request_by
+ return (1 << 16);
+ }
+
++/*
++ * SP800-90A allows implementations to support additional info / personalization
++ * strings of up to 2**35 bits. Implementations can have a smaller maximum. We
++ * use 2**35 - 16 bits == U32_MAX - 1 bytes so that the max + 1 always fits in a
++ * size_t, allowing drbg_healthcheck_sanity() to verify its enforcement.
++ */
+ static inline size_t drbg_max_addtl(struct drbg_state *drbg)
+ {
+- /* SP800-90A requires 2**35 bytes additional info str / pers str */
+-#if (__BITS_PER_LONG == 32)
+- /*
+- * SP800-90A allows smaller maximum numbers to be returned -- we
+- * return SIZE_MAX - 1 to allow the verification of the enforcement
+- * of this value in drbg_healthcheck_sanity.
+- */
+- return (SIZE_MAX - 1);
+-#else
+- return (1UL<<35);
+-#endif
++ return U32_MAX - 1;
+ }
+
+ static inline size_t drbg_max_requests(struct drbg_state *drbg)
--- /dev/null
+From 39a31ad9e2a5ed7e9c9c6f711dca96c8c8f5f26b Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@kernel.org>
+Date: Sun, 19 Apr 2026 23:33:45 -0700
+Subject: crypto: drbg - Fix returning success on failure in CTR_DRBG
+
+From: Eric Biggers <ebiggers@kernel.org>
+
+commit 39a31ad9e2a5ed7e9c9c6f711dca96c8c8f5f26b upstream.
+
+drbg_ctr_generate() sometimes returns success when it fails, leaving the
+output buffer uninitialized. Fix it.
+
+Fixes: cde001e4c3c3 ("crypto: rng - RNGs must return 0 in success case")
+Cc: stable@vger.kernel.org
+Signed-off-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ crypto/drbg.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/crypto/drbg.c
++++ b/crypto/drbg.c
+@@ -591,7 +591,7 @@ static int drbg_ctr_generate(struct drbg
+ if (addtl && !list_empty(addtl)) {
+ ret = drbg_ctr_update(drbg, addtl, 2);
+ if (ret)
+- return 0;
++ return ret;
+ }
+
+ /* 10.2.1.5.2 step 4.1 */
--- /dev/null
+From a8a1f93080efc83a9ff8452954429ae379e9e614 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@kernel.org>
+Date: Sun, 19 Apr 2026 23:33:49 -0700
+Subject: crypto: drbg - Fix the fips_enabled priority boost
+
+From: Eric Biggers <ebiggers@kernel.org>
+
+commit a8a1f93080efc83a9ff8452954429ae379e9e614 upstream.
+
+When fips_enabled=1, it seems to have been intended for one of the
+algorithms defined in crypto/drbg.c to be the highest priority "stdrng"
+algorithm, so that it is what is used by "stdrng" users.
+
+However, the code only boosts the priority to 400, which is less than
+the priority 500 used in drivers/crypto/caam/caamprng.c. Thus, the CAAM
+RNG could be used instead.
+
+Fix this by boosting the priority by 2000 instead of 200.
+
+Fixes: 541af946fe13 ("crypto: drbg - SP800-90A Deterministic Random Bit Generator")
+Cc: stable@vger.kernel.org
+Signed-off-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ crypto/drbg.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/crypto/drbg.c
++++ b/crypto/drbg.c
+@@ -2081,7 +2081,7 @@ static inline void __init drbg_fill_arra
+ * it is selected.
+ */
+ if (fips_enabled)
+- alg->base.cra_priority += 200;
++ alg->base.cra_priority += 2000;
+
+ alg->base.cra_ctxsize = sizeof(struct drbg_state);
+ alg->base.cra_module = THIS_MODULE;
--- /dev/null
+From 27b536a2ec8e2f85a0380c2d13c9ecbc7aaab406 Mon Sep 17 00:00:00 2001
+From: Anastasia Tishchenko <sv3iry@gmail.com>
+Date: Wed, 13 May 2026 13:57:40 +0300
+Subject: crypto: ecc - Fix carry overflow in vli multiplication
+
+From: Anastasia Tishchenko <sv3iry@gmail.com>
+
+commit 27b536a2ec8e2f85a0380c2d13c9ecbc7aaab406 upstream.
+
+The carry flag calculation fails when r01.m_high is saturated
+(0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows.
+
+The condition (r01.m_high < product.m_high) doesn't handle the case
+where r01.m_high == product.m_high and an additional carry exists
+from lower-bit overflow.
+
+When commit 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")
+introduced crypto/ecc.c, it split the muladd() function in the
+micro-ecc library into separate mul_64_64() and add_128_128() helpers.
+It seems the check got lost in translation.
+
+Add proper handling for this boundary by accounting for the carry
+from the lower addition.
+
+Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")
+Signed-off-by: Anastasia Tishchenko <sv3iry@gmail.com>
+Cc: stable@vger.kernel.org # v4.8+
+Reviewed-by: Lukas Wunner <lukas@wunner.de>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ crypto/ecc.c | 31 ++++++++++++++++++++-----------
+ 1 file changed, 20 insertions(+), 11 deletions(-)
+
+--- a/crypto/ecc.c
++++ b/crypto/ecc.c
+@@ -402,14 +402,26 @@ static uint128_t mul_64_64(u64 left, u64
+ return result;
+ }
+
+-static uint128_t add_128_128(uint128_t a, uint128_t b)
++/* Calculate addition with overflow checking. Returns true on wrap-around,
++ * false otherwise.
++ */
++static bool check_add_128_128_overflow(uint128_t *result, uint128_t a,
++ uint128_t b)
+ {
+- uint128_t result;
++ bool carry;
+
+- result.m_low = a.m_low + b.m_low;
+- result.m_high = a.m_high + b.m_high + (result.m_low < a.m_low);
++ result->m_low = a.m_low + b.m_low;
++ carry = (result->m_low < a.m_low);
+
+- return result;
++ result->m_high = a.m_high + b.m_high + carry;
++
++ /* Using constant-time bitwise arithmetic to prevent timing
++ * side-channels.
++ */
++ carry = (result->m_high < a.m_high) |
++ ((result->m_high == a.m_high) & carry);
++
++ return carry;
+ }
+
+ static void vli_mult(u64 *result, const u64 *left, const u64 *right,
+@@ -434,9 +446,7 @@ static void vli_mult(u64 *result, const
+ uint128_t product;
+
+ product = mul_64_64(left[i], right[k - i]);
+-
+- r01 = add_128_128(r01, product);
+- r2 += (r01.m_high < product.m_high);
++ r2 += check_add_128_128_overflow(&r01, r01, product);
+ }
+
+ result[k] = r01.m_low;
+@@ -459,7 +469,7 @@ static void vli_umult(u64 *result, const
+ uint128_t product;
+
+ product = mul_64_64(left[k], right);
+- r01 = add_128_128(r01, product);
++ check_add_128_128_overflow(&r01, r01, product);
+ /* no carry */
+ result[k] = r01.m_low;
+ r01.m_low = r01.m_high;
+@@ -496,8 +506,7 @@ static void vli_square(u64 *result, cons
+ product.m_low <<= 1;
+ }
+
+- r01 = add_128_128(r01, product);
+- r2 += (r01.m_high < product.m_high);
++ r2 += check_add_128_128_overflow(&r01, r01, product);
+ }
+
+ result[k] = r01.m_low;
--- /dev/null
+From ed459fe319376e876de433d12b6c6772e612ca36 Mon Sep 17 00:00:00 2001
+From: Ruijie Li <ruijieli51@gmail.com>
+Date: Mon, 25 May 2026 19:45:21 +0800
+Subject: crypto: pcrypt - restore callback for non-parallel fallback
+
+From: Ruijie Li <ruijieli51@gmail.com>
+
+commit ed459fe319376e876de433d12b6c6772e612ca36 upstream.
+
+pcrypt installs pcrypt_aead_done() on the child AEAD request before
+trying to submit it through padata. If padata_do_parallel() returns
+-EBUSY, pcrypt falls back to calling the child AEAD directly.
+
+That fallback must not keep the padata completion callback. Otherwise
+an asynchronous completion runs pcrypt_aead_done() even though the
+request was never enrolled in padata.
+
+Restore the original request callback and callback data before calling
+the child AEAD directly. This keeps the fallback path aligned with a
+direct AEAD request while leaving the parallel path unchanged.
+
+Fixes: 662f2f13e66d ("crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY")
+Cc: stable@kernel.org
+Reported-by: Yuan Tan <yuantan098@gmail.com>
+Reported-by: Yifan Wu <yifanwucs@gmail.com>
+Reported-by: Juefei Pu <tomapufckgml@gmail.com>
+Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
+Reported-by: Xin Liu <bird@lzu.edu.cn>
+Assisted-by: Codex:gpt-5.4
+Signed-off-by: Ruijie Li <ruijieli51@gmail.com>
+Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ crypto/pcrypt.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/crypto/pcrypt.c
++++ b/crypto/pcrypt.c
+@@ -122,6 +122,8 @@ static int pcrypt_aead_encrypt(struct ae
+ return -EINPROGRESS;
+ if (err == -EBUSY) {
+ /* try non-parallel mode */
++ aead_request_set_callback(creq, flags, req->base.complete,
++ req->base.data);
+ return crypto_aead_encrypt(creq);
+ }
+
+@@ -173,6 +175,8 @@ static int pcrypt_aead_decrypt(struct ae
+ return -EINPROGRESS;
+ if (err == -EBUSY) {
+ /* try non-parallel mode */
++ aead_request_set_callback(creq, flags, req->base.complete,
++ req->base.data);
+ return crypto_aead_decrypt(creq);
+ }
+
--- /dev/null
+From 6ea0ce3a19f9c37a014099e2b0a46b27fa164564 Mon Sep 17 00:00:00 2001
+From: Wentao Liang <vulab@iscas.ac.cn>
+Date: Thu, 4 Jun 2026 10:27:06 +0000
+Subject: crypto: tegra - fix refcount leak in tegra_se_host1x_submit()
+
+From: Wentao Liang <vulab@iscas.ac.cn>
+
+commit 6ea0ce3a19f9c37a014099e2b0a46b27fa164564 upstream.
+
+The timeout error path in tegra_se_host1x_submit() returns without
+calling host1x_job_put(), while all other paths (success, submit
+error, pin error) properly release the job reference through the
+job_put label. Since host1x_job_alloc() initializes the reference
+count and host1x_job_put() is required to drop it, omitting it on
+timeout causes a permanent refcount leak.
+
+Fix this by redirecting the timeout return to the existing job_put
+label, ensuring the job reference and any associated syncpt
+references are consistently released.
+
+Cc: stable@vger.kernel.org
+Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver")
+Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
+Reviewed-by: Akhil R <akhilrajeev@nvidia.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/tegra/tegra-se-main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/crypto/tegra/tegra-se-main.c
++++ b/drivers/crypto/tegra/tegra-se-main.c
+@@ -180,7 +180,7 @@ int tegra_se_host1x_submit(struct tegra_
+ MAX_SCHEDULE_TIMEOUT, NULL);
+ if (ret) {
+ dev_err(se->dev, "host1x job timed out\n");
+- return ret;
++ goto job_put;
+ }
+
+ host1x_job_put(job);
--- /dev/null
+From 457e32348d606a77f9b20e25e989734189834c07 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 11 May 2026 13:04:16 +0200
+Subject: dm-ioctl: report an error if a device has no table
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 457e32348d606a77f9b20e25e989734189834c07 upstream.
+
+When we send a message to a device that has no table, the return code was
+not set. The code would return "2", which is not considered a valid return value.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-ioctl.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm-ioctl.c
++++ b/drivers/md/dm-ioctl.c
+@@ -1806,8 +1806,11 @@ static int target_message(struct file *f
+ goto out_argv;
+
+ table = dm_get_live_table(md, &srcu_idx);
+- if (!table)
++ if (!table) {
++ DMERR("The device has no table.");
++ r = -EINVAL;
+ goto out_table;
++ }
+
+ if (dm_deleting_md(md)) {
+ r = -ENXIO;
--- /dev/null
+From 8d13f7a8450206e3f820cdb26e33e91d181071b4 Mon Sep 17 00:00:00 2001
+From: Wentao Liang <vulab@iscas.ac.cn>
+Date: Wed, 3 Jun 2026 11:03:27 +0000
+Subject: hwrng: jh7110 - fix refcount leak in starfive_trng_read()
+
+From: Wentao Liang <vulab@iscas.ac.cn>
+
+commit 8d13f7a8450206e3f820cdb26e33e91d181071b4 upstream.
+
+The starfive_trng_read() function acquires a runtime PM reference
+via pm_runtime_get_sync() but fails to release it on two error
+paths. If starfive_trng_wait_idle() or starfive_trng_cmd() returns
+an error, the function exits without calling
+pm_runtime_put_sync_autosuspend(), leaving the runtime PM usage
+counter permanently elevated and preventing the device from entering
+runtime suspend.
+
+Refactor the function to use a unified error path that calls
+pm_runtime_put_sync_autosuspend() before returning.
+
+Cc: stable@vger.kernel.org
+Fixes: c388f458bc34 ("hwrng: starfive - Add TRNG driver for StarFive SoC")
+Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/hw_random/jh7110-trng.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/drivers/char/hw_random/jh7110-trng.c
++++ b/drivers/char/hw_random/jh7110-trng.c
+@@ -256,19 +256,22 @@ static int starfive_trng_read(struct hwr
+
+ if (wait) {
+ ret = starfive_trng_wait_idle(trng);
+- if (ret)
+- return -ETIMEDOUT;
++ if (ret) {
++ ret = -ETIMEDOUT;
++ goto out_put;
++ }
+ }
+
+ ret = starfive_trng_cmd(trng, STARFIVE_CTRL_GENE_RANDNUM, wait);
+ if (ret)
+- return ret;
++ goto out_put;
+
+ memcpy_fromio(buf, trng->base + STARFIVE_RAND0, max);
++ ret = max;
+
++out_put:
+ pm_runtime_put_sync_autosuspend(trng->dev);
+-
+- return max;
++ return ret;
+ }
+
+ static int starfive_trng_probe(struct platform_device *pdev)
--- /dev/null
+From 5fa1d6a5ec2356d2107dead614437c66fa7138b1 Mon Sep 17 00:00:00 2001
+From: Bryam Vargas <hexlabsecurity@proton.me>
+Date: Sun, 7 Jun 2026 01:18:27 +0000
+Subject: isofs: bound Rock Ridge symlink components to the SL record
+
+From: Bryam Vargas <hexlabsecurity@proton.me>
+
+commit 5fa1d6a5ec2356d2107dead614437c66fa7138b1 upstream.
+
+get_symlink_chunk() and the SL handling in
+parse_rock_ridge_inode_internal() walk the variable-length components of
+a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte
+header (flags, len) followed by len bytes of text, so it occupies
+slp->len + 2 bytes. Both loops read slp->len and advance to the next
+component, and get_symlink_chunk() additionally does
+memcpy(rpnt, slp->text, slp->len), but neither checks that the component
+lies within the SL record before dereferencing it.
+
+A crafted SL record whose component declares a len that runs past the
+record (rr->len) therefore triggers an out-of-bounds read of up to 255
+bytes. When the record sits at the tail of its backing buffer - for
+example a small kmalloc()ed continuation block reached through a CE
+record - the read crosses the allocation; get_symlink_chunk() then
+copies the out-of-bounds bytes into the symlink body returned to user
+space by readlink(), disclosing adjacent kernel memory.
+
+ISO 9660 images are routinely mounted from untrusted removable media -
+desktop environments auto-mount them (e.g. via udisks2) without
+CAP_SYS_ADMIN - so the record contents are attacker-controlled.
+
+Reject any component that does not fit in the remaining record bytes
+before using it. In get_symlink_chunk() return NULL, like the existing
+output-buffer (plimit) checks, so a malformed record makes readlink()
+fail with -EIO rather than silently returning a truncated target; in
+parse_rock_ridge_inode_internal() stop the inode-size walk.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: stable@vger.kernel.org
+Suggested-by: Michael Bommarito <michael.bommarito@gmail.com>
+Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
+Link: https://patch.msgid.link/20260607011823.217748-1-hexlabsecurity@proton.me
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/isofs/rock.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/fs/isofs/rock.c
++++ b/fs/isofs/rock.c
+@@ -466,6 +466,9 @@ repeat:
+ inode->i_size = symlink_len;
+ while (slen > 1) {
+ rootflag = 0;
++ /* keep the component within the SL record */
++ if (slp->len + 2 > slen)
++ goto eio;
+ switch (slp->flags & ~1) {
+ case 0:
+ inode->i_size +=
+@@ -621,6 +624,14 @@ static char *get_symlink_chunk(char *rpn
+ slp = &rr->u.SL.link;
+ while (slen > 1) {
+ rootflag = 0;
++ /*
++ * A component is slp->len + 2 bytes (a two-byte header plus
++ * len bytes of text). If it does not fit in the bytes left in
++ * the SL record the record is malformed: fail like the plimit
++ * checks below so readlink() returns -EIO, not a truncated path.
++ */
++ if (slp->len + 2 > slen)
++ return NULL;
+ switch (slp->flags & ~1) {
+ case 0:
+ if (slp->len > plimit - rpnt)
--- /dev/null
+From 88bac2c1a72b8f4f71e9845699aa872df04e5850 Mon Sep 17 00:00:00 2001
+From: "Achkinazi, Igor" <Igor.Achkinazi@dell.com>
+Date: Thu, 28 May 2026 15:24:27 +0000
+Subject: nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace disks
+
+From: Achkinazi, Igor <Igor.Achkinazi@dell.com>
+
+commit 88bac2c1a72b8f4f71e9845699aa872df04e5850 upstream.
+
+When nvme_ns_head_submit_bio() remaps a bio from the multipath head to a
+per-path namespace, bio_set_dev() clears BIO_REMAPPED. The remapped bio
+is then resubmitted through submit_bio_noacct() which calls
+bio_check_eod() because BIO_REMAPPED is not set.
+
+This races with nvme_ns_remove() which zeroes the per-path capacity
+before synchronize_srcu():
+
+ CPU 0 (IO submission)
+ ---------------------
+ srcu_read_lock()
+ nvme_find_path() -> ns
+ [NVME_NS_READY is set]
+
+ CPU 1 (namespace removal)
+ -------------------------
+ clear_bit(NVME_NS_READY)
+ set_capacity(ns->disk, 0)
+ synchronize_srcu() <- blocks
+
+ CPU 0 (IO submission)
+ ---------------------
+ bio_set_dev(bio, ns->disk->part0)
+ [clears BIO_REMAPPED]
+ submit_bio_noacct(bio)
+ -> bio_check_eod() sees capacity=0
+ -> bio fails with IO error
+
+The SRCU read lock prevents synchronize_srcu() from completing, but does
+not prevent set_capacity(0) from executing. The bio fails the EOD check
+before it reaches the NVMe driver, so nvme_failover_req() never gets a
+chance to redirect it to another path of multipath. IO errors are
+reported to the application despite another path being available.
+
+On older kernels (before commit 0b64682e78f7 "block: skip unnecessary
+checks for split bio"), the same race was also reachable through split
+remainders resubmitted via submit_bio_noacct().
+
+Fix this by setting BIO_REMAPPED after bio_set_dev() in
+nvme_ns_head_submit_bio(). This skips bio_check_eod() on the per-path
+device; the EOD check already passed on the multipath head.
+
+NVMe per-path namespace devices are always whole disks (bd_partno=0), so
+the blk_partition_remap() skip also gated by BIO_REMAPPED is a no-op.
+The flag does not persist across failover and cannot go stale if the
+namespace geometry changes between attempts: nvme_failover_req() calls
+bio_set_dev() to redirect the bio back to the multipath head, which
+clears BIO_REMAPPED. When nvme_requeue_work() resubmits through
+submit_bio_noacct(), bio_check_eod() runs normally against the current
+capacity.
+
+Same approach as commit 3a905c37c351 ("block: skip bio_check_eod for
+partition-remapped bios").
+
+Fixes: a7c7f7b2b641 ("nvme: use bio_set_dev to assign ->bi_bdev")
+Cc: stable@vger.kernel.org
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Igor Achkinazi <igor.achkinazi@dell.com>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/host/multipath.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/nvme/host/multipath.c
++++ b/drivers/nvme/host/multipath.c
+@@ -467,6 +467,12 @@ static void nvme_ns_head_submit_bio(stru
+ ns = nvme_find_path(head);
+ if (likely(ns)) {
+ bio_set_dev(bio, ns->disk->part0);
++ /*
++ * Use BIO_REMAPPED to skip bio_check_eod() when this bio
++ * enters submit_bio_noacct() for the per-path device. The EOD
++ * check already passed on the multipath head.
++ */
++ bio_set_flag(bio, BIO_REMAPPED);
+ bio->bi_opf |= REQ_NVME_MPATH;
+ trace_block_bio_remap(bio, disk_devt(ns->head->disk),
+ bio->bi_iter.bi_sector);
--- /dev/null
+From badc53620fe813b3a9f727ef9526f98567c2c898 Mon Sep 17 00:00:00 2001
+From: Wentao Liang <vulab@iscas.ac.cn>
+Date: Wed, 27 May 2026 08:45:44 +0000
+Subject: nvme: target: rdma: fix ndev refcount leak on queue connect
+
+From: Wentao Liang <vulab@iscas.ac.cn>
+
+commit badc53620fe813b3a9f727ef9526f98567c2c898 upstream.
+
+nvmet_rdma_queue_connect() calls nvmet_rdma_find_get_device() which
+acquires a reference on the returned ndev via kref_get(). On the path
+where the host queue backlog is exceeded and the function returns
+NVME_SC_CONNECT_CTRL_BUSY, reference of ndev is not released, leaking
+the kref.
+
+Fix this by adding a goto to the existing put_device label before the
+early return.
+
+Fixes: 31deaeb11ba7 ("nvmet-rdma: avoid circular locking dependency on install_queue()")
+Cc: stable@vger.kernel.org
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/target/rdma.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/nvme/target/rdma.c
++++ b/drivers/nvme/target/rdma.c
+@@ -1597,8 +1597,10 @@ static int nvmet_rdma_queue_connect(stru
+ pending++;
+ }
+ mutex_unlock(&nvmet_rdma_queue_mutex);
+- if (pending > NVMET_RDMA_BACKLOG)
+- return NVME_SC_CONNECT_CTRL_BUSY;
++ if (pending > NVMET_RDMA_BACKLOG) {
++ ret = NVME_SC_CONNECT_CTRL_BUSY;
++ goto put_device;
++ }
+ }
+
+ ret = nvmet_rdma_cm_accept(cm_id, queue, &event->param.conn);
--- /dev/null
+From 3a413ece2504c70aa34a20be4dafec04e8c741f9 Mon Sep 17 00:00:00 2001
+From: Tianchu Chen <flynnnchen@tencent.com>
+Date: Fri, 29 May 2026 14:18:39 +0000
+Subject: nvmet-auth: validate reply message payload bounds against transfer length
+
+From: Tianchu Chen <flynnnchen@tencent.com>
+
+commit 3a413ece2504c70aa34a20be4dafec04e8c741f9 upstream.
+
+nvmet_auth_reply() accesses the variable-length rval[] array using
+attacker-controlled hl (hash length) and dhvlen (DH value length) fields
+without verifying they fit within the allocated buffer of tl bytes.
+
+A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a
+small transfer length but large hl/dhvlen values, causing out-of-bounds
+heap reads when the target processes the DH public key (rval + 2*hl) or
+performs the host response memcmp.
+
+With DH authentication configured, the OOB pointer is passed directly to
+sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching
+up to 526 bytes past the buffer. This is exploitable pre-authentication.
+
+Add bounds validation ensuring sizeof(*data) + 2*hl + dhvlen <= tl before
+any access to the variable-length fields.
+
+Discovered by Atuin - Automated Vulnerability Discovery Engine.
+
+Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication")
+Cc: stable@vger.kernel.org
+Reviewed-by: Hannes Reinecke <hare@kernel.org>
+Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/target/fabrics-cmd-auth.c | 15 ++++++++++++---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+--- a/drivers/nvme/target/fabrics-cmd-auth.c
++++ b/drivers/nvme/target/fabrics-cmd-auth.c
+@@ -109,13 +109,22 @@ static u8 nvmet_auth_negotiate(struct nv
+ return 0;
+ }
+
+-static u8 nvmet_auth_reply(struct nvmet_req *req, void *d)
++static u8 nvmet_auth_reply(struct nvmet_req *req, void *d, u32 tl)
+ {
+ struct nvmet_ctrl *ctrl = req->sq->ctrl;
+ struct nvmf_auth_dhchap_reply_data *data = d;
+- u16 dhvlen = le16_to_cpu(data->dhvlen);
++ u16 dhvlen;
+ u8 *response;
+
++ if (tl < sizeof(*data))
++ return NVME_AUTH_DHCHAP_FAILURE_INCORRECT_PAYLOAD;
++
++ dhvlen = le16_to_cpu(data->dhvlen);
++
++ /* Validate that hl and dhvlen fit within the transfer length */
++ if (sizeof(*data) + 2 * (size_t)data->hl + dhvlen > tl)
++ return NVME_AUTH_DHCHAP_FAILURE_INCORRECT_PAYLOAD;
++
+ pr_debug("%s: ctrl %d qid %d: data hl %d cvalid %d dhvlen %u\n",
+ __func__, ctrl->cntlid, req->sq->qid,
+ data->hl, data->cvalid, dhvlen);
+@@ -287,7 +296,7 @@ void nvmet_execute_auth_send(struct nvme
+
+ switch (data->auth_id) {
+ case NVME_AUTH_DHCHAP_MESSAGE_REPLY:
+- dhchap_status = nvmet_auth_reply(req, d);
++ dhchap_status = nvmet_auth_reply(req, d, tl);
+ if (dhchap_status == 0)
+ req->sq->dhchap_step =
+ NVME_AUTH_DHCHAP_MESSAGE_SUCCESS1;
--- /dev/null
+From 53cd102a7a56079b11b897835bd9b94c14e6322c Mon Sep 17 00:00:00 2001
+From: Bryam Vargas <hexlabsecurity@proton.me>
+Date: Wed, 27 May 2026 15:00:00 -0500
+Subject: nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page
+
+From: Bryam Vargas <hexlabsecurity@proton.me>
+
+commit 53cd102a7a56079b11b897835bd9b94c14e6322c upstream.
+
+nvmet_execute_disc_get_log_page() validates only the dword alignment
+of the host-supplied Log Page Offset (lpo). The 64-bit offset is then
+added to a small kzalloc'd buffer that holds the discovery log page
+and the result is passed straight to nvmet_copy_to_sgl(), which
+memcpy()s data_len bytes out to the host with no source-side bound
+check:
+
+ u64 offset = nvmet_get_log_page_offset(req->cmd); /* 64-bit host */
+ size_t data_len = nvmet_get_log_page_len(req->cmd); /* 32-bit host */
+ ...
+ if (offset & 0x3) { ... } /* only check */
+ ...
+ alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);
+ buffer = kzalloc(alloc_len, GFP_KERNEL);
+ ...
+ status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);
+
+The Discovery controller is unauthenticated -- nvmet_host_allowed()
+returns true unconditionally for the discovery subsystem -- so the call
+is reachable pre-authentication by any TCP/RDMA/FC peer that can reach
+the nvmet target. With a discovery log page of ~1 KiB, an attacker
+requesting up to 4 KiB starting at offset == alloc_len reads the next
+slab page out and gets its content returned over the fabric (an
+empirical run on a default nvmet-tcp loopback target leaked 81
+canonical kernel pointers in one Get Log Page response). Pointing the
+offset at unmapped kernel memory faults the in-kernel memcpy and
+crashes (or panics, on panic_on_oops=1) the target host instead.
+
+The attacker-controlled source-side offset pattern
+"nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique
+to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every
+other Get Log Page handler in admin-cmd.c either ignores lpo (and
+silently starts every response at offset 0) or tracks a local
+destination offset with a fixed source pointer.
+
+Validate the host-supplied offset against the log page size, cap the
+copy length to what is actually available, and zero-fill any remainder
+of the host transfer buffer. The zero-fill matches the existing
+short-response pattern in nvmet_execute_get_log_changed_ns()
+(admin-cmd.c) and prevents leaking transport SGL contents when the
+host asks for more bytes than the log page contains.
+
+Fixes: a07b4970f464 ("nvmet: add a generic NVMe target")
+Cc: stable@vger.kernel.org
+Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/target/discovery.c | 23 ++++++++++++++++++++++-
+ 1 file changed, 22 insertions(+), 1 deletion(-)
+
+--- a/drivers/nvme/target/discovery.c
++++ b/drivers/nvme/target/discovery.c
+@@ -166,6 +166,7 @@ static void nvmet_execute_disc_get_log_p
+ u64 offset = nvmet_get_log_page_offset(req->cmd);
+ size_t data_len = nvmet_get_log_page_len(req->cmd);
+ size_t alloc_len;
++ size_t copy_len;
+ struct nvmet_subsys_link *p;
+ struct nvmet_port *r;
+ u32 numrec = 0;
+@@ -239,7 +240,27 @@ static void nvmet_execute_disc_get_log_p
+
+ up_read(&nvmet_config_sem);
+
+- status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);
++ /*
++ * Validate the host-supplied log page offset before copying out.
++ * Without this check, the host controls a 64-bit byte offset into
++ * a small kzalloc'd buffer: a value past the log page lets the
++ * subsequent memcpy read adjacent kernel heap, and a value aimed
++ * at unmapped kernel memory faults the in-kernel copy and crashes
++ * the target host. The Discovery controller is unauthenticated,
++ * so the bug is reachable from any reachable fabric peer.
++ */
++ if (offset > alloc_len) {
++ req->error_loc =
++ offsetof(struct nvme_get_log_page_command, lpo);
++ status = NVME_SC_INVALID_FIELD | NVME_STATUS_DNR;
++ goto out_free_buffer;
++ }
++
++ copy_len = min_t(size_t, data_len, alloc_len - offset);
++ status = nvmet_copy_to_sgl(req, 0, buffer + offset, copy_len);
++ if (!status && copy_len < data_len)
++ status = nvmet_zero_sgl(req, copy_len, data_len - copy_len);
++out_free_buffer:
+ kfree(buffer);
+ out:
+ nvmet_req_complete(req, status);
--- /dev/null
+From 2dc0bfd2fe355fb930de63c2f2eb8ced8570c579 Mon Sep 17 00:00:00 2001
+From: Bryam Vargas <hexlabsecurity@proton.me>
+Date: Sun, 7 Jun 2026 06:41:43 +0000
+Subject: partitions: aix: bound the pp_count scan to the ppe array
+
+From: Bryam Vargas <hexlabsecurity@proton.me>
+
+commit 2dc0bfd2fe355fb930de63c2f2eb8ced8570c579 upstream.
+
+aix_partition() reads the physical volume descriptor into a fixed-size
+struct pvd and then scans its physical-partition-extent array:
+
+ int numpps = be16_to_cpu(pvd->pp_count);
+ ...
+ for (i = 0; i < numpps; i += 1) {
+ struct ppe *p = pvd->ppe + i;
+ ...
+ lp_ix = be16_to_cpu(p->lp_ix);
+
+pvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a
+fixed ARRAY_SIZE(pvd->ppe) (1016) entries, but the loop runs up to the
+on-disk pp_count. pp_count is an unvalidated __be16 read straight from
+the descriptor, so a crafted AIX image with pp_count larger than 1016
+drives the loop to read pvd->ppe[i] past the end of the allocation (up
+to 65535 entries, ~2 MB out of bounds).
+
+The partition scan runs without mounting anything, when a block device
+with a crafted AIX/IBM partition table appears (an attacker-supplied
+image attached with losetup -P, or a device auto-scanned by udev), via
+msdos_partition() -> aix_partition().
+
+Clamp the scan to the number of entries the ppe[] array can hold.
+
+Fixes: 6ceea22bbbc8 ("partitions: add aix lvm partition support files")
+Cc: stable@vger.kernel.org
+Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
+Acked-by: Philippe De Muyter <phdm@macqel.be>
+Link: https://patch.msgid.link/20260607064137.302574-1-hexlabsecurity@proton.me
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/partitions/aix.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/block/partitions/aix.c
++++ b/block/partitions/aix.c
+@@ -228,6 +228,15 @@ int aix_partition(struct parsed_partitio
+ int next_lp_ix = 1;
+ int lp_ix;
+
++ /*
++ * pvd was read into a fixed-size struct pvd whose ppe[] array
++ * holds ARRAY_SIZE(pvd->ppe) entries. pp_count is an
++ * unvalidated on-disk __be16, so clamp the scan to the array
++ * size to avoid walking past the allocation.
++ */
++ if (numpps > ARRAY_SIZE(pvd->ppe))
++ numpps = ARRAY_SIZE(pvd->ppe);
++
+ for (i = 0; i < numpps; i += 1) {
+ struct ppe *p = pvd->ppe + i;
+ unsigned int lv_ix;
block-skip-sync_blockdev-on-surprise-removal-in-bdev_mark_dead.patch
x86-fs-resctrl-prevent-out-of-bounds-access-while-of.patch
pci-always-lift-2.5gt-s-restriction-in-pcie-failed-l.patch
+udf-validate-free-block-extents-against-the-partition-length.patch
+udf-validate-vat-header-length-against-the-vat-inode-size.patch
+udf-validate-sparing-table-length-as-an-entry-count-not-a-byte-count.patch
+hwrng-jh7110-fix-refcount-leak-in-starfive_trng_read.patch
+nvme-target-rdma-fix-ndev-refcount-leak-on-queue-connect.patch
+dm-ioctl-report-an-error-if-a-device-has-no-table.patch
+nvme-multipath-set-bio_remapped-on-bios-remapped-to-per-path-namespace-disks.patch
+nvmet-fix-pre-auth-out-of-bounds-heap-read-in-discovery-get-log-page.patch
+nvmet-auth-validate-reply-message-payload-bounds-against-transfer-length.patch
+btrfs-do-not-trim-a-device-which-is-not-writeable.patch
+partitions-aix-bound-the-pp_count-scan-to-the-ppe-array.patch
+isofs-bound-rock-ridge-symlink-components-to-the-sl-record.patch
+crypto-af_alg-remove-zero-copy-support-from-skcipher-and-aead.patch
+crypto-caam-use-print_hex_dump_devel-to-guard-key-hex-dumps.patch
+crypto-caam-use-print_hex_dump_devel-to-guard-key-hex-dumps-again.patch
+crypto-ecc-fix-carry-overflow-in-vli-multiplication.patch
+crypto-pcrypt-restore-callback-for-non-parallel-fallback.patch
+crypto-tegra-fix-refcount-leak-in-tegra_se_host1x_submit.patch
+crypto-ccp-do-not-initialize-snp-for-sev-ioctls.patch
+crypto-ccp-do-not-initialize-snp-for-ioctl-snp_commit.patch
+crypto-ccp-do-not-initialize-snp-for-ioctl-snp_vlek_load.patch
+crypto-drbg-fix-returning-success-on-failure-in-ctr_drbg.patch
+crypto-drbg-fix-drbg_max_addtl-on-64-bit-kernels.patch
+crypto-drbg-fix-the-fips_enabled-priority-boost.patch
--- /dev/null
+From 5f0419457f89dce1a3f1c8e62a3adf2f39ab8168 Mon Sep 17 00:00:00 2001
+From: Michael Bommarito <michael.bommarito@gmail.com>
+Date: Fri, 15 May 2026 10:23:27 -0400
+Subject: udf: validate free block extents against the partition length
+
+From: Michael Bommarito <michael.bommarito@gmail.com>
+
+commit 5f0419457f89dce1a3f1c8e62a3adf2f39ab8168 upstream.
+
+udf_free_blocks() checks the logical block number and count against the
+partition length, but drops the extent offset from that final bound. A
+crafted extent can pass the guard while logicalBlockNum + offset + count
+points past the partition, which later indexes past the space bitmap
+array.
+
+A single ftruncate(2) on a file backed by such an extent reliably
+panics the kernel. This is a local availability issue. On desktop
+systems where UDisks/polkit allows the active user to mount removable
+UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply
+the crafted filesystem and trigger the panic by truncating a writable
+file on it. Systems that require root or CAP_SYS_ADMIN to mount the
+image have a higher prerequisite.
+
+No confidentiality or integrity impact is claimed: the reproduced
+primitive is an out-of-bounds read of a bitmap pointer slot followed by
+a kernel panic.
+
+Use the already computed logicalBlockNum + offset + count value for the
+partition length check. Also make load_block_bitmap() reject an
+out-of-range block group before indexing s_block_bitmap[], so corrupted
+callers cannot walk past the flexible array.
+
+Fixes: 56e69e59751d ("udf: prevent integer overflow in udf_bitmap_free_blocks()")
+Cc: stable@vger.kernel.org
+Assisted-by: Claude:claude-opus-4-7
+Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
+Link: https://patch.msgid.link/20260515142327.1120767-1-michael.bommarito@gmail.com
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/udf/balloc.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/fs/udf/balloc.c
++++ b/fs/udf/balloc.c
+@@ -82,8 +82,9 @@ static int load_block_bitmap(struct supe
+ int nr_groups = bitmap->s_nr_groups;
+
+ if (block_group >= nr_groups) {
+- udf_debug("block_group (%u) > nr_groups (%d)\n",
++ udf_debug("block_group (%u) >= nr_groups (%d)\n",
+ block_group, nr_groups);
++ return -EFSCORRUPTED;
+ }
+
+ if (bitmap->s_block_bitmap[block_group]) {
+@@ -662,7 +663,7 @@ void udf_free_blocks(struct super_block
+
+ if (check_add_overflow(bloc->logicalBlockNum, offset, &blk) ||
+ check_add_overflow(blk, count, &blk) ||
+- bloc->logicalBlockNum + count > map->s_partition_len) {
++ blk > map->s_partition_len) {
+ udf_debug("Invalid request to free blocks: (%d, %u), off %u, "
+ "len %u, partition len %u\n",
+ partition, bloc->logicalBlockNum, offset, count,
--- /dev/null
+From 3ec997bd5508e9b25210b5bbec89031629cdb093 Mon Sep 17 00:00:00 2001
+From: Bryam Vargas <hexlabsecurity@proton.me>
+Date: Fri, 12 Jun 2026 01:40:01 -0500
+Subject: udf: validate sparing table length as an entry count, not a byte count
+
+From: Bryam Vargas <hexlabsecurity@proton.me>
+
+commit 3ec997bd5508e9b25210b5bbec89031629cdb093 upstream.
+
+udf_load_sparable_map() accepts a sparing table when
+
+ sizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize
+
+is false, i.e. it treats reallocationTableLen as a number of BYTES that
+must fit in the block. But the table is walked as an array of 8-byte
+sparingEntry elements:
+
+ for (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) {
+ struct sparingEntry *entry = &st->mapEntry[i];
+ ... entry->origLocation ...
+ }
+
+in udf_get_pblock_spar15() and udf_relocate_blocks(). A
+reallocationTableLen of N therefore passes the check whenever
+sizeof(*st) + N <= blocksize, yet the consumers index
+sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the
+block. On a crafted UDF image this is an out-of-bounds read in
+udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the
+same length to udf_update_tag(), whose crc_itu_t() reads far past the
+block, and its memmove() through st->mapEntry[] is an out-of-bounds
+write.
+
+Validate reallocationTableLen as the entry count it is, with
+struct_size().
+
+Fixes: 1df2ae31c724 ("udf: Fortify loading of sparing table")
+Cc: stable@vger.kernel.org
+Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
+Link: https://patch.msgid.link/20260612-b4-disp-91780c4e-v1-1-f15112ff6882@proton.me
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/udf/super.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/udf/super.c
++++ b/fs/udf/super.c
+@@ -1426,7 +1426,8 @@ static int udf_load_sparable_map(struct
+ if (ident != 0 ||
+ strncmp(st->sparingIdent.ident, UDF_ID_SPARING,
+ strlen(UDF_ID_SPARING)) ||
+- sizeof(*st) + le16_to_cpu(st->reallocationTableLen) >
++ struct_size(st, mapEntry,
++ le16_to_cpu(st->reallocationTableLen)) >
+ sb->s_blocksize) {
+ brelse(bh);
+ continue;
--- /dev/null
+From d8202786b3d75125c84ebc4de6d946f92fde0ee8 Mon Sep 17 00:00:00 2001
+From: Bryam Vargas <hexlabsecurity@proton.me>
+Date: Fri, 12 Jun 2026 02:53:31 -0500
+Subject: udf: validate VAT header length against the VAT inode size
+
+From: Bryam Vargas <hexlabsecurity@proton.me>
+
+commit d8202786b3d75125c84ebc4de6d946f92fde0ee8 upstream.
+
+udf_load_vat() takes the virtual partition's start offset straight from
+the on-disk VAT 2.0 header without checking it against the VAT inode
+size:
+
+ map->s_type_specific.s_virtual.s_start_offset =
+ le16_to_cpu(vat20->lengthHeader);
+ map->s_type_specific.s_virtual.s_num_entries =
+ (sbi->s_vat_inode->i_size -
+ map->s_type_specific.s_virtual.s_start_offset) >> 2;
+
+lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds
+the VAT inode size, the s_num_entries subtraction underflows to a huge
+count, which defeats the "block > s_num_entries" bound in
+udf_get_pblock_virt15(); and on the ICB-inline path that function reads
+
+ ((__le32 *)(iinfo->i_data + s_start_offset))[block]
+
+so a large s_start_offset indexes past the inode's in-ICB data. Mounting
+a crafted UDF image with a virtual (VAT) partition then triggers an
+out-of-bounds read.
+
+Reject a VAT whose header length does not leave room for at least one
+entry within the VAT inode.
+
+Fixes: fa5e08156335 ("udf: Handle VAT packed inside inode properly")
+Cc: stable@vger.kernel.org
+Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
+Link: https://patch.msgid.link/20260612-b4-disp-9a2317ee-v1-1-fefef5736154@proton.me
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/udf/super.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/fs/udf/super.c
++++ b/fs/udf/super.c
+@@ -1263,6 +1263,14 @@ static int udf_load_vat(struct super_blo
+
+ map->s_type_specific.s_virtual.s_start_offset =
+ le16_to_cpu(vat20->lengthHeader);
++ if (map->s_type_specific.s_virtual.s_start_offset
++ > sbi->s_vat_inode->i_size) {
++ udf_err(sb, "Corrupted VAT header length %u (VAT inode size %lld)\n",
++ map->s_type_specific.s_virtual.s_start_offset,
++ sbi->s_vat_inode->i_size);
++ brelse(bh);
++ return -EFSCORRUPTED;
++ }
+ map->s_type_specific.s_virtual.s_num_entries =
+ (sbi->s_vat_inode->i_size -
+ map->s_type_specific.s_virtual.
projects / thirdparty / kernel / stable-queue.git / commitdiff
