--- /dev/null
+From d63c219b7ff39f897da10c160a2edef76320f16c Mon Sep 17 00:00:00 2001
+From: Tommaso Soncin <soncintommaso@gmail.com>
+Date: Wed, 29 Apr 2026 18:08:57 +0200
+Subject: ASoC: amd: yc: Add HP OMEN Gaming Laptop 16-ap0xxx product line in quirk table
+
+From: Tommaso Soncin <soncintommaso@gmail.com>
+
+commit d63c219b7ff39f897da10c160a2edef76320f16c upstream.
+
+Add a DMI quirk for the HP OMEN Gaming Laptop 16-ap0xxx line fixing the
+issue where the internal microphone was not detected.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Tommaso Soncin <soncintommaso@gmail.com>
+Link: https://patch.msgid.link/20260429160858.538986-1-soncintommaso@gmail.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/amd/yc/acp6x-mach.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/sound/soc/amd/yc/acp6x-mach.c
++++ b/sound/soc/amd/yc/acp6x-mach.c
+@@ -55,6 +55,13 @@ static const struct dmi_system_id yc_acp
+ {
+ .driver_data = &acp6x_card,
+ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "HP"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "OMEN Gaming Laptop 16-ap0xxx"),
++ }
++ },
++ {
++ .driver_data = &acp6x_card,
++ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Dell G15 5525"),
+ }
+@@ -578,6 +585,13 @@ static const struct dmi_system_id yc_acp
+ }
+ },
+ {
++ .driver_data = &acp6x_card,
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "HP"),
++ DMI_MATCH(DMI_BOARD_NAME, "8E35"),
++ }
++ },
++ {
+ .driver_data = &acp6x_card,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Micro-Star International Co., Ltd."),
--- /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 cab45ab95ce7600fc0ff84585c77fd45b7b0d67c Mon Sep 17 00:00:00 2001
+From: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
+Date: Thu, 2 Apr 2026 08:11:10 +0000
+Subject: ASoC: qcom: q6apm-dai: reset queue ptr on trigger stop
+
+From: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
+
+commit cab45ab95ce7600fc0ff84585c77fd45b7b0d67c upstream.
+
+Reset queue pointer on SNDRV_PCM_TRIGGER_STOP event to be inline
+with resetting appl_ptr. Without this we will end up with a queue_ptr
+out of sync and driver could try to send data that is not ready yet.
+
+Fix this by resetting the queue_ptr.
+
+Fixes: 3d4a4411aa8bb ("ASoC: q6apm-dai: schedule all available frames to avoid dsp under-runs")
+Cc: Stable@vger.kernel.org
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260402081118.348071-6-srinivas.kandagatla@oss.qualcomm.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/qcom/qdsp6/q6apm-dai.c | 1 +
+ sound/soc/qcom/qdsp6/q6apm.c | 2 ++
+ 2 files changed, 3 insertions(+)
+
+--- a/sound/soc/qcom/qdsp6/q6apm-dai.c
++++ b/sound/soc/qcom/qdsp6/q6apm-dai.c
+@@ -246,6 +246,7 @@ static int q6apm_dai_trigger(struct snd_
+ case SNDRV_PCM_TRIGGER_STOP:
+ /* TODO support be handled via SoftPause Module */
+ prtd->state = Q6APM_STREAM_STOPPED;
++ prtd->queue_ptr = 0;
+ break;
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+--- a/sound/soc/qcom/qdsp6/q6apm.c
++++ b/sound/soc/qcom/qdsp6/q6apm.c
+@@ -294,6 +294,8 @@ int q6apm_map_memory_regions(struct q6ap
+
+ mutex_lock(&graph->lock);
+
++ data->dsp_buf = 0;
++
+ if (data->buf) {
+ mutex_unlock(&graph->lock);
+ return 0;
--- /dev/null
+From 69acc488aaf39d0ddf6c3cf0e47c1873d39919a2 Mon Sep 17 00:00:00 2001
+From: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
+Date: Thu, 2 Apr 2026 08:11:09 +0000
+Subject: ASoC: qcom: q6apm-lpass-dai: Fix multiple graph opens
+
+From: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
+
+commit 69acc488aaf39d0ddf6c3cf0e47c1873d39919a2 upstream.
+
+As prepare can be called mulitple times, this can result in multiple
+graph opens for playback path.
+
+This will result in a memory leaks, fix this by adding a check before
+opening.
+
+Fixes: be1fae62cf25 ("ASoC: q6apm-lpass-dai: close graph on prepare errors")
+Cc: Stable@vger.kernel.org
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260402081118.348071-5-srinivas.kandagatla@oss.qualcomm.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/qcom/qdsp6/q6apm-lpass-dais.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/soc/qcom/qdsp6/q6apm-lpass-dais.c
++++ b/sound/soc/qcom/qdsp6/q6apm-lpass-dais.c
+@@ -144,7 +144,7 @@ static int q6apm_lpass_dai_prepare(struc
+ * It is recommend to load DSP with source graph first and then sink
+ * graph, so sequence for playback and capture will be different
+ */
+- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
++ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK && dai_data->graph[dai->id] == NULL) {
+ graph = q6apm_graph_open(dai->dev, NULL, dai->dev, graph_id);
+ if (IS_ERR(graph)) {
+ dev_err(dai->dev, "Failed to open graph (%d)\n", graph_id);
--- /dev/null
+From 4a0e1bcc98f7281d1605768bd2fe71eacc34f9b7 Mon Sep 17 00:00:00 2001
+From: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
+Date: Thu, 2 Apr 2026 08:11:07 +0000
+Subject: ASoC: qcom: q6apm: remove child devices when apm is removed
+
+From: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
+
+commit 4a0e1bcc98f7281d1605768bd2fe71eacc34f9b7 upstream.
+
+looks like q6apm driver does not remove the child driver q6apm-dai and
+q6apm-bedais when the this driver is removed.
+
+Fix this by depopulating them in remove callback.
+
+With this change when the dsp is shutdown all the devices associated with
+q6apm will now be removed.
+
+Fixes: 5477518b8a0e ("ASoC: qdsp6: audioreach: add q6apm support")
+Cc: Stable@vger.kernel.org
+Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260402081118.348071-3-srinivas.kandagatla@oss.qualcomm.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/qcom/qdsp6/q6apm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/soc/qcom/qdsp6/q6apm.c
++++ b/sound/soc/qcom/qdsp6/q6apm.c
+@@ -763,6 +763,7 @@ static int apm_probe(gpr_device_t *gdev)
+
+ static void apm_remove(gpr_device_t *gdev)
+ {
++ of_platform_depopulate(&gdev->dev);
+ snd_soc_unregister_component(&gdev->dev);
+ }
+
--- /dev/null
+From 3f487be81292702a59ea9dbc4088b3360a50e837 Mon Sep 17 00:00:00 2001
+From: Guangshuo Li <lgs201920130244@gmail.com>
+Date: Wed, 1 Apr 2026 18:56:19 +0800
+Subject: btrfs: fix double free in create_space_info() error path
+
+From: Guangshuo Li <lgs201920130244@gmail.com>
+
+commit 3f487be81292702a59ea9dbc4088b3360a50e837 upstream.
+
+When kobject_init_and_add() fails, the call chain is:
+
+create_space_info()
+-> btrfs_sysfs_add_space_info_type()
+-> kobject_init_and_add()
+-> failure
+-> kobject_put(&space_info->kobj)
+-> space_info_release()
+-> kfree(space_info)
+
+Then control returns to create_space_info():
+
+btrfs_sysfs_add_space_info_type() returns error
+-> goto out_free
+-> kfree(space_info)
+
+This causes a double free.
+
+Keep the direct kfree(space_info) for the earlier failure path, but
+after btrfs_sysfs_add_space_info_type() has called kobject_put(), let
+the kobject release callback handle the cleanup.
+
+Fixes: a11224a016d6d ("btrfs: fix memory leaks in create_space_info() error paths")
+CC: stable@vger.kernel.org # 6.19+
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/space-info.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/space-info.c
++++ b/fs/btrfs/space-info.c
+@@ -290,7 +290,7 @@ static int create_space_info(struct btrf
+
+ ret = btrfs_sysfs_add_space_info_type(info, space_info);
+ if (ret)
+- goto out_free;
++ return ret;
+
+ list_add(&space_info->list, &info->space_info);
+ if (flags & BTRFS_BLOCK_GROUP_DATA)
--- /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
+@@ -1316,6 +1316,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
+@@ -486,12 +486,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
+@@ -684,7 +684,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)) {
+@@ -765,8 +765,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
+@@ -747,7 +747,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
+@@ -3993,6 +3993,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 ba9d308ccd6732dd97ed8080d834a4a89e758e14 Mon Sep 17 00:00:00 2001
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+Date: Wed, 8 Apr 2026 17:18:14 +0300
+Subject: nvme-apple: drop invalid put of admin queue reference count
+
+From: Fedor Pchelkin <pchelkin@ispras.ru>
+
+commit ba9d308ccd6732dd97ed8080d834a4a89e758e14 upstream.
+
+Commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime") moved the
+admin queue reference ->put call into nvme_free_ctrl() - a controller
+device release callback performed for every nvme driver doing
+nvme_init_ctrl().
+
+nvme-apple sets refcount of the admin queue to 1 at allocation during the
+probe function and then puts it twice now:
+
+nvme_free_ctrl()
+ blk_put_queue(ctrl->admin_q) // #1
+ ->free_ctrl()
+ apple_nvme_free_ctrl()
+ blk_put_queue(anv->ctrl.admin_q) // #2
+
+Note that there is a commit 941f7298c70c ("nvme-apple: remove an extra
+queue reference") which intended to drop taking an extra admin queue
+reference. Looks like at that moment it accidentally fixed a refcount
+leak, which existed since the driver's introduction. There were two ->get
+calls at driver's probe function and a single ->put inside
+apple_nvme_free_ctrl().
+
+However now after commit 03b3bcd319b3 ("nvme: fix admin request_queue
+lifetime") the refcount is imbalanced again. Fix it by removing extra
+->put call from apple_nvme_free_ctrl(). anv->dev and ctrl->dev point to
+the same device, so use ctrl->dev directly for simplification. Compile
+tested only.
+
+Found by Linux Verification Center (linuxtesting.org).
+
+Fixes: 03b3bcd319b3 ("nvme: fix admin request_queue lifetime")
+Cc: stable@vger.kernel.org
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/host/apple.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+--- a/drivers/nvme/host/apple.c
++++ b/drivers/nvme/host/apple.c
+@@ -1194,11 +1194,7 @@ static int apple_nvme_get_address(struct
+
+ static void apple_nvme_free_ctrl(struct nvme_ctrl *ctrl)
+ {
+- struct apple_nvme *anv = ctrl_to_apple_nvme(ctrl);
+-
+- if (anv->ctrl.admin_q)
+- blk_put_queue(anv->ctrl.admin_q);
+- put_device(anv->dev);
++ put_device(ctrl->dev);
+ }
+
+ static const struct nvme_ctrl_ops nvme_ctrl_ops = {
--- /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
+@@ -1496,7 +1496,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);
+
+ nvmet_destroy_auth(ctrl);
--- /dev/null
+From aa69918bd418e700309fdd08509dba324fb24296 Mon Sep 17 00:00:00 2001
+From: Ilya Maximets <i.maximets@ovn.org>
+Date: Fri, 1 May 2026 01:38:37 +0200
+Subject: openvswitch: vport: fix self-deadlock on release of tunnel ports
+
+From: Ilya Maximets <i.maximets@ovn.org>
+
+commit aa69918bd418e700309fdd08509dba324fb24296 upstream.
+
+vports are used concurrently and protected by RCU, so netdev_put()
+must happen after the RCU grace period. So, either in an RCU call or
+after the synchronize_net(). The rtnl_delete_link() must happen under
+RTNL and so can't be executed in RCU context. Calling synchronize_net()
+while holding RTNL is not a good idea for performance and system
+stability under load in general, so calling netdev_put() in RCU call
+is the right solution here.
+
+However,
+when the device is deleted, rtnl_unlock() will call netdev_run_todo()
+and block until all the references are gone. In the current code this
+means that we never reach the call_rcu() and the vport is never freed
+and the reference is never released, causing a self-deadlock on device
+removal.
+
+Fix that by moving the rcu_call() before the rtnl_unlock(), so the
+scheduled RCU callback will be executed when synchronize_net() is
+called from the rtnl_unlock()->netdev_run_todo() while the RTNL itself
+is already released.
+
+Fixes: 6931d21f87bc ("openvswitch: defer tunnel netdev_put to RCU release")
+Cc: stable@vger.kernel.org
+Acked-by: Eelco Chaudron <echaudro@redhat.com>
+Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
+Acked-by: Aaron Conole <aconole@redhat.com>
+Link: https://patch.msgid.link/20260430233848.440994-2-i.maximets@ovn.org
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/openvswitch/vport-netdev.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/net/openvswitch/vport-netdev.c
++++ b/net/openvswitch/vport-netdev.c
+@@ -189,9 +189,13 @@ void ovs_netdev_tunnel_destroy(struct vp
+ */
+ if (vport->dev->reg_state == NETREG_REGISTERED)
+ rtnl_delete_link(vport->dev, 0, NULL);
+- rtnl_unlock();
+
++ /* We can't put the device reference yet, since it can still be in
++ * use, but rtnl_unlock()->netdev_run_todo() will block until all
++ * the references are released, so the RCU call must be before it.
++ */
+ call_rcu(&vport->rcu, vport_netdev_free);
++ rtnl_unlock();
+ }
+ EXPORT_SYMBOL_GPL(ovs_netdev_tunnel_destroy);
+
--- /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
+@@ -1146,6 +1146,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);
+@@ -1229,7 +1230,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) {
spi-topcliff-pch-fix-use-after-free-on-unbind.patch
clk-microchip-mpfs-ccc-fix-out-of-bounds-access-during-output-registration.patch
cpuidle-powerpc-avoid-double-clear-when-breaking-snooze.patch
+asoc-amd-yc-add-hp-omen-gaming-laptop-16-ap0xxx-product-line-in-quirk-table.patch
+asoc-fsl_easrc-fix-comment-typo.patch
+asoc-intel-bytcr_wm5102-fix-mclk-leak-on-platform_clock_control-error.patch
+asoc-qcom-q6apm-dai-reset-queue-ptr-on-trigger-stop.patch
+asoc-qcom-q6apm-lpass-dai-fix-multiple-graph-opens.patch
+asoc-qcom-q6apm-remove-child-devices-when-apm-is-removed.patch
+btrfs-fix-double-free-in-create_space_info-error-path.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
+nvme-apple-drop-invalid-put-of-admin-queue-reference-count.patch
+nvmet-avoid-recursive-nvmet-wq-flush-in-nvmet_ctrl_free.patch
+openvswitch-vport-fix-self-deadlock-on-release-of-tunnel-ports.patch
+rdma-hns-fix-unlocked-call-to-hns_roce_qp_remove.patch
+s390-debug-reject-zero-length-input-in-debug_input_flush_fn.patch
+smb-client-fix-out-of-bounds-read-in-symlink_data.patch
--- /dev/null
+From d62b8d236fab503c6fec1d3e9a38bea71feaca20 Mon Sep 17 00:00:00 2001
+From: Zisen Ye <zisenye@stu.xidian.edu.cn>
+Date: Sat, 2 May 2026 18:48:36 +0800
+Subject: smb/client: fix out-of-bounds read in symlink_data()
+
+From: Zisen Ye <zisenye@stu.xidian.edu.cn>
+
+commit d62b8d236fab503c6fec1d3e9a38bea71feaca20 upstream.
+
+Since smb2_check_message() returns success without length validation for
+the symlink error response, in symlink_data() it is possible for
+iov->iov_len to be smaller than sizeof(struct smb2_err_rsp). If the buffer
+only contains the base SMB2 header (64 bytes), accessing
+err->ErrorContextCount (at offset 66) or err->ByteCount later in
+symlink_data() will cause an out-of-bounds read.
+
+Link: https://lore.kernel.org/linux-cifs/297d8d9b-adf7-42fd-a1c2-5b1f230032bc@chenxiaosong.com/
+Fixes: 76894f3e2f71 ("cifs: improve symlink handling for smb2+")
+Cc: Stable@vger.kernel.org
+Signed-off-by: Zisen Ye <zisenye@stu.xidian.edu.cn>
+Reviewed-by: ChenXiaoSong <chenxiaosong@kylinos.cn>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/smb2misc.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/smb/client/smb2misc.c
++++ b/fs/smb/client/smb2misc.c
+@@ -239,7 +239,8 @@ smb2_check_message(char *buf, unsigned i
+ if (len != calc_len) {
+ /* create failed on symlink */
+ if (command == SMB2_CREATE_HE &&
+- shdr->Status == STATUS_STOPPED_ON_SYMLINK)
++ shdr->Status == STATUS_STOPPED_ON_SYMLINK &&
++ len > calc_len)
+ return 0;
+ /* Windows 7 server returns 24 bytes more */
+ if (calc_len + 24 == len && command == SMB2_OPLOCK_BREAK_HE)
projects / thirdparty / kernel / stable-queue.git / commitdiff
