From: Greg Kroah-Hartman Date: Tue, 12 May 2026 14:11:28 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v6.12.88~38 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4b4c7c4cd7c3ac23697b273924e74d48b97e464e;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: asoc-fsl_easrc-fix-comment-typo.patch asoc-intel-bytcr_wm5102-fix-mclk-leak-on-platform_clock_control-error.patch dm-don-t-report-warning-when-doing-deferred-remove.patch dm-fix-a-buffer-overflow-in-ioctl-processing.patch dm-thin-fix-metadata-refcount-underflow.patch dm-verity-fec-correctly-reject-too-small-fec-devices.patch dm-verity-fec-correctly-reject-too-small-hash-devices.patch isofs-validate-block-number-from-nfs-file-handle-in-isofs_export_iget.patch isofs-validate-rock-ridge-ce-continuation-extent-against-volume-size.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 --- diff --git a/queue-5.15/asoc-fsl_easrc-fix-comment-typo.patch b/queue-5.15/asoc-fsl_easrc-fix-comment-typo.patch new file mode 100644 index 0000000000..51596540db --- /dev/null +++ b/queue-5.15/asoc-fsl_easrc-fix-comment-typo.patch @@ -0,0 +1,38 @@ +From 804dce6c73fdfa44184ee4e8b09abad7f5da408f Mon Sep 17 00:00:00 2001 +From: Joseph Salisbury +Date: Mon, 16 Mar 2026 14:05:45 -0400 +Subject: ASoC: fsl_easrc: fix comment typo + +From: Joseph Salisbury + +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 +Link: https://patch.msgid.link/20260316180545.144032-1-joseph.salisbury@oracle.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + 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) + { diff --git a/queue-5.15/asoc-intel-bytcr_wm5102-fix-mclk-leak-on-platform_clock_control-error.patch b/queue-5.15/asoc-intel-bytcr_wm5102-fix-mclk-leak-on-platform_clock_control-error.patch new file mode 100644 index 0000000000..506e644768 --- /dev/null +++ b/queue-5.15/asoc-intel-bytcr_wm5102-fix-mclk-leak-on-platform_clock_control-error.patch @@ -0,0 +1,42 @@ +From 13d30682e8dee191ac04e93642f0372a723e8b0c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?C=C3=A1ssio=20Gabriel?= +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 + +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 +Reviewed-by: Cezary Rojewski +Reviewed-by: Hans de Goede +Link: https://patch.msgid.link/20260427-bytcr-wm5102-mclk-leak-v1-1-02b96d08e99c@gmail.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + 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 { diff --git a/queue-5.15/dm-don-t-report-warning-when-doing-deferred-remove.patch b/queue-5.15/dm-don-t-report-warning-when-doing-deferred-remove.patch new file mode 100644 index 0000000000..6ae62a1a9a --- /dev/null +++ b/queue-5.15/dm-don-t-report-warning-when-doing-deferred-remove.patch @@ -0,0 +1,35 @@ +From b7cce3e2cca9cd78418f3c3784474b778e7996fe Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Mon, 16 Mar 2026 15:04:15 +0100 +Subject: dm: don't report warning when doing deferred remove + +From: Mikulas Patocka + +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 +Reported-by: Zdenek Kabelac +Cc: stable@vger.kernel.org +Fixes: 2c140a246dc0 ("dm: allow remove to be deferred") +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + diff --git a/queue-5.15/dm-fix-a-buffer-overflow-in-ioctl-processing.patch b/queue-5.15/dm-fix-a-buffer-overflow-in-ioctl-processing.patch new file mode 100644 index 0000000000..ed58d36145 --- /dev/null +++ b/queue-5.15/dm-fix-a-buffer-overflow-in-ioctl-processing.patch @@ -0,0 +1,55 @@ +From 2fa49cc884f6496a915c35621ba4da35649bf159 Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Thu, 9 Apr 2026 17:49:58 +0200 +Subject: dm: fix a buffer overflow in ioctl processing + +From: Mikulas Patocka + +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 +Signed-off-by: Mikulas Patocka +Reviewed-by: Bryn M. Reeves +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-5.15/dm-thin-fix-metadata-refcount-underflow.patch b/queue-5.15/dm-thin-fix-metadata-refcount-underflow.patch new file mode 100644 index 0000000000..c7efbe04d2 --- /dev/null +++ b/queue-5.15/dm-thin-fix-metadata-refcount-underflow.patch @@ -0,0 +1,55 @@ +From 09a65adc7d8bbfce06392cb6d375468e2728ead5 Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Mon, 20 Apr 2026 19:56:44 +0200 +Subject: dm-thin: fix metadata refcount underflow + +From: Mikulas Patocka + +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 +Fixes: 3241b1d3e0aa ("dm: add persistent data library") +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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))); + diff --git a/queue-5.15/dm-verity-fec-correctly-reject-too-small-fec-devices.patch b/queue-5.15/dm-verity-fec-correctly-reject-too-small-fec-devices.patch new file mode 100644 index 0000000000..a90538b834 --- /dev/null +++ b/queue-5.15/dm-verity-fec-correctly-reject-too-small-fec-devices.patch @@ -0,0 +1,48 @@ +From 2b14e0bb63cc671120e7791658f5c494fc66d072 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Thu, 5 Feb 2026 20:59:20 -0800 +Subject: dm-verity-fec: correctly reject too-small FEC devices + +From: Eric Biggers + +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 +Signed-off-by: Mikulas Patocka +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.15/dm-verity-fec-correctly-reject-too-small-hash-devices.patch b/queue-5.15/dm-verity-fec-correctly-reject-too-small-hash-devices.patch new file mode 100644 index 0000000000..2ffa18ac36 --- /dev/null +++ b/queue-5.15/dm-verity-fec-correctly-reject-too-small-hash-devices.patch @@ -0,0 +1,40 @@ +From 4355142245f7e55336dcc005ec03592df4d546f8 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Thu, 5 Feb 2026 20:59:21 -0800 +Subject: dm-verity-fec: correctly reject too-small hash devices + +From: Eric Biggers + +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 +Signed-off-by: Mikulas Patocka +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.15/isofs-validate-block-number-from-nfs-file-handle-in-isofs_export_iget.patch b/queue-5.15/isofs-validate-block-number-from-nfs-file-handle-in-isofs_export_iget.patch new file mode 100644 index 0000000000..3b3dcfeb02 --- /dev/null +++ b/queue-5.15/isofs-validate-block-number-from-nfs-file-handle-in-isofs_export_iget.patch @@ -0,0 +1,54 @@ +From 24376458138387fb251e782e624c7776e9826796 Mon Sep 17 00:00:00 2001 +From: Michael Bommarito +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 + +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 +Link: https://patch.msgid.link/20260419212155.2169382-3-michael.bommarito@gmail.com +Signed-off-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman +--- + 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)) diff --git a/queue-5.15/isofs-validate-rock-ridge-ce-continuation-extent-against-volume-size.patch b/queue-5.15/isofs-validate-rock-ridge-ce-continuation-extent-against-volume-size.patch new file mode 100644 index 0000000000..f696df19f5 --- /dev/null +++ b/queue-5.15/isofs-validate-rock-ridge-ce-continuation-extent-against-volume-size.patch @@ -0,0 +1,64 @@ +From a36d990f591320e9dd379ab30063ebfe91d47e1f Mon Sep 17 00:00:00 2001 +From: Michael Bommarito +Date: Sun, 19 Apr 2026 17:21:54 -0400 +Subject: isofs: validate Rock Ridge CE continuation extent against volume size + +From: Michael Bommarito + +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 +Link: https://patch.msgid.link/20260419212155.2169382-2-michael.bommarito@gmail.com +Signed-off-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-5.15/libceph-fix-slab-out-of-bounds-access-in-auth-message-processing.patch b/queue-5.15/libceph-fix-slab-out-of-bounds-access-in-auth-message-processing.patch new file mode 100644 index 0000000000..0c72a02912 --- /dev/null +++ b/queue-5.15/libceph-fix-slab-out-of-bounds-access-in-auth-message-processing.patch @@ -0,0 +1,59 @@ +From 1c439de70b1c3eb3c6bffa8245c16b9fc318f114 Mon Sep 17 00:00:00 2001 +From: Raphael Zimmer +Date: Tue, 21 Apr 2026 10:27:01 +0200 +Subject: libceph: Fix slab-out-of-bounds access in auth message processing + +From: Raphael Zimmer + +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 +Reviewed-by: Ilya Dryomov +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.15/md-raid10-fix-divide-by-zero-in-setup_geo-with-zero-far_copies.patch b/queue-5.15/md-raid10-fix-divide-by-zero-in-setup_geo-with-zero-far_copies.patch new file mode 100644 index 0000000000..887f551454 --- /dev/null +++ b/queue-5.15/md-raid10-fix-divide-by-zero-in-setup_geo-with-zero-far_copies.patch @@ -0,0 +1,38 @@ +From 9aa6d860b0930e2f72795665c42c44252a558a0c Mon Sep 17 00:00:00 2001 +From: Junrui Luo +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 + +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 +Link: https://lore.kernel.org/linux-raid/SYBPR01MB7881A5E2556806CC1D318582AF232@SYBPR01MB7881.ausprd01.prod.outlook.com +Signed-off-by: Yu Kuai +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.15/nvmet-avoid-recursive-nvmet-wq-flush-in-nvmet_ctrl_free.patch b/queue-5.15/nvmet-avoid-recursive-nvmet-wq-flush-in-nvmet_ctrl_free.patch new file mode 100644 index 0000000000..90c3281497 --- /dev/null +++ b/queue-5.15/nvmet-avoid-recursive-nvmet-wq-flush-in-nvmet_ctrl_free.patch @@ -0,0 +1,137 @@ +From aade8abd8b868b6ffa9697aadaea28ec7f65bee6 Mon Sep 17 00:00:00 2001 +From: Chaitanya Kulkarni +Date: Wed, 8 Apr 2026 17:56:47 -0700 +Subject: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free + +From: Chaitanya Kulkarni + +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] +[ 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] + +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 +Signed-off-by: Chaitanya Kulkarni +Signed-off-by: Keith Busch +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.15/rdma-hns-fix-unlocked-call-to-hns_roce_qp_remove.patch b/queue-5.15/rdma-hns-fix-unlocked-call-to-hns_roce_qp_remove.patch new file mode 100644 index 0000000000..bc84822f5c --- /dev/null +++ b/queue-5.15/rdma-hns-fix-unlocked-call-to-hns_roce_qp_remove.patch @@ -0,0 +1,50 @@ +From 0c99acbc8b6c6dd526ae475a48ee1897b61072fb Mon Sep 17 00:00:00 2001 +From: Jason Gunthorpe +Date: Tue, 28 Apr 2026 13:17:48 -0300 +Subject: RDMA/hns: Fix unlocked call to hns_roce_qp_remove() + +From: Jason Gunthorpe + +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 +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + 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: diff --git a/queue-5.15/s390-debug-reject-zero-length-input-in-debug_input_flush_fn.patch b/queue-5.15/s390-debug-reject-zero-length-input-in-debug_input_flush_fn.patch new file mode 100644 index 0000000000..cad24860c5 --- /dev/null +++ b/queue-5.15/s390-debug-reject-zero-length-input-in-debug_input_flush_fn.patch @@ -0,0 +1,40 @@ +From e14622a7584f9608927c59a7d6ae4a0999dc545e Mon Sep 17 00:00:00 2001 +From: Vasily Gorbik +Date: Fri, 17 Apr 2026 14:33:43 +0200 +Subject: s390/debug: Reject zero-length input in debug_input_flush_fn() + +From: Vasily Gorbik + +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 +Signed-off-by: Vasily Gorbik +Signed-off-by: Alexander Gordeev +Signed-off-by: Greg Kroah-Hartman +--- + 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) { diff --git a/queue-5.15/series b/queue-5.15/series index 5b2d563bb0..cacfd3bac4 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -331,3 +331,17 @@ thermal-drivers-sprd-fix-temperature-clamping-in-sprd_thm_temp_to_rawdata.patch 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