--- /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 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
+@@ -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);
+ }
+
--- /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
+@@ -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;
+ }
+
--- /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
+@@ -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;
+ }
--- /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
+@@ -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;
--- /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 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
+@@ -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;
--- /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
+@@ -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);
--- /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
+@@ -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) {
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
