--- /dev/null
+From 804dce6c73fdfa44184ee4e8b09abad7f5da408f Mon Sep 17 00:00:00 2001
+From: Joseph Salisbury <joseph.salisbury@oracle.com>
+Date: Mon, 16 Mar 2026 14:05:45 -0400
+Subject: ASoC: fsl_easrc: fix comment typo
+
+From: Joseph Salisbury <joseph.salisbury@oracle.com>
+
+commit 804dce6c73fdfa44184ee4e8b09abad7f5da408f upstream.
+
+The file contains a spelling error in a source comment (funciton).
+
+Typos in comments reduce readability and make text searches less reliable
+for developers and maintainers.
+
+Replace 'funciton' with 'function' in the affected comment. This is a
+comment-only cleanup and does not change behavior.
+
+Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers")
+Cc: stable@vger.kernel.org
+Signed-off-by: Joseph Salisbury <joseph.salisbury@oracle.com>
+Link: https://patch.msgid.link/20260316180545.144032-1-joseph.salisbury@oracle.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/fsl/fsl_easrc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/soc/fsl/fsl_easrc.c
++++ b/sound/soc/fsl/fsl_easrc.c
+@@ -1286,7 +1286,7 @@ static int fsl_easrc_request_context(int
+ /*
+ * Release the context
+ *
+- * This funciton is mainly doing the revert thing in request context
++ * This function is mainly doing the revert thing in request context
+ */
+ static void fsl_easrc_release_context(struct fsl_asrc_pair *ctx)
+ {
--- /dev/null
+From 13d30682e8dee191ac04e93642f0372a723e8b0c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?C=C3=A1ssio=20Gabriel?= <cassiogabrielcontato@gmail.com>
+Date: Mon, 27 Apr 2026 23:38:41 -0300
+Subject: ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+
+commit 13d30682e8dee191ac04e93642f0372a723e8b0c upstream.
+
+If byt_wm5102_prepare_and_enable_pll1() fails in the
+SND_SOC_DAPM_EVENT_ON() path, platform_clock_control() returns after
+clk_prepare_enable(priv->mclk) without disabling the clock again.
+
+This leaks an MCLK enable reference on failed power-up attempts. Add the
+missing clk_disable_unprepare() on the error path, matching the unwind
+used by the other Intel platform_clock_control() implementations.
+
+Fixes: 9a87fc1e0619 ("ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102")
+Cc: stable@vger.kernel.org
+Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
+Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
+Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260427-bytcr-wm5102-mclk-leak-v1-1-02b96d08e99c@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/intel/boards/bytcr_wm5102.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/soc/intel/boards/bytcr_wm5102.c
++++ b/sound/soc/intel/boards/bytcr_wm5102.c
+@@ -111,6 +111,7 @@ static int platform_clock_control(struct
+ ret = byt_wm5102_prepare_and_enable_pll1(codec_dai, 48000);
+ if (ret) {
+ dev_err(card->dev, "Error setting codec sysclk: %d\n", ret);
++ clk_disable_unprepare(priv->mclk);
+ return ret;
+ }
+ } else {
--- /dev/null
+From b7cce3e2cca9cd78418f3c3784474b778e7996fe Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 16 Mar 2026 15:04:15 +0100
+Subject: dm: don't report warning when doing deferred remove
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit b7cce3e2cca9cd78418f3c3784474b778e7996fe upstream.
+
+If dm_hash_remove_all was called from dm_deferred_remove, it would write
+a warning "remove_all left %d open device(s)" if there are some other
+devices active.
+
+The warning is bogus, so let's disable it in this case.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 2c140a246dc0 ("dm: allow remove to be deferred")
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-ioctl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/dm-ioctl.c
++++ b/drivers/md/dm-ioctl.c
+@@ -367,7 +367,7 @@ retry:
+
+ up_write(&_hash_lock);
+
+- if (dev_skipped)
++ if (dev_skipped && !only_deferred)
+ DMWARN("remove_all left %d open device(s)", dev_skipped);
+ }
+
--- /dev/null
+From 2fa49cc884f6496a915c35621ba4da35649bf159 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Thu, 9 Apr 2026 17:49:58 +0200
+Subject: dm: fix a buffer overflow in ioctl processing
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 2fa49cc884f6496a915c35621ba4da35649bf159 upstream.
+
+Tony Asleson (using Claude) found a buffer overflow in dm-ioctl in the
+function retrieve_status:
+
+1. The code in retrieve_status checks that the output string fits into
+ the output buffer and writes the output string there
+2. Then, the code aligns the "outptr" variable to the next 8-byte
+ boundary:
+ outptr = align_ptr(outptr);
+3. The alignment doesn't check overflow, so outptr could point past the
+ buffer end
+4. The "for" loop is iterated again, it executes:
+ remaining = len - (outptr - outbuf);
+5. If "outptr" points past "outbuf + len", the arithmetics wraps around
+ and the variable "remaining" contains unusually high number
+6. With "remaining" being high, the code writes more data past the end of
+ the buffer
+
+Luckily, this bug has no security implications because:
+1. Only root can issue device mapper ioctls
+2. The commonly used libraries that communicate with device mapper
+ (libdevmapper and devicemapper-rs) use buffer size that is aligned to
+ 8 bytes - thus, "outptr = align_ptr(outptr)" can't overshoot the input
+ buffer and the bug can't happen accidentally
+
+Reported-by: Tony Asleson <tasleson@redhat.com>
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Reviewed-by: Bryn M. Reeves <bmr@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-ioctl.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/md/dm-ioctl.c
++++ b/drivers/md/dm-ioctl.c
+@@ -1311,6 +1311,10 @@ static void retrieve_status(struct dm_ta
+ used = param->data_start + (outptr - outbuf);
+
+ outptr = align_ptr(outptr);
++ if (!outptr || outptr > outbuf + len) {
++ param->flags |= DM_BUFFER_FULL_FLAG;
++ break;
++ }
+ spec->next = outptr - outbuf;
+ }
+
--- /dev/null
+From 09a65adc7d8bbfce06392cb6d375468e2728ead5 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 20 Apr 2026 19:56:44 +0200
+Subject: dm-thin: fix metadata refcount underflow
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 09a65adc7d8bbfce06392cb6d375468e2728ead5 upstream.
+
+There's a bug in dm-thin in the function rebalance_children. If the
+internal btree node has one entry, the code tries to copy all btree
+entries from the node's child to the node itself and then decrement the
+child's reference count.
+
+If the child node is shared (it has reference count > 1), we won't free
+it, so there would be two pointers to each of the grandchildren nodes.
+But the reference counts of the grandchildren is not increased, thus the
+reference count doesn't match the number of pointers that point to the
+grandchildren. This results in "device mapper: space map common: unable
+to decrement block" errors.
+
+Fix this bug by incrementing reference counts on the grandchildren if the
+btree node is shared.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Fixes: 3241b1d3e0aa ("dm: add persistent data library")
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/persistent-data/dm-btree-remove.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/md/persistent-data/dm-btree-remove.c
++++ b/drivers/md/persistent-data/dm-btree-remove.c
+@@ -415,12 +415,20 @@ static int rebalance_children(struct sha
+
+ if (le32_to_cpu(n->header.nr_entries) == 1) {
+ struct dm_block *child;
++ int is_shared;
+ dm_block_t b = value64(n, 0);
+
++ r = dm_tm_block_is_shared(info->tm, b, &is_shared);
++ if (r)
++ return r;
++
+ r = dm_tm_read_lock(info->tm, b, &btree_node_validator, &child);
+ if (r)
+ return r;
+
++ if (is_shared)
++ inc_children(info->tm, dm_block_data(child), vt);
++
+ memcpy(n, dm_block_data(child),
+ dm_bm_block_size(dm_tm_get_bm(info->tm)));
+
--- /dev/null
+From 2b14e0bb63cc671120e7791658f5c494fc66d072 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@kernel.org>
+Date: Thu, 5 Feb 2026 20:59:20 -0800
+Subject: dm-verity-fec: correctly reject too-small FEC devices
+
+From: Eric Biggers <ebiggers@kernel.org>
+
+commit 2b14e0bb63cc671120e7791658f5c494fc66d072 upstream.
+
+Fix verity_fec_ctr() to reject too-small FEC devices by correctly
+computing the number of parity blocks as 'f->rounds * f->roots'.
+Previously it incorrectly used 'div64_u64(f->rounds * f->roots,
+v->fec->roots << SECTOR_SHIFT)' which is a much smaller value.
+
+Note that the units of 'rounds' are blocks, not bytes. This matches the
+units of the value returned by dm_bufio_get_device_size(), which are
+also blocks. A later commit will give 'rounds' a clearer name.
+
+Fixes: a739ff3f543a ("dm verity: add support for forward error correction")
+Cc: stable@vger.kernel.org
+Signed-off-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-verity-fec.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/md/dm-verity-fec.c
++++ b/drivers/md/dm-verity-fec.c
+@@ -668,7 +668,7 @@ int verity_fec_ctr(struct dm_verity *v)
+ {
+ struct dm_verity_fec *f = v->fec;
+ struct dm_target *ti = v->ti;
+- u64 hash_blocks, fec_blocks;
++ u64 hash_blocks;
+ int ret;
+
+ if (!verity_fec_is_enabled(v)) {
+@@ -752,8 +752,7 @@ int verity_fec_ctr(struct dm_verity *v)
+
+ dm_bufio_set_sector_offset(f->bufio, f->start << (v->data_dev_block_bits - SECTOR_SHIFT));
+
+- fec_blocks = div64_u64(f->rounds * f->roots, v->fec->roots << SECTOR_SHIFT);
+- if (dm_bufio_get_device_size(f->bufio) < fec_blocks) {
++ if (dm_bufio_get_device_size(f->bufio) < f->rounds * f->roots) {
+ ti->error = "FEC device is too small";
+ return -E2BIG;
+ }
--- /dev/null
+From 4355142245f7e55336dcc005ec03592df4d546f8 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@kernel.org>
+Date: Thu, 5 Feb 2026 20:59:21 -0800
+Subject: dm-verity-fec: correctly reject too-small hash devices
+
+From: Eric Biggers <ebiggers@kernel.org>
+
+commit 4355142245f7e55336dcc005ec03592df4d546f8 upstream.
+
+Fix verity_fec_ctr() to reject too-small hash devices by correctly
+taking hash_start into account.
+
+Note that this is necessary because dm-verity doesn't call
+dm_bufio_set_sector_offset() on the hash device's bufio client
+(v->bufio). Thus, dm_bufio_get_device_size(v->bufio) returns a size
+relative to 0 rather than hash_start. An alternative fix would be to
+call dm_bufio_set_sector_offset() on v->bufio, but then all the code
+that reads from the hash device would have to be adjusted accordingly.
+
+Fixes: a739ff3f543a ("dm verity: add support for forward error correction")
+Cc: stable@vger.kernel.org
+Signed-off-by: Eric Biggers <ebiggers@kernel.org>
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-verity-fec.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm-verity-fec.c
++++ b/drivers/md/dm-verity-fec.c
+@@ -731,7 +731,8 @@ int verity_fec_ctr(struct dm_verity *v)
+ * it to be large enough.
+ */
+ f->hash_blocks = f->blocks - v->data_blocks;
+- if (dm_bufio_get_device_size(v->bufio) < f->hash_blocks) {
++ if (dm_bufio_get_device_size(v->bufio) <
++ v->hash_start + f->hash_blocks) {
+ ti->error = "Hash device is too small for "
+ DM_VERITY_OPT_FEC_BLOCKS;
+ return -E2BIG;
--- /dev/null
+From 24376458138387fb251e782e624c7776e9826796 Mon Sep 17 00:00:00 2001
+From: Michael Bommarito <michael.bommarito@gmail.com>
+Date: Sun, 19 Apr 2026 17:21:55 -0400
+Subject: isofs: validate block number from NFS file handle in isofs_export_iget
+
+From: Michael Bommarito <michael.bommarito@gmail.com>
+
+commit 24376458138387fb251e782e624c7776e9826796 upstream.
+
+isofs_fh_to_dentry() and isofs_fh_to_parent() pass an attacker-
+controlled block number (ifid->block or ifid->parent_block) from
+the NFS file handle to isofs_export_iget(), which only rejects
+block == 0 before calling isofs_iget() and ultimately sb_bread().
+A crafted file handle with fh_len sufficient to pass the check
+added by commit 0405d4b63d08 ("isofs: Prevent the use of too small
+fid") can still drive the server to read any in-range block on the
+backing device as if it were an iso_directory_record. That earlier
+fix was assigned CVE-2025-37780.
+
+sb_bread() on an out-of-range block returns NULL cleanly via the
+EIO path, so there is no memory-safety violation. For in-range
+reads of adjacent-partition data on the same block device, the
+unrelated bytes end up in iso_inode_info fields that reach the NFS
+client as dentry metadata. The deployment surface (isofs exported
+over NFS from loop-mounted images) is narrow and requires an
+authenticated NFS peer, but the malformed-file-handle class is
+reportable as hardening next to the existing CVE-2025-37780 fix.
+
+Reject block >= ISOFS_SB(sb)->s_nzones in isofs_export_iget() so
+the check covers both isofs_fh_to_dentry() and isofs_fh_to_parent()
+call sites with a single line.
+
+Fixes: 0405d4b63d08 ("isofs: Prevent the use of too small fid")
+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/20260419212155.2169382-3-michael.bommarito@gmail.com
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/isofs/export.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/isofs/export.c
++++ b/fs/isofs/export.c
+@@ -24,7 +24,7 @@ isofs_export_iget(struct super_block *sb
+ {
+ struct inode *inode;
+
+- if (block == 0)
++ if (block == 0 || block >= ISOFS_SB(sb)->s_nzones)
+ return ERR_PTR(-ESTALE);
+ inode = isofs_iget(sb, block, offset);
+ if (IS_ERR(inode))
--- /dev/null
+From a36d990f591320e9dd379ab30063ebfe91d47e1f Mon Sep 17 00:00:00 2001
+From: Michael Bommarito <michael.bommarito@gmail.com>
+Date: Sun, 19 Apr 2026 17:21:54 -0400
+Subject: isofs: validate Rock Ridge CE continuation extent against volume size
+
+From: Michael Bommarito <michael.bommarito@gmail.com>
+
+commit a36d990f591320e9dd379ab30063ebfe91d47e1f upstream.
+
+rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE
+record and passes it to sb_bread() without checking that the block
+number is within the mounted ISO 9660 volume. commit e595447e177b
+("[PATCH] rock.c: handle corrupted directories") added cont_offset
+and cont_size rejection for the CE continuation but did not validate
+the extent block number itself. commit f54e18f1b831 ("isofs: Fix
+infinite looping over CE entries") later capped the CE chain length
+at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked.
+
+With a crafted ISO mounted via udisks2 (desktop optical auto-mount)
+or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at
+an out-of-range block or at blocks belonging to an adjacent
+filesystem on the same block device. sb_bread() on an out-of-range
+block returns NULL cleanly via the block layer EIO path, so there
+is no memory-safety violation. For in-range reads of adjacent-
+filesystem data, the CE buffer is parsed as Rock Ridge records and
+only the text of SL sub-records reaches userspace through
+readlink(), which makes the info-leak channel narrow and difficult
+to exploit; still, rejecting the malformed CE outright matches the
+rejection shape already present in the same function for
+cont_offset and cont_size.
+
+Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next
+to the existing offset/size rejection, printing the same
+corrupted-directory-entry notice.
+
+Fixes: f54e18f1b831 ("isofs: Fix infinite looping over CE entries")
+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/20260419212155.2169382-2-michael.bommarito@gmail.com
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/isofs/rock.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/isofs/rock.c
++++ b/fs/isofs/rock.c
+@@ -101,6 +101,15 @@ static int rock_continue(struct rock_sta
+ goto out;
+ }
+
++ if ((unsigned)rs->cont_extent >= ISOFS_SB(rs->inode->i_sb)->s_nzones) {
++ printk(KERN_NOTICE "rock: corrupted directory entry. "
++ "extent=%u out of volume (nzones=%lu)\n",
++ (unsigned)rs->cont_extent,
++ ISOFS_SB(rs->inode->i_sb)->s_nzones);
++ ret = -EIO;
++ goto out;
++ }
++
+ if (rs->cont_extent) {
+ struct buffer_head *bh;
+
--- /dev/null
+From 1c439de70b1c3eb3c6bffa8245c16b9fc318f114 Mon Sep 17 00:00:00 2001
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Date: Tue, 21 Apr 2026 10:27:01 +0200
+Subject: libceph: Fix slab-out-of-bounds access in auth message processing
+
+From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+
+commit 1c439de70b1c3eb3c6bffa8245c16b9fc318f114 upstream.
+
+If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY
+contains a positive value in its result field, it is treated as an
+error code by ceph_handle_auth_reply() and returned to
+handle_auth_reply(). Thereafter, an attempt is made to send the
+preallocated message of type CEPH_MSG_AUTH, where the returned value is
+interpreted as the size of the front segment to send. If the result
+value in the message is greater than the size of the memory buffer
+allocated for the front segment, an out-of-bounds access occurs, and
+the content of the memory region beyond this buffer is sent out.
+
+This patch fixes the issue by treating only negative values in the
+result field as errors. Positive values are therefore treated as success
+in the same way as a zero value. Additionally, a BUG_ON is added to
+__send_prepared_auth_request() comparing the len parameter to
+front_alloc_len to prevent sending the message if it exceeds the bounds
+of the allocation and to make it easier to catch any logic flaws leading
+to this.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/auth.c | 2 +-
+ net/ceph/mon_client.c | 2 ++
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+--- a/net/ceph/auth.c
++++ b/net/ceph/auth.c
+@@ -257,7 +257,7 @@ int ceph_handle_auth_reply(struct ceph_a
+ ac->negotiating = false;
+ }
+
+- if (result) {
++ if (result < 0) {
+ pr_err("auth protocol '%s' mauth authentication failed: %d\n",
+ ceph_auth_proto_name(ac->protocol), result);
+ ret = result;
+--- a/net/ceph/mon_client.c
++++ b/net/ceph/mon_client.c
+@@ -174,6 +174,8 @@ int ceph_monmap_contains(struct ceph_mon
+ */
+ static void __send_prepared_auth_request(struct ceph_mon_client *monc, int len)
+ {
++ BUG_ON(len > monc->m_auth->front_alloc_len);
++
+ monc->pending_auth = 1;
+ monc->m_auth->front.iov_len = len;
+ monc->m_auth->hdr.front_len = cpu_to_le32(len);
--- /dev/null
+From 9aa6d860b0930e2f72795665c42c44252a558a0c Mon Sep 17 00:00:00 2001
+From: Junrui Luo <moonafterrain@outlook.com>
+Date: Thu, 16 Apr 2026 11:39:56 +0800
+Subject: md/raid10: fix divide-by-zero in setup_geo() with zero far_copies
+
+From: Junrui Luo <moonafterrain@outlook.com>
+
+commit 9aa6d860b0930e2f72795665c42c44252a558a0c upstream.
+
+setup_geo() extracts near_copies (nc) and far_copies (fc) from the
+user-provided layout parameter without checking for zero. When fc=0
+with the "improved" far set layout selected, 'geo->far_set_size =
+disks / fc' triggers a divide-by-zero.
+
+Validate nc and fc immediately after extraction, returning -1 if
+either is zero.
+
+Fixes: 475901aff158 ("MD RAID10: Improve redundancy for 'far' and 'offset' algorithms (part 1)")
+Cc: stable@vger.kernel.org
+Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
+Link: https://lore.kernel.org/linux-raid/SYBPR01MB7881A5E2556806CC1D318582AF232@SYBPR01MB7881.ausprd01.prod.outlook.com
+Signed-off-by: Yu Kuai <yukuai@fnnas.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/raid10.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/md/raid10.c
++++ b/drivers/md/raid10.c
+@@ -4004,6 +4004,8 @@ static int setup_geo(struct geom *geo, s
+ nc = layout & 255;
+ fc = (layout >> 8) & 255;
+ fo = layout & (1<<16);
++ if (!nc || !fc)
++ return -1;
+ geo->raid_disks = disks;
+ geo->near_copies = nc;
+ geo->far_copies = fc;
--- /dev/null
+From aade8abd8b868b6ffa9697aadaea28ec7f65bee6 Mon Sep 17 00:00:00 2001
+From: Chaitanya Kulkarni <kch@nvidia.com>
+Date: Wed, 8 Apr 2026 17:56:47 -0700
+Subject: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free
+
+From: Chaitanya Kulkarni <kch@nvidia.com>
+
+commit aade8abd8b868b6ffa9697aadaea28ec7f65bee6 upstream.
+
+nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the
+final controller reference through nvmet_cq_put(). If that triggers
+nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on
+the same nvmet-wq.
+
+Call chain:
+
+ nvmet_tcp_schedule_release_queue()
+ kref_put(&queue->kref, nvmet_tcp_release_queue)
+ nvmet_tcp_release_queue()
+ queue_work(nvmet_wq, &queue->release_work) <--- nvmet_wq
+ process_one_work()
+ nvmet_tcp_release_queue_work()
+ nvmet_cq_put(&queue->nvme_cq)
+ nvmet_cq_destroy()
+ nvmet_ctrl_put(cq->ctrl)
+ nvmet_ctrl_free()
+ flush_work(&ctrl->async_event_work) <--- nvmet_wq
+
+ Previously Scheduled by :-
+ nvmet_add_async_event
+ queue_work(nvmet_wq, &ctrl->async_event_work);
+
+This trips lockdep with a possible recursive locking warning.
+
+[ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55
+[ 5223.061801] loop0: detected capacity change from 0 to 2097152
+[ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1
+[ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420)
+[ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349.
+[ 5223.128453] nvme nvme1: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349
+[ 5233.199447] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery"
+
+[ 5233.227718] ============================================
+[ 5233.231283] WARNING: possible recursive locking detected
+[ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N
+[ 5233.238434] --------------------------------------------
+[ 5233.241852] kworker/u192:6/2413 is trying to acquire lock:
+[ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90
+[ 5233.251438]
+ but task is already holding lock:
+[ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0
+[ 5233.261125]
+ other info that might help us debug this:
+[ 5233.265333] Possible unsafe locking scenario:
+
+[ 5233.269217] CPU0
+[ 5233.270795] ----
+[ 5233.272436] lock((wq_completion)nvmet-wq);
+[ 5233.275241] lock((wq_completion)nvmet-wq);
+[ 5233.278020]
+ *** DEADLOCK ***
+
+[ 5233.281793] May be due to missing lock nesting notation
+
+[ 5233.286195] 3 locks held by kworker/u192:6/2413:
+[ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0
+[ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0
+[ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530
+[ 5233.304290]
+ stack backtrace:
+[ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full)
+[ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST
+[ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
+[ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp]
+[ 5233.306532] Call Trace:
+[ 5233.306534] <TASK>
+[ 5233.306536] dump_stack_lvl+0x73/0xb0
+[ 5233.306552] print_deadlock_bug+0x225/0x2f0
+[ 5233.306556] __lock_acquire+0x13f0/0x2290
+[ 5233.306563] lock_acquire+0xd0/0x300
+[ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90
+[ 5233.306571] ? __flush_work+0x20b/0x530
+[ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90
+[ 5233.306577] touch_wq_lockdep_map+0x3b/0x90
+[ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90
+[ 5233.306583] ? __flush_work+0x20b/0x530
+[ 5233.306585] __flush_work+0x268/0x530
+[ 5233.306588] ? __pfx_wq_barrier_func+0x10/0x10
+[ 5233.306594] ? xen_error_entry+0x30/0x60
+[ 5233.306600] nvmet_ctrl_free+0x140/0x310 [nvmet]
+[ 5233.306617] nvmet_cq_put+0x74/0x90 [nvmet]
+[ 5233.306629] nvmet_tcp_release_queue_work+0x19f/0x360 [nvmet_tcp]
+[ 5233.306634] process_one_work+0x206/0x6e0
+[ 5233.306640] worker_thread+0x184/0x320
+[ 5233.306643] ? __pfx_worker_thread+0x10/0x10
+[ 5233.306646] kthread+0xf1/0x130
+[ 5233.306648] ? __pfx_kthread+0x10/0x10
+[ 5233.306651] ret_from_fork+0x355/0x450
+[ 5233.306653] ? __pfx_kthread+0x10/0x10
+[ 5233.306656] ret_from_fork_asm+0x1a/0x30
+[ 5233.306664] </TASK>
+
+There is also no need to flush async_event_work from controller
+teardown. The admin queue teardown already fails outstanding AER
+requests before the final controller put :-
+
+ nvmet_sq_destroy(admin sq)
+ nvmet_async_events_failall(ctrl)
+
+The controller has already been removed from the subsystem list before
+nvmet_ctrl_free() quiesces outstanding work.
+
+Replace flush_work() with cancel_work_sync() so a pending
+async_event_work item is canceled and a running instance is waited on
+without recursing into the same workqueue.
+
+Fixes: 06406d81a2d7 ("nvmet: cancel fatal error and flush async work before free controller")
+Cc: stable@vger.kernel.org
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/target/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/nvme/target/core.c
++++ b/drivers/nvme/target/core.c
+@@ -1471,7 +1471,7 @@ static void nvmet_ctrl_free(struct kref
+
+ nvmet_stop_keep_alive_timer(ctrl);
+
+- flush_work(&ctrl->async_event_work);
++ cancel_work_sync(&ctrl->async_event_work);
+ cancel_work_sync(&ctrl->fatal_err_work);
+
+ ida_simple_remove(&cntlid_ida, ctrl->cntlid);
--- /dev/null
+From 0c99acbc8b6c6dd526ae475a48ee1897b61072fb Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Tue, 28 Apr 2026 13:17:48 -0300
+Subject: RDMA/hns: Fix unlocked call to hns_roce_qp_remove()
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit 0c99acbc8b6c6dd526ae475a48ee1897b61072fb upstream.
+
+Sashiko points out that hns_roce_qp_remove() requires the caller to hold
+locks. The error flow in hns_roce_create_qp_common() doesn't hold those
+locks for the error unwind so it risks corrupting memory.
+
+Grab the same locks the other two callers use.
+
+Cc: stable@vger.kernel.org
+Fixes: e088a685eae9 ("RDMA/hns: Support rq record doorbell for the user space")
+Link: https://sashiko.dev/#/patchset/0-v2-1c49eeb88c48%2B91-rdma_udata_rep_jgg%40nvidia.com?part=9
+Link: https://patch.msgid.link/r/15-v1-41f3135e5565+9d2-rdma_ai_fixes1_jgg@nvidia.com
+Reviewed-by: Junxian Huang <huangjunxian6@hisilicon.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/hns/hns_roce_qp.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/infiniband/hw/hns/hns_roce_qp.c
++++ b/drivers/infiniband/hw/hns/hns_roce_qp.c
+@@ -1052,6 +1052,7 @@ static int hns_roce_create_qp_common(str
+ struct hns_roce_ib_create_qp_resp resp = {};
+ struct ib_device *ibdev = &hr_dev->ib_dev;
+ struct hns_roce_ib_create_qp ucmd = {};
++ unsigned long flags;
+ int ret;
+
+ mutex_init(&hr_qp->mutex);
+@@ -1135,7 +1136,13 @@ static int hns_roce_create_qp_common(str
+ return 0;
+
+ err_flow_ctrl:
++ spin_lock_irqsave(&hr_dev->qp_list_lock, flags);
++ hns_roce_lock_cqs(init_attr->send_cq ? to_hr_cq(init_attr->send_cq) : NULL,
++ init_attr->recv_cq ? to_hr_cq(init_attr->recv_cq) : NULL);
+ hns_roce_qp_remove(hr_dev, hr_qp);
++ hns_roce_unlock_cqs(init_attr->send_cq ? to_hr_cq(init_attr->send_cq) : NULL,
++ init_attr->recv_cq ? to_hr_cq(init_attr->recv_cq) : NULL);
++ spin_unlock_irqrestore(&hr_dev->qp_list_lock, flags);
+ err_store:
+ free_qpc(hr_dev, hr_qp);
+ err_qpc:
--- /dev/null
+From e14622a7584f9608927c59a7d6ae4a0999dc545e Mon Sep 17 00:00:00 2001
+From: Vasily Gorbik <gor@linux.ibm.com>
+Date: Fri, 17 Apr 2026 14:33:43 +0200
+Subject: s390/debug: Reject zero-length input in debug_input_flush_fn()
+
+From: Vasily Gorbik <gor@linux.ibm.com>
+
+commit e14622a7584f9608927c59a7d6ae4a0999dc545e upstream.
+
+debug_input_flush_fn() always copies one byte from the userspace buffer
+with copy_from_user() regardless of the supplied write length. A
+zero-length write therefore reads one byte beyond the caller's buffer.
+If the stale byte happens to be '-' or a digit the debug log is
+silently flushed. With an unmapped buffer the call returns -EFAULT.
+
+Reject zero-length writes before copying from userspace.
+
+Cc: stable@vger.kernel.org # v5.10+
+Acked-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/kernel/debug.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/arch/s390/kernel/debug.c
++++ b/arch/s390/kernel/debug.c
+@@ -1444,6 +1444,11 @@ static int debug_input_flush_fn(debug_in
+ char input_buf[1];
+ int rc = user_len;
+
++ if (!user_len) {
++ rc = -EINVAL;
++ goto out;
++ }
++
+ if (user_len > 0x10000)
+ user_len = 0x10000;
+ if (*offset != 0) {
thermal-drivers-sprd-fix-raw-temperature-clamping-in-sprd_thm_rawdata_to_temp.patch
spi-topcliff-pch-fix-use-after-free-on-unbind.patch
cpuidle-powerpc-avoid-double-clear-when-breaking-snooze.patch
+asoc-fsl_easrc-fix-comment-typo.patch
+asoc-intel-bytcr_wm5102-fix-mclk-leak-on-platform_clock_control-error.patch
+dm-thin-fix-metadata-refcount-underflow.patch
+dm-don-t-report-warning-when-doing-deferred-remove.patch
+dm-fix-a-buffer-overflow-in-ioctl-processing.patch
+dm-verity-fec-correctly-reject-too-small-fec-devices.patch
+dm-verity-fec-correctly-reject-too-small-hash-devices.patch
+isofs-validate-rock-ridge-ce-continuation-extent-against-volume-size.patch
+isofs-validate-block-number-from-nfs-file-handle-in-isofs_export_iget.patch
+libceph-fix-slab-out-of-bounds-access-in-auth-message-processing.patch
+md-raid10-fix-divide-by-zero-in-setup_geo-with-zero-far_copies.patch
+nvmet-avoid-recursive-nvmet-wq-flush-in-nvmet_ctrl_free.patch
+rdma-hns-fix-unlocked-call-to-hns_roce_qp_remove.patch
+s390-debug-reject-zero-length-input-in-debug_input_flush_fn.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
