--- /dev/null
+From a54bf16965f896415c3337bc4fbb40fb11941d99 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Sun, 26 Jul 2026 09:48:19 +0200
+Subject: ALSA: 6fire: Fix UAF at error handling during probe
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit a54bf16965f896415c3337bc4fbb40fb11941d99 upstream.
+
+Although 6fire driver had a few fixes for dealing with the early error
+handling during the probe phase, it forgot a pending URB before
+freeing the resources, which may lead to a UAF.
+
+This patch addresses it by doing the almost same cleanup procedure
+like the normal disconnect phase at the error path.
+
+Reported-and-tested-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
+Closes: https://lore.kernel.org/20260724030900.1984491-1-shuangpeng.kernel@gmail.com
+Cc: <stable@vger.kernel.org>
+Link: https://patch.msgid.link/20260726074821.2288158-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/6fire/chip.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/sound/usb/6fire/chip.c
++++ b/sound/usb/6fire/chip.c
+@@ -158,6 +158,10 @@ static int usb6fire_chip_probe(struct us
+ return 0;
+
+ destroy_chip:
++ chip->shutdown = true;
++ if (card)
++ snd_card_disconnect(card);
++ usb6fire_chip_abort(chip);
+ snd_card_free(card);
+ return ret;
+ }
--- /dev/null
+From 6437033bffe8bd2af174d139af552d90d40c7ac6 Mon Sep 17 00:00:00 2001
+From: Xu Rao <raoxu@uniontech.com>
+Date: Thu, 23 Jul 2026 16:57:10 +0800
+Subject: ALSA: lx6464es: fix period byte count for 16-bit streams
+
+From: Xu Rao <raoxu@uniontech.com>
+
+commit 6437033bffe8bd2af174d139af552d90d40c7ac6 upstream.
+
+The lx6464es driver advertises both 16-bit and packed 24-bit PCM formats,
+but lx_trigger_start() and lx_interrupt_request_new_buffer() calculate the
+DMA period size as runtime->period_size * runtime->channels * 3. That is
+only correct for the packed 24-bit formats.
+
+For 16-bit streams the driver submits buffers that are 50% larger than the
+actual ALSA period and advances the DMA address by the same wrong amount.
+For example, with 2 channels, 256 frames and 4 periods, the third buffer
+already extends beyond the ALSA buffer and the fourth buffer starts outside
+it.
+
+Use snd_pcm_lib_period_bytes() so the byte count matches the runtime
+format, channel count and period size.
+
+Fixes: 02bec4904508 ("ALSA: lx6464es - driver for the digigram lx6464es interface")
+Cc: stable@vger.kernel.org
+Signed-off-by: Xu Rao <raoxu@uniontech.com>
+Link: https://patch.msgid.link/8BB12E8D92A7CDBA+20260723085710.2567463-1-raoxu@uniontech.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/lx6464es/lx6464es.c | 5 +----
+ sound/pci/lx6464es/lx_core.c | 5 +----
+ 2 files changed, 2 insertions(+), 8 deletions(-)
+
+--- a/sound/pci/lx6464es/lx6464es.c
++++ b/sound/pci/lx6464es/lx6464es.c
+@@ -410,11 +410,8 @@ static void lx_trigger_start(struct lx64
+
+ int err;
+
+- const u32 channels = substream->runtime->channels;
+- const u32 bytes_per_frame = channels * 3;
+- const u32 period_size = substream->runtime->period_size;
+ const u32 periods = substream->runtime->periods;
+- const u32 period_bytes = period_size * bytes_per_frame;
++ const u32 period_bytes = snd_pcm_lib_period_bytes(substream);
+
+ dma_addr_t buf = substream->dma_buffer.addr;
+ int i;
+--- a/sound/pci/lx6464es/lx_core.c
++++ b/sound/pci/lx6464es/lx_core.c
+@@ -1015,10 +1015,7 @@ static int lx_interrupt_request_new_buff
+ const unsigned int is_capture = lx_stream->is_capture;
+ int err;
+
+- const u32 channels = substream->runtime->channels;
+- const u32 bytes_per_frame = channels * 3;
+- const u32 period_size = substream->runtime->period_size;
+- const u32 period_bytes = period_size * bytes_per_frame;
++ const u32 period_bytes = snd_pcm_lib_period_bytes(substream);
+ const u32 pos = lx_stream->frame_pos;
+ const u32 next_pos = ((pos+1) == substream->runtime->periods) ?
+ 0 : pos + 1;
--- /dev/null
+From f495b6c4c8594122918552c9be2b51eb71647cd9 Mon Sep 17 00:00:00 2001
+From: Norbert Szetei <norbert@doyensec.com>
+Date: Tue, 28 Jul 2026 14:50:01 +0200
+Subject: ALSA: pcm: wake linked drain waiters on unlink
+
+From: Norbert Szetei <norbert@doyensec.com>
+
+commit f495b6c4c8594122918552c9be2b51eb71647cd9 upstream.
+
+snd_pcm_drain() on a linked stream parks an on-stack wait entry on the
+drained peer's runtime->sleep, and after schedule_timeout() removes it
+only if that peer is still found in the caller's group. If group
+membership changes during the wait and the sleep ends by signal or
+timeout (so autoremove_wake_function() does not run), finish_wait() is
+skipped and snd_pcm_drain() returns with the entry still queued on that
+stream's sleep list; a later wake_up() then walks a freed stack frame.
+This is reachable by unlinking either the drained or the draining stream.
+
+Unlike the close path (snd_pcm_drop() -> snd_pcm_post_stop()),
+snd_pcm_unlink() never wakes the sleep queues. Wake every group member
+under the group lock before the membership change, so a linked drainer is
+released and drops its entry while the streams are still grouped.
+
+The window was opened when snd_pcm_link_rwsem stopped being held across
+the wait and the removal became conditional on group membership (see
+Fixes). The later switch to finish_wait() kept that conditional removal,
+so the signal/timeout case remained.
+
+Fixes: f57f3df03a8e ("ALSA: pcm: More fine-grained PCM link locking")
+Cc: stable@vger.kernel.org
+Assisted-by: Claude:claude-opus-5
+Signed-off-by: Norbert Szetei <norbert@doyensec.com>
+Link: https://patch.msgid.link/A0705100-D10B-4286-9980-0142ABEEAD51@doyensec.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/core/pcm_native.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/sound/core/pcm_native.c
++++ b/sound/core/pcm_native.c
+@@ -2354,6 +2354,7 @@ static void relink_to_local(struct snd_p
+
+ static int snd_pcm_unlink(struct snd_pcm_substream *substream)
+ {
++ struct snd_pcm_substream *s;
+ struct snd_pcm_group *group;
+ bool nonatomic = substream->pcm->nonatomic;
+ bool do_free = false;
+@@ -2369,6 +2370,12 @@ static int snd_pcm_unlink(struct snd_pcm
+ group = substream->group;
+ snd_pcm_group_lock_irq(group, nonatomic);
+
++ /* release drain waiters before changing membership, else snd_pcm_drain()
++ * leaves its on-stack wait entry queued on a member's sleep list
++ */
++ snd_pcm_group_for_each_entry(s, substream)
++ wake_up(&s->runtime->sleep);
++
+ relink_to_local(substream);
+ refcount_dec(&group->refs);
+
--- /dev/null
+From 70c977815af0d997feb2d0c5d284d55689bf7051 Mon Sep 17 00:00:00 2001
+From: Baul Lee <baul.lee@xbow.com>
+Date: Sun, 26 Jul 2026 14:16:33 +0900
+Subject: ALSA: ump: fix double free of out_cvts on rawmidi error
+
+From: Baul Lee <baul.lee@xbow.com>
+
+commit 70c977815af0d997feb2d0c5d284d55689bf7051 upstream.
+
+snd_ump_attach_legacy_rawmidi() allocates the legacy conversion array
+ump->out_cvts and, on the snd_rawmidi_new() error path, frees it with
+kfree() but leaves ump->out_cvts pointing at the freed memory. When the
+endpoint is later torn down, snd_ump_endpoint_free() frees ump->out_cvts
+a second time, resulting in a double free.
+
+The host snd-usb-audio driver attaches the legacy rawmidi for any USB
+MIDI 2.0 (UMP) device, so a device that makes snd_rawmidi_new() fail
+reaches this path on enumeration.
+
+Clear ump->out_cvts after freeing it on the error path so it is not
+freed again during teardown.
+
+Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
+
+Fixes: 33cd7630782d ("ALSA: ump: Export MIDI1 / UMP conversion helpers")
+Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
+Reported-by: Baul Lee <baul.lee@xbow.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Baul Lee <baul.lee@xbow.com>
+Link: https://patch.msgid.link/20260726051633.41206-1-baul.lee@xbow.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/core/ump.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/core/ump.c
++++ b/sound/core/ump.c
+@@ -1286,6 +1286,7 @@ int snd_ump_attach_legacy_rawmidi(struct
+ &rmidi);
+ if (err < 0) {
+ kfree(ump->out_cvts);
++ ump->out_cvts = NULL;
+ return err;
+ }
+
--- /dev/null
+From 8d7a30c50c2e58a6839634ed0acde14466d1dc61 Mon Sep 17 00:00:00 2001
+From: Sonali Pradhan <sonalipradhan@google.com>
+Date: Tue, 28 Jul 2026 20:24:32 +0000
+Subject: ALSA: usb-audio: Clamp frame size in implicit-feedback mode
+
+From: Sonali Pradhan <sonalipradhan@google.com>
+
+commit 8d7a30c50c2e58a6839634ed0acde14466d1dc61 upstream.
+
+snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's
+stride and stores the result directly in out_packet->packet_size[i]. If a
+connected USB device sends an oversized sync packet, this frame count can
+exceed ep->maxframesize.
+
+The un-clamped frame count then propagates to the playback endpoint queue,
+potentially driving packet transfers beyond the endpoint's hardware frame
+limits.
+
+Cap the calculated frame count against ep->maxframesize in
+snd_usb_handle_sync_urb() to prevent oversized packets from entering the
+playback queue.
+
+Fixes: 28acb12014fb ("ALSA: usb-audio: use sender stride for implicit feedback")
+Cc: stable@vger.kernel.org
+Assisted-by: Jetski:Gemini-3.6-Flash
+Signed-off-by: Sonali Pradhan <sonalipradhan@google.com>
+Link: https://patch.msgid.link/20260728202432.2354994-1-sonalipradhan@google.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/endpoint.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -1834,11 +1834,13 @@ static void snd_usb_handle_sync_urb(stru
+
+ out_packet->packets = in_ctx->packets;
+ for (i = 0; i < in_ctx->packets; i++) {
+- if (urb->iso_frame_desc[i].status == 0)
+- out_packet->packet_size[i] =
++ if (urb->iso_frame_desc[i].status == 0) {
++ unsigned int frames =
+ urb->iso_frame_desc[i].actual_length / sender->stride;
+- else
++ out_packet->packet_size[i] = min(frames, ep->maxframesize);
++ } else {
+ out_packet->packet_size[i] = 0;
++ }
+ }
+
+ spin_unlock_irqrestore(&ep->lock, flags);
--- /dev/null
+From d0199ae1666ff9ae2d1d568d64c3430d4c47f0e5 Mon Sep 17 00:00:00 2001
+From: Sonali Pradhan <sonalipradhan@google.com>
+Date: Tue, 28 Jul 2026 20:17:16 +0000
+Subject: ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set
+
+From: Sonali Pradhan <sonalipradhan@google.com>
+
+commit d0199ae1666ff9ae2d1d568d64c3430d4c47f0e5 upstream.
+
+When a USB audio endpoint requests full packet transfers via the fill_max
+descriptor flag, data_ep_set_params() promotes ep->curpacksize to
+ep->maxpacksize. However, maxsize is left at the original sample-rate
+derived value.
+
+Since u->buffer_size is allocated as maxsize * packets, the resulting
+DMA buffer is far too small for the requested transfer length. When the
+USB host controller streams up to curpacksize bytes per packet, it writes
+past the end of the buffer via DMA, corrupting kernel heap memory.
+
+Update maxsize to curpacksize when fill_max is set so that the allocated
+DMA buffer size matches the actual transfer request size.
+
+[ changed to reassign maxsize only when ep->fill_max is set -- tiwai ]
+
+Fixes: 8fdff6a319e7 ("ALSA: snd-usb: implement new endpoint streaming model")
+Cc: stable@vger.kernel.org
+Assisted-by: Jetski:Gemini-3.6-Flash
+Signed-off-by: Sonali Pradhan <sonalipradhan@google.com>
+Link: https://patch.msgid.link/20260728201716.2347726-1-sonalipradhan@google.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/endpoint.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -1185,10 +1185,12 @@ static int data_ep_set_params(struct snd
+ << (16 - ep->datainterval);
+ }
+
+- if (ep->fill_max)
++ if (ep->fill_max) {
+ ep->curpacksize = ep->maxpacksize;
+- else
++ maxsize = ep->curpacksize;
++ } else {
+ ep->curpacksize = maxsize;
++ }
+
+ if (snd_usb_get_speed(chip->dev) != USB_SPEED_FULL) {
+ packs_per_ms = 8 >> ep->datainterval;
--- /dev/null
+From 0970274613fb463d376211450cab066d34ebfe6a Mon Sep 17 00:00:00 2001
+From: Baul Lee <baul.lee@xbow.com>
+Date: Sun, 26 Jul 2026 16:45:00 +0900
+Subject: ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()
+
+From: Baul Lee <baul.lee@xbow.com>
+
+commit 0970274613fb463d376211450cab066d34ebfe6a upstream.
+
+snd_usbmidi_akai_output() computes its fill-loop bound
+
+ buf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1;
+
+as a signed int, so a small device-advertised bulk-OUT max_transfer
+makes buf_end negative. The loop guard then compares the u32
+urb->transfer_buffer_length against that negative int: the usual
+arithmetic conversion turns buf_end into a large unsigned value, so the
+guard stays true and each iteration keeps appending SysEx framing and
+payload bytes past the end of the URB transfer buffer, which is only
+max_transfer bytes long.
+
+A USB device that advertises a tiny bulk-OUT endpoint can therefore
+trigger an attacker-length- and content-controlled heap out-of-bounds
+write when a process writes to the created /dev/snd/midiC*D* node.
+
+Return early when there is no room for even one SysEx, so the loop is
+never entered with a bound that would wrap. The loop is the last
+statement of the function, so bailing out is equivalent to it not
+running.
+
+Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
+
+Fixes: 4434ade8c933 ("ALSA: usb-audio: add support for Akai MPD16")
+Suggested-by: Takashi Iwai <tiwai@suse.de>
+Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
+Reported-by: Baul Lee <baul.lee@xbow.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Baul Lee <baul.lee@xbow.com>
+Link: https://patch.msgid.link/20260726074500.50145-1-baul.lee@xbow.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/midi.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/sound/usb/midi.c
++++ b/sound/usb/midi.c
+@@ -800,6 +800,8 @@ static void snd_usbmidi_akai_output(stru
+
+ msg = urb->transfer_buffer + urb->transfer_buffer_length;
+ buf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1;
++ if (buf_end <= 0)
++ return;
+
+ /* only try adding more data when there's space for at least 1 SysEx */
+ while (urb->transfer_buffer_length < buf_end) {
--- /dev/null
+From 4a05b2d1b4642df74f30b6f54843e825c4a2bfd3 Mon Sep 17 00:00:00 2001
+From: Baul Lee <baul.lee@xbow.com>
+Date: Sun, 26 Jul 2026 14:13:37 +0900
+Subject: ALSA: usb-audio: fix use-after-free in ump_to_endpoint()
+
+From: Baul Lee <baul.lee@xbow.com>
+
+commit 4a05b2d1b4642df74f30b6f54843e825c4a2bfd3 upstream.
+
+create_midi2_ump() registers a card-owned snd_ump_endpoint and stores a
+back-pointer to its per-interface snd_usb_midi2_ump object in
+ump->private_data, but it never installs an ump->private_free hook and
+never clears that pointer.
+
+If a later step of snd_usb_midi_v2_create() fails, its error path calls
+free_all_midi2_umps(), which kfree()s the snd_usb_midi2_ump object while
+the already-registered endpoint keeps pointing at it. The created
+/dev/snd/umpC*D* node stays exposed, so the first operation of any UMP
+open, ump_to_endpoint(), dereferences the dangling ump->private_data and
+reads rmidi->eps[dir] out of freed memory.
+
+A malicious USB MIDI 2.0 device that makes creation fail after the
+endpoint is registered can thus trigger a slab use-after-free read on a
+subsequent open of the UMP node.
+
+Clear the endpoint's back-pointer before freeing the object, and let
+ump_to_endpoint() tolerate a NULL private_data so the open/close/trigger
+callbacks fail cleanly (their callers already handle a NULL endpoint)
+instead of dereferencing a stale pointer.
+
+Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
+
+Fixes: ff49d1df79ae ("ALSA: usb-audio: USB MIDI 2.0 UMP support")
+Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
+Reported-by: Baul Lee <baul.lee@xbow.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Baul Lee <baul.lee@xbow.com>
+Link: https://patch.msgid.link/20260726051337.41124-1-baul.lee@xbow.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/midi2.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/sound/usb/midi2.c
++++ b/sound/usb/midi2.c
+@@ -337,7 +337,7 @@ ump_to_endpoint(struct snd_ump_endpoint
+ {
+ struct snd_usb_midi2_ump *rmidi = ump->private_data;
+
+- return rmidi->eps[dir];
++ return rmidi ? rmidi->eps[dir] : NULL;
+ }
+
+ /* ump open callback */
+@@ -703,6 +703,8 @@ static void free_all_midi2_umps(struct s
+ rmidi = list_first_entry(&umidi->rawmidi_list,
+ struct snd_usb_midi2_ump, list);
+ list_del(&rmidi->list);
++ if (rmidi->ump)
++ rmidi->ump->private_data = NULL;
+ kfree(rmidi);
+ }
+ }
--- /dev/null
+From bdb0fd6de403fcea7b85dc9d38f0a571583ebe80 Mon Sep 17 00:00:00 2001
+From: Haidar Lee <haidar.lee@adlinktech.com>
+Date: Wed, 15 Jul 2026 14:04:41 +0800
+Subject: ASoC: tas2562: fix broken entries in the volume lookup table
+
+From: Haidar Lee <haidar.lee@adlinktech.com>
+
+commit bdb0fd6de403fcea7b85dc9d38f0a571583ebe80 upstream.
+
+The float_vol_db_lookup table is supposed to hold
+round(10^(dB/20) * 2^30) for every 2 dB step from -110 dB to 0 dB,
+which is 56 entries, but it only has 55: the -90 dB entry duplicates
+the -92 dB value (0x0000695b) and the -20 dB entry (0x06666666) is
+missing altogether. As a result every step between -90 dB and -22 dB
+is off by 2 dB, and the control's maximum raw value of 110 indexes one
+element past the end of the array.
+
+Replace the duplicated -90 dB entry with the correct value 0x000084a3
+and add the missing -20 dB entry, bringing the table to the full 56
+entries so index 55 (raw value 110, 0 dB) is in range again.
+
+Fixes: bf726b1c86f2 ("ASoC: tas2562: Add support for digital volume control")
+Cc: stable@vger.kernel.org
+Signed-off-by: Haidar Lee <haidar.lee@adlinktech.com>
+Link: https://patch.msgid.link/20260715-tas2562-dvc-fix-v1-2-072b13901b20@adlinktech.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/codecs/tas2562.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/sound/soc/codecs/tas2562.c
++++ b/sound/soc/codecs/tas2562.c
+@@ -32,15 +32,16 @@
+ static const unsigned int float_vol_db_lookup[] = {
+ 0x00000d43, 0x000010b2, 0x00001505, 0x00001a67, 0x00002151,
+ 0x000029f1, 0x000034cd, 0x00004279, 0x000053af, 0x0000695b,
+-0x0000695b, 0x0000a6fa, 0x0000d236, 0x000108a4, 0x00014d2a,
++0x000084a3, 0x0000a6fa, 0x0000d236, 0x000108a4, 0x00014d2a,
+ 0x0001a36e, 0x00021008, 0x000298c0, 0x000344df, 0x00041d8f,
+ 0x00052e5a, 0x000685c8, 0x00083621, 0x000a566d, 0x000d03a7,
+ 0x0010624d, 0x0014a050, 0x0019f786, 0x0020b0bc, 0x0029279d,
+ 0x0033cf8d, 0x004139d3, 0x00521d50, 0x00676044, 0x0082248a,
+ 0x00a3d70a, 0x00ce4328, 0x0103ab3d, 0x0146e75d, 0x019b8c27,
+ 0x02061b89, 0x028c423f, 0x03352529, 0x0409c2b0, 0x05156d68,
+-0x080e9f96, 0x0a24b062, 0x0cc509ab, 0x10137987, 0x143d1362,
+-0x197a967f, 0x2013739e, 0x28619ae9, 0x32d64617, 0x40000000
++0x06666666, 0x080e9f96, 0x0a24b062, 0x0cc509ab, 0x10137987,
++0x143d1362, 0x197a967f, 0x2013739e, 0x28619ae9, 0x32d64617,
++0x40000000
+ };
+
+ struct tas2562_data {
--- /dev/null
+From 8e957e4907c58e9ca944f98799524f2bbb9cf68a Mon Sep 17 00:00:00 2001
+From: Haidar Lee <haidar.lee@adlinktech.com>
+Date: Wed, 15 Jul 2026 14:04:40 +0800
+Subject: ASoC: tas2562: fix DVC coefficient write order
+
+From: Haidar Lee <haidar.lee@adlinktech.com>
+
+commit 8e957e4907c58e9ca944f98799524f2bbb9cf68a upstream.
+
+The TAS2562 applies the 32-bit digital volume coefficient to the
+playback path when the last byte, DVC_CFG4 (book 0 page 2 reg 0x0F), is
+written. tas2562_volume_control_put() wrote DVC_CFG4 first and DVC_CFG1
+(the MSB) last, so every volume change latched a value made of the
+previous coefficient's upper three bytes combined with the new LSB; the
+remaining bytes only took effect on the next volume change.
+
+In practice the control was unusable: the first setting after power-on
+always played at roughly 0 dB no matter what value was requested (the
+chip's default upper bytes were still latched), and most subsequent
+changes muted the output entirely or produced a distorted, over-unity
+gain.
+
+Verified on a TAS2562 (ADLINK OSM-520 / MT8189 board) by tracing the
+I2C writes with ftrace and by writing the same coefficients manually in
+both byte orders: written MSB-first the register block behaves exactly
+as the driver expects, LSB-first reproduces the broken behaviour.
+
+Write the bytes MSB first with DVC_CFG4 last so the complete new
+coefficient is latched atomically.
+
+Fixes: bf726b1c86f2 ("ASoC: tas2562: Add support for digital volume control")
+Cc: stable@vger.kernel.org
+Signed-off-by: Haidar Lee <haidar.lee@adlinktech.com>
+Link: https://patch.msgid.link/20260715-tas2562-dvc-fix-v1-1-072b13901b20@adlinktech.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/codecs/tas2562.c | 23 +++++++++++++++--------
+ 1 file changed, 15 insertions(+), 8 deletions(-)
+
+--- a/sound/soc/codecs/tas2562.c
++++ b/sound/soc/codecs/tas2562.c
+@@ -476,20 +476,27 @@ static int tas2562_volume_control_put(st
+ u32 reg_val;
+
+ reg_val = float_vol_db_lookup[ucontrol->value.integer.value[0]/2];
+- ret = snd_soc_component_write(component, TAS2562_DVC_CFG4,
+- (reg_val & 0xff));
+- if (ret)
+- return ret;
+- ret = snd_soc_component_write(component, TAS2562_DVC_CFG3,
+- ((reg_val >> 8) & 0xff));
++ /*
++ * The device applies the 32-bit coefficient to the playback path on
++ * the write to DVC_CFG4 (the LSB, book 0 page 2 reg 0x0F), so the
++ * bytes must be written MSB first and DVC_CFG4 last. Writing CFG4
++ * first latches a mix of the previous coefficient's upper bytes and
++ * the new LSB instead of the requested value.
++ */
++ ret = snd_soc_component_write(component, TAS2562_DVC_CFG1,
++ ((reg_val >> 24) & 0xff));
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG2,
+ ((reg_val >> 16) & 0xff));
+ if (ret)
+ return ret;
+- ret = snd_soc_component_write(component, TAS2562_DVC_CFG1,
+- ((reg_val >> 24) & 0xff));
++ ret = snd_soc_component_write(component, TAS2562_DVC_CFG3,
++ ((reg_val >> 8) & 0xff));
++ if (ret)
++ return ret;
++ ret = snd_soc_component_write(component, TAS2562_DVC_CFG4,
++ (reg_val & 0xff));
+ if (ret)
+ return ret;
+
--- /dev/null
+From 1e024d2b41ee32bc06818f7f09a3562c58842cf9 Mon Sep 17 00:00:00 2001
+From: Matt Vollrath <tactii@gmail.com>
+Date: Fri, 24 Jul 2026 03:39:42 -0400
+Subject: ata: libata-eh: Increase STANDBY IMMEDIATE timeout
+
+From: Matt Vollrath <tactii@gmail.com>
+
+commit 1e024d2b41ee32bc06818f7f09a3562c58842cf9 upstream.
+
+Correct a previous change (see Fixes) which reduced the standby timeout
+from 30 to 5 seconds. Increase it to 15 seconds.
+
+I was troubleshooting an error spotted during system suspend:
+
+ [ 1217.152867] ata1.00: Entering standby power mode
+ [ 1222.322948] ata1.00: qc timeout after 5000 msecs (cmd 0xe0)
+ [ 1222.324010] ata1.00: STANDBY IMMEDIATE failed (err_mask=0x4)
+
+This drive is a Samsung 870 EVO SSD in good SMART standing, and I wasn't
+aware of any reason it should be taking so long to standby. The issue is
+intermittent, but I observed it sometimes taking 7 seconds to manually
+standby. I assume this was interruption of background maintenance after
+a power outage.
+
+As a desktop user, I would prefer to wait the extra 2 seconds at suspend
+to let the drive finish its business rather than drop the rails from
+under it.
+
+The change from 30 to 5 seconds was implicit when switching suspend
+from START STOP UNIT to an internal command with no timeout table entry.
+No reason was stated for the change.
+
+Fixes: aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop")
+Cc: stable@vger.kernel.org
+Signed-off-by: Matt Vollrath <tactii@gmail.com>
+Assisted-by: Claude:claude-5-fable
+Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-eh.c | 8 ++++++++
+ include/linux/libata.h | 2 +-
+ 2 files changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/ata/libata-eh.c
++++ b/drivers/ata/libata-eh.c
+@@ -106,6 +106,12 @@ static const unsigned int ata_eh_flush_t
+ UINT_MAX,
+ };
+
++static const unsigned int ata_eh_standby_timeouts[] = {
++ 15000, /* Some drives may be slow to standby */
++ /* but don't hold up a suspend too long waiting for them */
++ UINT_MAX,
++};
++
+ static const unsigned int ata_eh_other_timeouts[] = {
+ 5000, /* same rationale as identify timeout */
+ 10000, /* ditto */
+@@ -147,6 +153,8 @@ ata_eh_cmd_timeout_table[ATA_EH_CMD_TIME
+ .timeouts = ata_eh_other_timeouts, },
+ { .commands = CMDS(ATA_CMD_FLUSH, ATA_CMD_FLUSH_EXT),
+ .timeouts = ata_eh_flush_timeouts },
++ { .commands = CMDS(ATA_CMD_STANDBYNOW1),
++ .timeouts = ata_eh_standby_timeouts },
+ { .commands = CMDS(ATA_CMD_VERIFY),
+ .timeouts = ata_eh_reset_timeouts },
+ };
+--- a/include/linux/libata.h
++++ b/include/linux/libata.h
+@@ -360,7 +360,7 @@ enum {
+ /* This should match the actual table size of
+ * ata_eh_cmd_timeout_table in libata-eh.c.
+ */
+- ATA_EH_CMD_TIMEOUT_TABLE_SIZE = 8,
++ ATA_EH_CMD_TIMEOUT_TABLE_SIZE = 9,
+
+ /* Horkage types. May be set by libata or controller on drives
+ (some horkage may be drive/controller pair dependent */
--- /dev/null
+From 88c17de85ddb459c3fe1e3c65d61fa366b1cf0a8 Mon Sep 17 00:00:00 2001
+From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
+Date: Thu, 23 Jul 2026 14:04:45 +0800
+Subject: bpf: lwt: Fix dst reference leak on reroute failure
+
+From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
+
+commit 88c17de85ddb459c3fe1e3c65d61fa366b1cf0a8 upstream.
+
+bpf_lwt_xmit_reroute() obtains a referenced dst from the route
+lookup. When skb_cow_head() fails before that dst is installed on the
+skb, the error path only frees the skb. The skb still owns its previous
+dst, so the newly looked up dst reference is leaked.
+
+Release the new dst reference before freeing the skb on this error
+path.
+
+Fixes: 3bd0b15281af ("bpf: add handling of BPF_LWT_REROUTE to lwt_bpf.c")
+Cc: stable@vger.kernel.org
+Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
+Link: https://patch.msgid.link/20260723060445.21926-1-xuanqiang.luo@linux.dev
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/lwt_bpf.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/net/core/lwt_bpf.c
++++ b/net/core/lwt_bpf.c
+@@ -246,8 +246,10 @@ static int bpf_lwt_xmit_reroute(struct s
+ * if there is enough header space in skb.
+ */
+ err = skb_cow_head(skb, LL_RESERVED_SPACE(dst->dev));
+- if (unlikely(err))
++ if (unlikely(err)) {
++ dst_release(dst);
+ goto err;
++ }
+
+ skb_dst_drop(skb);
+ skb_dst_set(skb, dst);
--- /dev/null
+From 867621ba203027338b525af6729719c544135336 Mon Sep 17 00:00:00 2001
+From: Md Sadre Alam <md.alam@oss.qualcomm.com>
+Date: Mon, 15 Jun 2026 11:39:08 +0530
+Subject: dmaengine: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+
+
+From: Md Sadre Alam <md.alam@oss.qualcomm.com>
+
+commit 867621ba203027338b525af6729719c544135336 upstream.
+
+BAM version 1.6.0 and later changed the behavior of the mask field in
+command elements for read operations.
+
+In older BAM versions, or prior implementation assumptions, the mask
+field was effectively ignored for read commands. However, starting from
+BAM v1.6.0, the mask field for read commands is repurposed to carry the
+upper 4 bits of the destination address, enabling support for 36-bit
+addressing. For write commands, the mask field continues to function as
+a traditional write mask.
+
+The current driver sets mask = 0xffffffff for all command elements.
+While this works for write operations, it breaks read operations on
+BAM v1.6.0+ hardware. In such cases, the hardware interprets the upper
+address bits as 0xf, resulting in an invalid destination address
+(0xf_xxxxxxxx instead of 0x0_xxxxxxxx).
+
+This leads to failures such as NAND enumeration issues observed on
+platforms like IPQ5424.
+
+Fix this by assigning the mask field based on command type:
+ - For read commands: set mask = 0 (upper address bits = 0)
+ - For write commands: retain mask = 0xffffffff
+
+Also update the bam_cmd_element structure documentation to reflect the
+dual purpose of the mask field across BAM versions.
+
+This ensures correct behavior on BAM v1.6.0+ while maintaining backward
+compatibility with older hardware.
+
+Fixes: dfebb055f73a2 ("dmaengine: qcom: bam_dma: wrapper functions for command descriptor")
+Tested-by: Lakshmi Sowjanya D <lakshmi.d@oss.qualcomm.com>
+Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com>
+Reviewed-by: Frank Li <Frank.Li@nxp.com>
+Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260615060908.1263171-1-varadarajan.narayanan@oss.qualcomm.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/dma/qcom_bam_dma.h | 21 ++++++++++++++++-----
+ 1 file changed, 16 insertions(+), 5 deletions(-)
+
+--- a/include/linux/dma/qcom_bam_dma.h
++++ b/include/linux/dma/qcom_bam_dma.h
+@@ -13,9 +13,12 @@
+ * supported by BAM DMA Engine.
+ *
+ * @cmd_and_addr - upper 8 bits command and lower 24 bits register address.
+- * @data - for write command: content to be written into peripheral register.
+- * for read command: dest addr to write peripheral register value.
+- * @mask - register mask.
++ * @data - For write command: content to be written into peripheral register.
++ * For read command: lower 32 bits of destination address.
++ * @mask - For write command: register write mask.
++ * For read command on BAM v1.6.0+: upper 4 bits of destination address.
++ * For read command on BAM < v1.6.0: ignored by hardware.
++ * Setting to 0 ensures 32-bit addressing compatibility.
+ * @reserved - for future usage.
+ *
+ */
+@@ -42,6 +45,10 @@ enum bam_command_type {
+ * @addr: target address
+ * @cmd: BAM command
+ * @data: actual data for write and dest addr for read in le32
++ *
++ * For BAM v1.6.0+, the mask field behavior depends on command type:
++ * - Write commands: mask = write mask (typically 0xffffffff)
++ * - Read commands: mask = upper 4 bits of destination address (0 for 32-bit)
+ */
+ static inline void
+ bam_prep_ce_le32(struct bam_cmd_element *bam_ce, u32 addr,
+@@ -50,7 +57,11 @@ bam_prep_ce_le32(struct bam_cmd_element
+ bam_ce->cmd_and_addr =
+ cpu_to_le32((addr & 0xffffff) | ((cmd & 0xff) << 24));
+ bam_ce->data = data;
+- bam_ce->mask = cpu_to_le32(0xffffffff);
++ if (cmd == BAM_READ_COMMAND)
++ bam_ce->mask = cpu_to_le32(0x0); /* 32-bit addressing */
++ else
++ bam_ce->mask = cpu_to_le32(0xffffffff); /* Write mask */
++ bam_ce->reserved = 0;
+ }
+
+ /*
+@@ -60,7 +71,7 @@ bam_prep_ce_le32(struct bam_cmd_element
+ * @bam_ce: BAM command element
+ * @addr: target address
+ * @cmd: BAM command
+- * @data: actual data for write and dest addr for read
++ * @data: actual data for write and destination address for read
+ */
+ static inline void
+ bam_prep_ce(struct bam_cmd_element *bam_ce, u32 addr,
--- /dev/null
+From 816419dfea5c88126f35eb7a1b429a1bf546665e Mon Sep 17 00:00:00 2001
+From: Dawei Feng <dawei.feng@seu.edu.cn>
+Date: Sun, 7 Jun 2026 22:57:06 +0800
+Subject: e1000: fix memory leak in e1000_probe()
+
+From: Dawei Feng <dawei.feng@seu.edu.cn>
+
+commit 816419dfea5c88126f35eb7a1b429a1bf546665e upstream.
+
+In the e1000_probe() path, e1000_sw_init() allocates adapter->tx_ring and
+adapter->rx_ring. If the subsequent CE4100-specific MDIO BAR mapping
+fails, the error handling jumps past the ring cleanup code, leaking both
+allocations.
+
+Fix this leak by moving the err_mdio_ioremap label above the ring
+deallocation logic. This guarantees the proper release of these resources
+and prevents the memory leak.
+
+The bug was first flagged by an experimental analysis tool we are
+developing for kernel memory-management bugs while analyzing
+v6.13-rc1. The tool is still under development and is not yet publicly
+available. Manual inspection confirms that the bug is still
+present in v7.1-rc6.
+
+An x86_64 allyesconfig build showed no new warnings. As we do not have a
+CE4100 reference platform to test with, no runtime testing was able to
+be performed.
+
+Fixes: 5377a4160bb65 ("e1000: Add support for the CE4100 reference platform")
+Cc: stable@vger.kernel.org
+Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
+Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
+Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/e1000/e1000_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
++++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
+@@ -1228,11 +1228,11 @@ err_eeprom:
+
+ if (hw->flash_address)
+ iounmap(hw->flash_address);
++err_mdio_ioremap:
+ kfree(adapter->tx_ring);
+ kfree(adapter->rx_ring);
+ err_dma:
+ err_sw_init:
+-err_mdio_ioremap:
+ iounmap(hw->ce4100_gbe_mdio_base_virt);
+ iounmap(hw->hw_addr);
+ err_ioremap:
--- /dev/null
+From 0565052b7e2f436b7f1541f4849da96dc0aa7a0e Mon Sep 17 00:00:00 2001
+From: Matt Vollrath <tactii@gmail.com>
+Date: Thu, 16 Apr 2026 23:34:52 -0400
+Subject: igbvf: Fix leak in TX DMA error cleanup
+
+From: Matt Vollrath <tactii@gmail.com>
+
+commit 0565052b7e2f436b7f1541f4849da96dc0aa7a0e upstream.
+
+If an error is encountered while mapping TX buffers, the driver should
+unmap any buffers already mapped for that skb.
+
+Because count is incremented before each frag mapping, it will always
+match the correct number of unmappings needed when dma_error is reached.
+Decrementing count before the while loop in dma_error causes an
+off-by-one error. If any mapping was successful before an unsuccessful
+mapping, exactly one DMA mapping (the head) would leak.
+
+This bug was introduced by a 2010 fix for an endless loop in dma_error.
+All other affected drivers have already been fixed.
+
+Fixes: c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of unsigned in *_tx_map()")
+Cc: stable@vger.kernel.org
+Assisted-by: Claude:claude-4-7-opus
+Signed-off-by: Matt Vollrath <tactii@gmail.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/igbvf/netdev.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/drivers/net/ethernet/intel/igbvf/netdev.c
++++ b/drivers/net/ethernet/intel/igbvf/netdev.c
+@@ -2201,8 +2201,6 @@ dma_error:
+ buffer_info->time_stamp = 0;
+ buffer_info->length = 0;
+ buffer_info->mapped_as_page = false;
+- if (count)
+- count--;
+
+ /* clear timestamp and dma mappings for remaining portion of packet */
+ while (count--) {
--- /dev/null
+From a63d2dbaeb50a85d4c976b15a36e6b0c7113db5b Mon Sep 17 00:00:00 2001
+From: Zhiling Zou <roxy520tt@gmail.com>
+Date: Mon, 13 Jul 2026 19:52:32 +0800
+Subject: ipvs: do not propagate one-packet flag to synced conns
+
+From: Zhiling Zou <roxy520tt@gmail.com>
+
+commit a63d2dbaeb50a85d4c976b15a36e6b0c7113db5b upstream.
+
+Synced connections can be created before their destination exists. When
+the destination is later added, ip_vs_bind_dest() copies connection flags
+from the destination into cp->flags.
+
+IP_VS_CONN_F_ONE_PACKET connections are not synced. If a synced
+connection inherits IP_VS_CONN_F_ONE_PACKET while it is already hashed,
+expiry can treat it as a one-packet connection and skip unlinking the
+existing conn_tab node, leaving stale hash nodes pointing at a freed
+struct ip_vs_conn.
+
+Drop IP_VS_CONN_F_ONE_PACKET from destination flags when binding synced
+connections.
+
+Fixes: 26ec037f9841 ("IPVS: one-packet scheduling")
+Cc: stable@vger.kernel.org
+Reported-by: Yuan Tan <yuantan098@gmail.com>
+Reported-by: Yifan Wu <yifanwucs@gmail.com>
+Reported-by: Juefei Pu <tomapufckgml@gmail.com>
+Reported-by: Xin Liu <bird@lzu.edu.cn>
+Suggested-by: Julian Anastasov <ja@ssi.bg>
+Signed-off-by: Zhiling Zou <roxy520tt@gmail.com>
+Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
+Acked-by: Julian Anastasov <ja@ssi.bg>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/netfilter/ipvs/ip_vs_conn.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/netfilter/ipvs/ip_vs_conn.c
++++ b/net/netfilter/ipvs/ip_vs_conn.c
+@@ -598,6 +598,9 @@ ip_vs_bind_dest(struct ip_vs_conn *cp, s
+ flags = cp->flags;
+ /* Bind with the destination and its corresponding transmitter */
+ if (flags & IP_VS_CONN_F_SYNC) {
++ /* Synced conns are hashed, so they can not get this flag */
++ conn_flags &= ~IP_VS_CONN_F_ONE_PACKET;
++
+ /* if the connection is not template and is created
+ * by sync, preserve the activity flag.
+ */
--- /dev/null
+From f621d6ebeebb6374342571e4ddf45fdbc420f6cd Mon Sep 17 00:00:00 2001
+From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
+Date: Thu, 23 Jul 2026 18:54:54 +0800
+Subject: net/smc: fix socket use-after-free during link group termination
+
+From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
+
+commit f621d6ebeebb6374342571e4ddf45fdbc420f6cd upstream.
+
+__smc_lgr_terminate() drops conns_lock after finding a connection in
+lgr->conns_all, but before taking a reference on its socket. The connection
+is embedded in the socket, and its registration reference protects it only
+while the connection remains in the tree.
+
+A concurrent close can unregister the connection and drop that reference,
+freeing the socket before the termination worker reaches sock_hold().
+
+The race is reachable when close overlaps link group termination.
+Local stress testing reproduced the use-after-free and KASAN reported:
+
+ BUG: KASAN: slab-use-after-free in __smc_lgr_terminate.part.0 [smc]
+ Write of size 4 by task kworker/3:3
+ Workqueue: events smc_lgr_terminate_work [smc]
+ __smc_lgr_terminate.part.0 [smc]
+
+The socket was allocated by smc_create(), freed through
+slab_free_after_rcu_debug(), and was followed by:
+
+ refcount_t: addition on 0; use-after-free.
+ __smc_lgr_terminate.part.0 [smc]
+
+Take the socket reference while conns_lock still protects the tree entry.
+The unregister path then cannot drop the last reference until termination
+has finished using the socket.
+
+Fixes: 69318b5215f2 ("net/smc: improve abnormal termination locking")
+Cc: stable@vger.kernel.org
+Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
+Reviewed-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
+Link: https://patch.msgid.link/20260723105454.87016-1-xuanqiang.luo@linux.dev
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/smc/smc_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/smc/smc_core.c
++++ b/net/smc/smc_core.c
+@@ -1502,10 +1502,10 @@ static void __smc_lgr_terminate(struct s
+ read_lock_bh(&lgr->conns_lock);
+ node = rb_first(&lgr->conns_all);
+ while (node) {
+- read_unlock_bh(&lgr->conns_lock);
+ conn = rb_entry(node, struct smc_connection, alert_node);
+ smc = container_of(conn, struct smc_sock, conn);
+ sock_hold(&smc->sk); /* sock_put below */
++ read_unlock_bh(&lgr->conns_lock);
+ lock_sock(&smc->sk);
+ smc_conn_kill(conn, soft);
+ release_sock(&smc->sk);
--- /dev/null
+From f30415929be8aeb002d557c8d3f7ab2d2188003a Mon Sep 17 00:00:00 2001
+From: David Lee <david.lee@trailofbits.com>
+Date: Mon, 13 Jul 2026 09:59:15 +0000
+Subject: netfilter: ipset: do not update comments from kernel-side hash adds
+
+From: David Lee <david.lee@trailofbits.com>
+
+commit f30415929be8aeb002d557c8d3f7ab2d2188003a upstream.
+
+mtype_resize() copies comment pointers with memcpy(), not the comment
+objects themselves. During the window after an entry has been copied but
+before the table swap and backlog replay, the old table is still
+published for packet-side updates while the replacement-table entry
+already holds the same ip_set_comment_rcu pointer.
+
+If xt_SET --add-set ... --exist hits that old entry in this window,
+mtype_add() calls ip_set_init_comment() even though packet-side adds
+carry no comment payload. That call frees the shared comment through the
+old entry, so the replacement-table entry now holds a stale pointer.
+When the queued add is replayed on the new table, mtype_add() calls
+ip_set_init_comment() again and strlen() dereferences the stale pointer.
+
+Fix this in mtype_add() by skipping ip_set_init_comment() when
+ext->target marks a packet-side add. Userspace adds still update
+comments, while packet-side adds can no longer free comment storage
+shared with a resize copy.
+
+Fixes: f66ee0410b1c ("netfilter: ipset: Fix "INFO: rcu detected stall in hash_xxx" reports")
+Cc: stable@vger.kernel.org
+Signed-off-by: David Lee <david.lee@trailofbits.com>
+Assisted-by: Codex:gpt-5.5
+Acked-by: Jozsef Kadlecsik <kadlec@netfilter.org>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/netfilter/ipset/ip_set_hash_gen.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/netfilter/ipset/ip_set_hash_gen.h
++++ b/net/netfilter/ipset/ip_set_hash_gen.h
+@@ -983,7 +983,7 @@ overwrite_extensions:
+ #endif
+ if (SET_WITH_COUNTER(set))
+ ip_set_init_counter(ext_counter(data, set), ext);
+- if (SET_WITH_COMMENT(set))
++ if (SET_WITH_COMMENT(set) && !ext->target)
+ ip_set_init_comment(set, ext_comment(data, set), ext);
+ if (SET_WITH_SKBINFO(set))
+ ip_set_init_skbinfo(ext_skbinfo(data, set), ext);
bluetooth-mgmt-fix-uaf-in-pair-command-cancellation.patch
bluetooth-hidp-reject-frames-without-a-transaction-header.patch
bluetooth-hidp-validate-numbered-report-payloads.patch
+bpf-lwt-fix-dst-reference-leak-on-reroute-failure.patch
+alsa-6fire-fix-uaf-at-error-handling-during-probe.patch
+alsa-lx6464es-fix-period-byte-count-for-16-bit-streams.patch
+alsa-pcm-wake-linked-drain-waiters-on-unlink.patch
+alsa-ump-fix-double-free-of-out_cvts-on-rawmidi-error.patch
+asoc-tas2562-fix-dvc-coefficient-write-order.patch
+asoc-tas2562-fix-broken-entries-in-the-volume-lookup-table.patch
+ata-libata-eh-increase-standby-immediate-timeout.patch
+alsa-usb-audio-fix-use-after-free-in-ump_to_endpoint.patch
+alsa-usb-audio-fix-oob-write-in-snd_usbmidi_akai_output.patch
+alsa-usb-audio-fix-dma-buffer-out-of-bounds-write-when-fill_max-is-set.patch
+alsa-usb-audio-clamp-frame-size-in-implicit-feedback-mode.patch
+dmaengine-qcom-bam_dma-fix-command-element-mask-field-for-bam-v1.6.0.patch
+e1000-fix-memory-leak-in-e1000_probe.patch
+igbvf-fix-leak-in-tx-dma-error-cleanup.patch
+ipvs-do-not-propagate-one-packet-flag-to-synced-conns.patch
+net-smc-fix-socket-use-after-free-during-link-group-termination.patch
+netfilter-ipset-do-not-update-comments-from-kernel-side-hash-adds.patch
+tipc-avoid-use-after-free-in-poll-trace-queue-dumps.patch
+wifi-mwifiex-use-the-subframe-length-when-parsing-a-msdu-tdls-frames.patch
--- /dev/null
+From b4f1719dfea023220e0e6bd892b087d76b2a6a49 Mon Sep 17 00:00:00 2001
+From: Zihan Xi <zihanx@nebusec.ai>
+Date: Fri, 24 Jul 2026 00:38:41 +0800
+Subject: tipc: avoid use-after-free in poll trace queue dumps
+
+From: Zihan Xi <zihanx@nebusec.ai>
+
+commit b4f1719dfea023220e0e6bd892b087d76b2a6a49 upstream.
+
+TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most
+queue-dump callsites already serialize that walk under the socket lock or
+sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(...,
+TIPC_DUMP_ALL, ...) without holding either lock.
+
+That lets the poll trace path reach tipc_list_dump() and backlog head/tail
+dumping while another context dequeues and frees an skb, leaving the trace
+helper dereferencing a stale queue entry.
+
+Stop the unlocked poll trace site from requesting queue dumps. Other queue
+dump trace callsites keep their existing output under the locking they
+already provide, while poll still emits the event itself without walking
+live queue members from an unlocked context.
+
+Fixes: b4b9771bcbbd ("tipc: enable tracepoints in tipc")
+Cc: stable@vger.kernel.org
+Reported-by: Vega <vega@nebusec.ai>
+Signed-off-by: Zihan Xi <zihanx@nebusec.ai>
+Signed-off-by: Ren Wei <enjou1224z@gmail.com>
+Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech>
+Link: https://patch.msgid.link/f8119abd5e5ecc400597de667ae9d39656de56d0.1784794294.git.zihanx@nebusec.ai
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/tipc/socket.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/tipc/socket.c
++++ b/net/tipc/socket.c
+@@ -798,7 +798,7 @@ static __poll_t tipc_poll(struct file *f
+ __poll_t revents = 0;
+
+ sock_poll_wait(file, sock, wait);
+- trace_tipc_sk_poll(sk, NULL, TIPC_DUMP_ALL, " ");
++ trace_tipc_sk_poll(sk, NULL, TIPC_DUMP_NONE, " ");
+
+ if (sk->sk_shutdown & RCV_SHUTDOWN)
+ revents |= EPOLLRDHUP | EPOLLIN | EPOLLRDNORM;
--- /dev/null
+From 99a948382af8a225e2d5e54a7052158cd6281cc6 Mon Sep 17 00:00:00 2001
+From: Zhao Li <enderaoelyther@gmail.com>
+Date: Tue, 28 Jul 2026 19:53:25 +0800
+Subject: wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames
+
+From: Zhao Li <enderaoelyther@gmail.com>
+
+commit 99a948382af8a225e2d5e54a7052158cd6281cc6 upstream.
+
+mwifiex_11n_dispatch_amsdu_pkt() splits an A-MSDU with
+ieee80211_amsdu_to_8023s() and walks the resulting subframes. For each
+subframe it passes the subframe data pointer to
+mwifiex_process_tdls_action_frame(), but pairs it with skb->len, the
+length of the A-MSDU parent, instead of rx_skb->len:
+
+ rx_skb = __skb_dequeue(&list);
+ rx_hdr = (struct rx_packet_hdr *)rx_skb->data;
+ if (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) &&
+ ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) {
+ mwifiex_process_tdls_action_frame(priv, (u8 *)rx_hdr,
+ skb->len);
+ }
+
+The parent is not a valid description of that buffer, and may not be
+valid memory at all. ieee80211_amsdu_to_8023s() ends with
+
+ if (!reuse_skb)
+ dev_kfree_skb(skb);
+
+and it only sets reuse_skb when the parent is linear, is not a
+head_frag, and is being consumed as the *last* subframe. So when the
+parent does not qualify for reuse it has already been freed, and the
+read of skb->len is a use-after-free. When it is reused, skb->len is
+the length of the last subframe, applied to every earlier subframe,
+which over-states the buffer whenever an earlier subframe is shorter.
+
+The callee cannot absorb a wrong length, because it derives its own
+ceiling from the value it is given. Each frame type computes
+
+ ies_len = len - sizeof(struct ethhdr) - TDLS_*_FIX_LEN;
+
+and the element walk is then bounded entirely against that ceiling,
+
+ for (end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]) {
+ u8 ie_len = pos[1];
+
+ if (pos + 2 + ie_len > end)
+ break;
+
+so a too-large len moves end past the end of the subframe and the walk
+reads and copies beyond it. The A-MSDU layout is chosen by the sender,
+which makes the difference between the last subframe and a shorter
+earlier one remotely selectable. Reaching this requires TDLS support in
+firmware and the TDLS ethertype on the subframe.
+
+The other caller, mwifiex_process_rx_packet(), is correct: it passes a
+pointer and a length that describe the same region of the RX buffer.
+
+Pass rx_skb->len, the length of the subframe actually being parsed.
+
+Fixes: 776f742040ca ("mwifiex: fix AMPDU not setup on TDLS link problem")
+Assisted-by: Codex:gpt-5.6-sol
+Assisted-by: Kimi:K3
+Cc: stable@vger.kernel.org
+Signed-off-by: Zhao Li <enderaoelyther@gmail.com>
+Link: https://patch.msgid.link/20260728115325.19128-1-enderaoelyther@gmail.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
++++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+@@ -44,7 +44,7 @@ static int mwifiex_11n_dispatch_amsdu_pk
+ ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) {
+ mwifiex_process_tdls_action_frame(priv,
+ (u8 *)rx_hdr,
+- skb->len);
++ rx_skb->len);
+ }
+
+ if (priv->bss_role == MWIFIEX_BSS_ROLE_UAP)
projects / thirdparty / kernel / stable-queue.git / commitdiff
