From: Greg Kroah-Hartman Date: Tue, 12 May 2026 14:11:19 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v6.12.88~39 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f97f84d2d8304d8757c2626911fd3be10f9c44a9;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: asoc-fsl_easrc-fix-comment-typo.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-block-number-from-nfs-file-handle-in-isofs_export_iget.patch isofs-validate-rock-ridge-ce-continuation-extent-against-volume-size.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 s390-debug-reject-zero-length-input-in-debug_input_flush_fn.patch --- diff --git a/queue-5.10/asoc-fsl_easrc-fix-comment-typo.patch b/queue-5.10/asoc-fsl_easrc-fix-comment-typo.patch new file mode 100644 index 0000000000..51596540db --- /dev/null +++ b/queue-5.10/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.10/dm-don-t-report-warning-when-doing-deferred-remove.patch b/queue-5.10/dm-don-t-report-warning-when-doing-deferred-remove.patch new file mode 100644 index 0000000000..ce9328fd7e --- /dev/null +++ b/queue-5.10/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 +@@ -328,7 +328,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.10/dm-fix-a-buffer-overflow-in-ioctl-processing.patch b/queue-5.10/dm-fix-a-buffer-overflow-in-ioctl-processing.patch new file mode 100644 index 0000000000..69e550e192 --- /dev/null +++ b/queue-5.10/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 +@@ -1214,6 +1214,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.10/dm-verity-fec-correctly-reject-too-small-fec-devices.patch b/queue-5.10/dm-verity-fec-correctly-reject-too-small-fec-devices.patch new file mode 100644 index 0000000000..ea8f98b9d0 --- /dev/null +++ b/queue-5.10/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 +@@ -670,7 +670,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)) { +@@ -754,8 +754,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.10/dm-verity-fec-correctly-reject-too-small-hash-devices.patch b/queue-5.10/dm-verity-fec-correctly-reject-too-small-hash-devices.patch new file mode 100644 index 0000000000..250cc23826 --- /dev/null +++ b/queue-5.10/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 +@@ -733,7 +733,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.10/isofs-validate-block-number-from-nfs-file-handle-in-isofs_export_iget.patch b/queue-5.10/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.10/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.10/isofs-validate-rock-ridge-ce-continuation-extent-against-volume-size.patch b/queue-5.10/isofs-validate-rock-ridge-ce-continuation-extent-against-volume-size.patch new file mode 100644 index 0000000000..f696df19f5 --- /dev/null +++ b/queue-5.10/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.10/md-raid10-fix-divide-by-zero-in-setup_geo-with-zero-far_copies.patch b/queue-5.10/md-raid10-fix-divide-by-zero-in-setup_geo-with-zero-far_copies.patch new file mode 100644 index 0000000000..4025cf4cbf --- /dev/null +++ b/queue-5.10/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 +@@ -3606,6 +3606,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.10/nvmet-avoid-recursive-nvmet-wq-flush-in-nvmet_ctrl_free.patch b/queue-5.10/nvmet-avoid-recursive-nvmet-wq-flush-in-nvmet_ctrl_free.patch new file mode 100644 index 0000000000..85715d25c9 --- /dev/null +++ b/queue-5.10/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 +@@ -1440,7 +1440,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.10/s390-debug-reject-zero-length-input-in-debug_input_flush_fn.patch b/queue-5.10/s390-debug-reject-zero-length-input-in-debug_input_flush_fn.patch new file mode 100644 index 0000000000..3bc1373cc7 --- /dev/null +++ b/queue-5.10/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 +@@ -1387,6 +1387,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.10/series b/queue-5.10/series index 8781b7b2d4..04597a941b 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -252,3 +252,13 @@ 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 +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 +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 +s390-debug-reject-zero-length-input-in-debug_input_flush_fn.patch