--- /dev/null
+From c14231cc04337c2c2a937db084af342ce704dbde Mon Sep 17 00:00:00 2001
+From: Jonathan Teh <jonathan.teh@outlook.com>
+Date: Sun, 13 Mar 2022 19:56:17 +0000
+Subject: ALSA: cmipci: Restore aux vol on suspend/resume
+
+From: Jonathan Teh <jonathan.teh@outlook.com>
+
+commit c14231cc04337c2c2a937db084af342ce704dbde upstream.
+
+Save and restore CM_REG_AUX_VOL instead of register 0x24 twice on
+suspend/resume.
+
+Tested on CMI8738LX.
+
+Fixes: cb60e5f5b2b1 ("[ALSA] cmipci - Add PM support")
+Signed-off-by: Jonathan Teh <jonathan.teh@outlook.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/DBAPR04MB7366CB3EA9C8521C35C56E8B920E9@DBAPR04MB7366.eurprd04.prod.outlook.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/cmipci.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/sound/pci/cmipci.c
++++ b/sound/pci/cmipci.c
+@@ -302,7 +302,6 @@ MODULE_PARM_DESC(joystick_port, "Joystic
+ #define CM_MICGAINZ 0x01 /* mic boost */
+ #define CM_MICGAINZ_SHIFT 0
+
+-#define CM_REG_MIXER3 0x24
+ #define CM_REG_AUX_VOL 0x26
+ #define CM_VAUXL_MASK 0xf0
+ #define CM_VAUXR_MASK 0x0f
+@@ -3310,7 +3309,7 @@ static void snd_cmipci_remove(struct pci
+ */
+ static unsigned char saved_regs[] = {
+ CM_REG_FUNCTRL1, CM_REG_CHFORMAT, CM_REG_LEGACY_CTRL, CM_REG_MISC_CTRL,
+- CM_REG_MIXER0, CM_REG_MIXER1, CM_REG_MIXER2, CM_REG_MIXER3, CM_REG_PLL,
++ CM_REG_MIXER0, CM_REG_MIXER1, CM_REG_MIXER2, CM_REG_AUX_VOL, CM_REG_PLL,
+ CM_REG_CH0_FRAME1, CM_REG_CH0_FRAME2,
+ CM_REG_CH1_FRAME1, CM_REG_CH1_FRAME2, CM_REG_EXT_MISC,
+ CM_REG_INT_STATUS, CM_REG_INT_HLDCLR, CM_REG_FUNCTRL0,
--- /dev/null
+From b7557267c233b55d8e8d7ba4c68cf944fe2ec02c Mon Sep 17 00:00:00 2001
+From: Jason Zheng <jasonzheng2004@gmail.com>
+Date: Sun, 13 Mar 2022 04:22:16 -0500
+Subject: ALSA: hda/realtek: Add quirk for ASUS GA402
+
+From: Jason Zheng <jasonzheng2004@gmail.com>
+
+commit b7557267c233b55d8e8d7ba4c68cf944fe2ec02c upstream.
+
+ASUS GA402 requires a workaround to manage the routing of its 4 speakers
+like the other ASUS models. Add a corresponding quirk entry to fix it.
+
+Signed-off-by: Jason Zheng <jasonzheng2004@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220313092216.29858-1-jasonzheng2004@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -8183,6 +8183,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x1043, 0x1e51, "ASUS Zephyrus M15", ALC294_FIXUP_ASUS_GU502_PINS),
+ SND_PCI_QUIRK(0x1043, 0x1e8e, "ASUS Zephyrus G15", ALC289_FIXUP_ASUS_GA401),
+ SND_PCI_QUIRK(0x1043, 0x1f11, "ASUS Zephyrus G14", ALC289_FIXUP_ASUS_GA401),
++ SND_PCI_QUIRK(0x1043, 0x1d42, "ASUS Zephyrus G14 2022", ALC289_FIXUP_ASUS_GA401),
+ SND_PCI_QUIRK(0x1043, 0x16b2, "ASUS GU603", ALC289_FIXUP_ASUS_GA401),
+ SND_PCI_QUIRK(0x1043, 0x3030, "ASUS ZN270IE", ALC256_FIXUP_ASUS_AIO_GPIO2),
+ SND_PCI_QUIRK(0x1043, 0x831a, "ASUS P901", ALC269_FIXUP_STEREO_DMIC),
--- /dev/null
+From 882bd07f564f97fca6e42ce6ce627ce24ce1ef5a Mon Sep 17 00:00:00 2001
+From: huangwenhui <huangwenhuia@uniontech.com>
+Date: Fri, 11 Mar 2022 17:38:36 +0800
+Subject: ALSA: hda/realtek - Fix headset mic problem for a HP machine with alc671
+
+From: huangwenhui <huangwenhuia@uniontech.com>
+
+commit 882bd07f564f97fca6e42ce6ce627ce24ce1ef5a upstream.
+
+On a HP 288 Pro G8, the front mic could not be detected.In order to
+get it working, the pin configuration needs to be set correctly, and
+the ALC671_FIXUP_HP_HEADSET_MIC2 fixup needs to be applied.
+
+Signed-off-by: huangwenhui <huangwenhuia@uniontech.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220311093836.20754-1-huangwenhuia@uniontech.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -10201,6 +10201,7 @@ static const struct snd_pci_quirk alc662
+ SND_PCI_QUIRK(0x1028, 0x069f, "Dell", ALC668_FIXUP_DELL_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800),
+ SND_PCI_QUIRK(0x103c, 0x873e, "HP", ALC671_FIXUP_HP_HEADSET_MIC2),
++ SND_PCI_QUIRK(0x103c, 0x885f, "HP 288 Pro G8", ALC671_FIXUP_HP_HEADSET_MIC2),
+ SND_PCI_QUIRK(0x1043, 0x1080, "Asus UX501VW", ALC668_FIXUP_HEADSET_MODE),
+ SND_PCI_QUIRK(0x1043, 0x11cd, "Asus N550", ALC662_FIXUP_ASUS_Nx50),
+ SND_PCI_QUIRK(0x1043, 0x129d, "Asus N750", ALC662_FIXUP_ASUS_Nx50),
--- /dev/null
+From efb6402c3c4a7c26d97c92d70186424097b6e366 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 18 Mar 2022 09:20:36 +0100
+Subject: ALSA: oss: Fix PCM OSS buffer allocation overflow
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit efb6402c3c4a7c26d97c92d70186424097b6e366 upstream.
+
+We've got syzbot reports hitting INT_MAX overflow at vmalloc()
+allocation that is called from snd_pcm_plug_alloc(). Although we
+apply the restrictions to input parameters, it's based only on the
+hw_params of the underlying PCM device. Since the PCM OSS layer
+allocates a temporary buffer for the data conversion, the size may
+become unexpectedly large when more channels or higher rates is given;
+in the reported case, it went over INT_MAX, hence it hits WARN_ON().
+
+This patch is an attempt to avoid such an overflow and an allocation
+for too large buffers. First off, it adds the limit of 1MB as the
+upper bound for period bytes. This must be large enough for all use
+cases, and we really don't want to handle a larger temporary buffer
+than this size. The size check is performed at two places, where the
+original period bytes is calculated and where the plugin buffer size
+is calculated.
+
+In addition, the driver uses array_size() and array3_size() for
+multiplications to catch overflows for the converted period size and
+buffer bytes.
+
+Reported-by: syzbot+72732c532ac1454eeee9@syzkaller.appspotmail.com
+Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/00000000000085b1b305da5a66f3@google.com
+Link: https://lore.kernel.org/r/20220318082036.29699-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/core/oss/pcm_oss.c | 12 ++++++++----
+ sound/core/oss/pcm_plugin.c | 5 ++++-
+ 2 files changed, 12 insertions(+), 5 deletions(-)
+
+--- a/sound/core/oss/pcm_oss.c
++++ b/sound/core/oss/pcm_oss.c
+@@ -774,6 +774,11 @@ static int snd_pcm_oss_period_size(struc
+
+ if (oss_period_size < 16)
+ return -EINVAL;
++
++ /* don't allocate too large period; 1MB period must be enough */
++ if (oss_period_size > 1024 * 1024)
++ return -ENOMEM;
++
+ runtime->oss.period_bytes = oss_period_size;
+ runtime->oss.period_frames = 1;
+ runtime->oss.periods = oss_periods;
+@@ -1045,10 +1050,9 @@ static int snd_pcm_oss_change_params_loc
+ goto failure;
+ }
+ #endif
+- oss_period_size *= oss_frame_size;
+-
+- oss_buffer_size = oss_period_size * runtime->oss.periods;
+- if (oss_buffer_size < 0) {
++ oss_period_size = array_size(oss_period_size, oss_frame_size);
++ oss_buffer_size = array_size(oss_period_size, runtime->oss.periods);
++ if (oss_buffer_size <= 0) {
+ err = -EINVAL;
+ goto failure;
+ }
+--- a/sound/core/oss/pcm_plugin.c
++++ b/sound/core/oss/pcm_plugin.c
+@@ -61,7 +61,10 @@ static int snd_pcm_plugin_alloc(struct s
+ }
+ if ((width = snd_pcm_format_physical_width(format->format)) < 0)
+ return width;
+- size = frames * format->channels * width;
++ size = array3_size(frames, format->channels, width);
++ /* check for too large period size once again */
++ if (size > 1024 * 1024)
++ return -ENOMEM;
+ if (snd_BUG_ON(size % 8))
+ return -ENXIO;
+ size /= 8;
--- /dev/null
+From 17aaf0193392cb3451bf0ac75ba396ec4cbded6e Mon Sep 17 00:00:00 2001
+From: Giacomo Guiduzzi <guiduzzi.giacomo@gmail.com>
+Date: Tue, 22 Mar 2022 21:06:54 +0100
+Subject: ALSA: pci: fix reading of swapped values from pcmreg in AC97 codec
+
+From: Giacomo Guiduzzi <guiduzzi.giacomo@gmail.com>
+
+commit 17aaf0193392cb3451bf0ac75ba396ec4cbded6e upstream.
+
+Tests 72 and 78 for ALSA in kselftest fail due to reading
+inconsistent values from some devices on a VirtualBox
+Virtual Machine using the snd_intel8x0 driver for the AC'97
+Audio Controller device.
+Taking for example test number 72, this is what the test reports:
+"Surround Playback Volume.0 expected 1 but read 0, is_volatile 0"
+"Surround Playback Volume.1 expected 0 but read 1, is_volatile 0"
+These errors repeat for each value from 0 to 31.
+
+Taking a look at these error messages it is possible to notice
+that the written values are read back swapped.
+When the write is performed, these values are initially stored in
+an array used to sanity-check them and write them in the pcmreg
+array. To write them, the two one-byte values are packed together
+in a two-byte variable through bitwise operations: the first
+value is shifted left by one byte and the second value is stored in the
+right byte through a bitwise OR. When reading the values back,
+right shifts are performed to retrieve the previously stored
+bytes. These shifts are executed in the wrong order, thus
+reporting the values swapped as shown above.
+
+This patch fixes this mistake by reversing the read
+operations' order.
+
+Signed-off-by: Giacomo Guiduzzi <guiduzzi.giacomo@gmail.com>
+Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220322200653.15862-1-guiduzzi.giacomo@gmail.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/ac97/ac97_codec.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/pci/ac97/ac97_codec.c
++++ b/sound/pci/ac97/ac97_codec.c
+@@ -938,8 +938,8 @@ static int snd_ac97_ad18xx_pcm_get_volum
+ int codec = kcontrol->private_value & 3;
+
+ mutex_lock(&ac97->page_mutex);
+- ucontrol->value.integer.value[0] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 0) & 31);
+- ucontrol->value.integer.value[1] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 8) & 31);
++ ucontrol->value.integer.value[0] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 8) & 31);
++ ucontrol->value.integer.value[1] = 31 - ((ac97->spec.ad18xx.pcmreg[codec] >> 0) & 31);
+ mutex_unlock(&ac97->page_mutex);
+ return 0;
+ }
--- /dev/null
+From 1f68915b2efd0d6bfd6e124aa63c94b3c69f127c Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 22 Mar 2022 18:13:25 +0100
+Subject: ALSA: pcm: Add stream lock during PCM reset ioctl operations
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 1f68915b2efd0d6bfd6e124aa63c94b3c69f127c upstream.
+
+snd_pcm_reset() is a non-atomic operation, and it's allowed to run
+during the PCM stream running. It implies that the manipulation of
+hw_ptr and other parameters might be racy.
+
+This patch adds the PCM stream lock at appropriate places in
+snd_pcm_*_reset() actions for covering that.
+
+Cc: <stable@vger.kernel.org>
+Reviewed-by: Jaroslav Kysela <perex@perex.cz>
+Link: https://lore.kernel.org/r/20220322171325.4355-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/core/pcm_native.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/sound/core/pcm_native.c
++++ b/sound/core/pcm_native.c
+@@ -1656,21 +1656,25 @@ static int snd_pcm_do_reset(struct snd_p
+ int err = substream->ops->ioctl(substream, SNDRV_PCM_IOCTL1_RESET, NULL);
+ if (err < 0)
+ return err;
++ snd_pcm_stream_lock_irq(substream);
+ runtime->hw_ptr_base = 0;
+ runtime->hw_ptr_interrupt = runtime->status->hw_ptr -
+ runtime->status->hw_ptr % runtime->period_size;
+ runtime->silence_start = runtime->status->hw_ptr;
+ runtime->silence_filled = 0;
++ snd_pcm_stream_unlock_irq(substream);
+ return 0;
+ }
+
+ static void snd_pcm_post_reset(struct snd_pcm_substream *substream, int state)
+ {
+ struct snd_pcm_runtime *runtime = substream->runtime;
++ snd_pcm_stream_lock_irq(substream);
+ runtime->control->appl_ptr = runtime->status->hw_ptr;
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK &&
+ runtime->silence_size > 0)
+ snd_pcm_playback_silence(substream, ULONG_MAX);
++ snd_pcm_stream_unlock_irq(substream);
+ }
+
+ static const struct action_ops snd_pcm_action_reset = {
--- /dev/null
+From 0f306cca42fe879694fb5e2382748c43dc9e0196 Mon Sep 17 00:00:00 2001
+From: Lars-Peter Clausen <lars@metafoo.de>
+Date: Fri, 11 Mar 2022 21:14:00 +0100
+Subject: ALSA: usb-audio: Add mute TLV for playback volumes on RODE NT-USB
+
+From: Lars-Peter Clausen <lars@metafoo.de>
+
+commit 0f306cca42fe879694fb5e2382748c43dc9e0196 upstream.
+
+For the RODE NT-USB the lowest Playback mixer volume setting mutes the
+audio output. But it is not reported as such causing e.g. PulseAudio to
+accidentally mute the device when selecting a low volume.
+
+Fix this by applying the existing quirk for this kind of issue when the
+device is detected.
+
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220311201400.235892-1-lars@metafoo.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/mixer_quirks.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/sound/usb/mixer_quirks.c
++++ b/sound/usb/mixer_quirks.c
+@@ -2370,9 +2370,10 @@ void snd_usb_mixer_fu_apply_quirk(struct
+ if (unitid == 7 && cval->control == UAC_FU_VOLUME)
+ snd_dragonfly_quirk_db_scale(mixer, cval, kctl);
+ break;
+- /* lowest playback value is muted on C-Media devices */
+- case USB_ID(0x0d8c, 0x000c):
+- case USB_ID(0x0d8c, 0x0014):
++ /* lowest playback value is muted on some devices */
++ case USB_ID(0x0d8c, 0x000c): /* C-Media */
++ case USB_ID(0x0d8c, 0x0014): /* C-Media */
++ case USB_ID(0x19f7, 0x0003): /* RODE NT-USB */
+ if (strstr(kctl->id.name, "Playback"))
+ cval->min_mute = 1;
+ break;
--- /dev/null
+From 455c5653f50e10b4f460ef24e99f0044fbe3401c Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 15 Mar 2022 17:41:58 +0100
+Subject: ASoC: sti: Fix deadlock via snd_pcm_stop_xrun() call
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 455c5653f50e10b4f460ef24e99f0044fbe3401c upstream.
+
+This is essentially a revert of the commit dc865fb9e7c2 ("ASoC: sti:
+Use snd_pcm_stop_xrun() helper"), which converted the manual
+snd_pcm_stop() calls with snd_pcm_stop_xrun().
+
+The commit above introduced a deadlock as snd_pcm_stop_xrun() itself
+takes the PCM stream lock while the caller already holds it. Since
+the conversion was done only for consistency reason and the open-call
+with snd_pcm_stop() to the XRUN state is a correct usage, let's revert
+the commit back as the fix.
+
+Fixes: dc865fb9e7c2 ("ASoC: sti: Use snd_pcm_stop_xrun() helper")
+Reported-by: Daniel Palmer <daniel@0x0f.com>
+Cc: Arnaud POULIQUEN <arnaud.pouliquen@st.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220315091319.3351522-1-daniel@0x0f.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
+Link: https://lore.kernel.org/r/20220315164158.19804-1-tiwai@suse.de
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/sti/uniperif_player.c | 6 +++---
+ sound/soc/sti/uniperif_reader.c | 2 +-
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/sound/soc/sti/uniperif_player.c
++++ b/sound/soc/sti/uniperif_player.c
+@@ -91,7 +91,7 @@ static irqreturn_t uni_player_irq_handle
+ SET_UNIPERIF_ITM_BCLR_FIFO_ERROR(player);
+
+ /* Stop the player */
+- snd_pcm_stop_xrun(player->substream);
++ snd_pcm_stop(player->substream, SNDRV_PCM_STATE_XRUN);
+ }
+
+ ret = IRQ_HANDLED;
+@@ -105,7 +105,7 @@ static irqreturn_t uni_player_irq_handle
+ SET_UNIPERIF_ITM_BCLR_DMA_ERROR(player);
+
+ /* Stop the player */
+- snd_pcm_stop_xrun(player->substream);
++ snd_pcm_stop(player->substream, SNDRV_PCM_STATE_XRUN);
+
+ ret = IRQ_HANDLED;
+ }
+@@ -138,7 +138,7 @@ static irqreturn_t uni_player_irq_handle
+ dev_err(player->dev, "Underflow recovery failed\n");
+
+ /* Stop the player */
+- snd_pcm_stop_xrun(player->substream);
++ snd_pcm_stop(player->substream, SNDRV_PCM_STATE_XRUN);
+
+ ret = IRQ_HANDLED;
+ }
+--- a/sound/soc/sti/uniperif_reader.c
++++ b/sound/soc/sti/uniperif_reader.c
+@@ -65,7 +65,7 @@ static irqreturn_t uni_reader_irq_handle
+ if (unlikely(status & UNIPERIF_ITS_FIFO_ERROR_MASK(reader))) {
+ dev_err(reader->dev, "FIFO error detected\n");
+
+- snd_pcm_stop_xrun(reader->substream);
++ snd_pcm_stop(reader->substream, SNDRV_PCM_STATE_XRUN);
+
+ ret = IRQ_HANDLED;
+ }
--- /dev/null
+From e9e6faeafaa00da1851bcf47912b0f1acae666b4 Mon Sep 17 00:00:00 2001
+From: Stephane Graber <stgraber@ubuntu.com>
+Date: Tue, 22 Mar 2022 18:42:06 -0400
+Subject: drivers: net: xgene: Fix regression in CRC stripping
+
+From: Stephane Graber <stgraber@ubuntu.com>
+
+commit e9e6faeafaa00da1851bcf47912b0f1acae666b4 upstream.
+
+All packets on ingress (except for jumbo) are terminated with a 4-bytes
+CRC checksum. It's the responsability of the driver to strip those 4
+bytes. Unfortunately a change dating back to March 2017 re-shuffled some
+code and made the CRC stripping code effectively dead.
+
+This change re-orders that part a bit such that the datalen is
+immediately altered if needed.
+
+Fixes: 4902a92270fb ("drivers: net: xgene: Add workaround for errata 10GE_8/ENET_11")
+Cc: stable@vger.kernel.org
+Signed-off-by: Stephane Graber <stgraber@ubuntu.com>
+Tested-by: Stephane Graber <stgraber@ubuntu.com>
+Link: https://lore.kernel.org/r/20220322224205.752795-1-stgraber@ubuntu.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
++++ b/drivers/net/ethernet/apm/xgene/xgene_enet_main.c
+@@ -696,6 +696,12 @@ static int xgene_enet_rx_frame(struct xg
+ buf_pool->rx_skb[skb_index] = NULL;
+
+ datalen = xgene_enet_get_data_len(le64_to_cpu(raw_desc->m1));
++
++ /* strip off CRC as HW isn't doing this */
++ nv = GET_VAL(NV, le64_to_cpu(raw_desc->m0));
++ if (!nv)
++ datalen -= 4;
++
+ skb_put(skb, datalen);
+ prefetch(skb->data - NET_IP_ALIGN);
+ skb->protocol = eth_type_trans(skb, ndev);
+@@ -717,12 +723,8 @@ static int xgene_enet_rx_frame(struct xg
+ }
+ }
+
+- nv = GET_VAL(NV, le64_to_cpu(raw_desc->m0));
+- if (!nv) {
+- /* strip off CRC as HW isn't doing this */
+- datalen -= 4;
++ if (!nv)
+ goto skip_jumbo;
+- }
+
+ slots = page_pool->slots - 1;
+ head = page_pool->head;
--- /dev/null
+From 764f4eb6846f5475f1244767d24d25dd86528a4a Mon Sep 17 00:00:00 2001
+From: Eric Dumazet <edumazet@google.com>
+Date: Tue, 22 Mar 2022 17:41:47 -0700
+Subject: llc: fix netdevice reference leaks in llc_ui_bind()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Eric Dumazet <edumazet@google.com>
+
+commit 764f4eb6846f5475f1244767d24d25dd86528a4a upstream.
+
+Whenever llc_ui_bind() and/or llc_ui_autobind()
+took a reference on a netdevice but subsequently fail,
+they must properly release their reference
+or risk the infamous message from unregister_netdevice()
+at device dismantle.
+
+unregister_netdevice: waiting for eth0 to become free. Usage count = 3
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reported-by: 赵子轩 <beraphin@gmail.com>
+Reported-by: Stoyan Manolov <smanolov@suse.de>
+Link: https://lore.kernel.org/r/20220323004147.1990845-1-eric.dumazet@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/llc/af_llc.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/net/llc/af_llc.c
++++ b/net/llc/af_llc.c
+@@ -311,6 +311,10 @@ static int llc_ui_autobind(struct socket
+ sock_reset_flag(sk, SOCK_ZAPPED);
+ rc = 0;
+ out:
++ if (rc) {
++ dev_put(llc->dev);
++ llc->dev = NULL;
++ }
+ return rc;
+ }
+
+@@ -409,6 +413,10 @@ static int llc_ui_bind(struct socket *so
+ out_put:
+ llc_sap_put(sap);
+ out:
++ if (rc) {
++ dev_put(llc->dev);
++ llc->dev = NULL;
++ }
+ release_sock(sk);
+ return rc;
+ }
--- /dev/null
+From 4c905f6740a365464e91467aa50916555b28213d Mon Sep 17 00:00:00 2001
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+Date: Thu, 17 Mar 2022 12:04:42 +0100
+Subject: netfilter: nf_tables: initialize registers in nft_do_chain()
+
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+
+commit 4c905f6740a365464e91467aa50916555b28213d upstream.
+
+Initialize registers to avoid stack leak into userspace.
+
+Fixes: 96518518cc41 ("netfilter: add nftables")
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/netfilter/nf_tables_core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/netfilter/nf_tables_core.c
++++ b/net/netfilter/nf_tables_core.c
+@@ -153,7 +153,7 @@ nft_do_chain(struct nft_pktinfo *pkt, vo
+ struct nft_rule *const *rules;
+ const struct nft_rule *rule;
+ const struct nft_expr *expr, *last;
+- struct nft_regs regs;
++ struct nft_regs regs = {};
+ unsigned int stackptr = 0;
+ struct nft_jumpstack jumpstack[NFT_JUMP_STACK_SIZE];
+ bool genbit = READ_ONCE(net->nft.gencursor);
esp-fix-possible-buffer-overflow-in-esp-transformation.patch
tpm-fix-error-handling-in-async-work.patch
staging-fbtft-fb_st7789v-reset-display-before-initialization.patch
+thermal-int340x-fix-memory-leak-in-int3400_notify.patch
+llc-fix-netdevice-reference-leaks-in-llc_ui_bind.patch
+swiotlb-fix-info-leak-with-dma_from_device.patch
+swiotlb-rework-fix-info-leak-with-dma_from_device.patch
+alsa-pcm-add-stream-lock-during-pcm-reset-ioctl-operations.patch
+alsa-usb-audio-add-mute-tlv-for-playback-volumes-on-rode-nt-usb.patch
+alsa-cmipci-restore-aux-vol-on-suspend-resume.patch
+alsa-pci-fix-reading-of-swapped-values-from-pcmreg-in-ac97-codec.patch
+drivers-net-xgene-fix-regression-in-crc-stripping.patch
+asoc-sti-fix-deadlock-via-snd_pcm_stop_xrun-call.patch
+alsa-oss-fix-pcm-oss-buffer-allocation-overflow.patch
+alsa-hda-realtek-fix-headset-mic-problem-for-a-hp-machine-with-alc671.patch
+alsa-hda-realtek-add-quirk-for-asus-ga402.patch
+netfilter-nf_tables-initialize-registers-in-nft_do_chain.patch
--- /dev/null
+From ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e Mon Sep 17 00:00:00 2001
+From: Halil Pasic <pasic@linux.ibm.com>
+Date: Fri, 11 Feb 2022 02:12:52 +0100
+Subject: swiotlb: fix info leak with DMA_FROM_DEVICE
+
+From: Halil Pasic <pasic@linux.ibm.com>
+
+commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e upstream.
+
+The problem I'm addressing was discovered by the LTP test covering
+cve-2018-1000204.
+
+A short description of what happens follows:
+1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
+ interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
+ and a corresponding dxferp. The peculiar thing about this is that TUR
+ is not reading from the device.
+2) In sg_start_req() the invocation of blk_rq_map_user() effectively
+ bounces the user-space buffer. As if the device was to transfer into
+ it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in
+ sg_build_indirect()") we make sure this first bounce buffer is
+ allocated with GFP_ZERO.
+3) For the rest of the story we keep ignoring that we have a TUR, so the
+ device won't touch the buffer we prepare as if the we had a
+ DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device
+ and the buffer allocated by SG is mapped by the function
+ virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here
+ scatter-gather and not scsi generics). This mapping involves bouncing
+ via the swiotlb (we need swiotlb to do virtio in protected guest like
+ s390 Secure Execution, or AMD SEV).
+4) When the SCSI TUR is done, we first copy back the content of the second
+ (that is swiotlb) bounce buffer (which most likely contains some
+ previous IO data), to the first bounce buffer, which contains all
+ zeros. Then we copy back the content of the first bounce buffer to
+ the user-space buffer.
+5) The test case detects that the buffer, which it zero-initialized,
+ ain't all zeros and fails.
+
+One can argue that this is an swiotlb problem, because without swiotlb
+we leak all zeros, and the swiotlb should be transparent in a sense that
+it does not affect the outcome (if all other participants are well
+behaved).
+
+Copying the content of the original buffer into the swiotlb buffer is
+the only way I can think of to make swiotlb transparent in such
+scenarios. So let's do just that if in doubt, but allow the driver
+to tell us that the whole mapped buffer is going to be overwritten,
+in which case we can preserve the old behavior and avoid the performance
+impact of the extra bounce.
+
+Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/DMA-attributes.txt | 10 ++++++++++
+ include/linux/dma-mapping.h | 8 ++++++++
+ kernel/dma/swiotlb.c | 3 ++-
+ 3 files changed, 20 insertions(+), 1 deletion(-)
+
+--- a/Documentation/DMA-attributes.txt
++++ b/Documentation/DMA-attributes.txt
+@@ -156,3 +156,13 @@ accesses to DMA buffers in both privileg
+ subsystem that the buffer is fully accessible at the elevated privilege
+ level (and ideally inaccessible or at least read-only at the
+ lesser-privileged levels).
++
++DMA_ATTR_PRIVILEGED
++-------------------
++
++Some advanced peripherals such as remote processors and GPUs perform
++accesses to DMA buffers in both privileged "supervisor" and unprivileged
++"user" modes. This attribute is used to indicate to the DMA-mapping
++subsystem that the buffer is fully accessible at the elevated privilege
++level (and ideally inaccessible or at least read-only at the
++lesser-privileged levels).
+--- a/include/linux/dma-mapping.h
++++ b/include/linux/dma-mapping.h
+@@ -71,6 +71,14 @@
+ #define DMA_ATTR_PRIVILEGED (1UL << 9)
+
+ /*
++ * This is a hint to the DMA-mapping subsystem that the device is expected
++ * to overwrite the entire mapped size, thus the caller does not require any
++ * of the previous buffer contents to be preserved. This allows
++ * bounce-buffering implementations to optimise DMA_FROM_DEVICE transfers.
++ */
++#define DMA_ATTR_OVERWRITE (1UL << 10)
++
++/*
+ * A dma_addr_t can hold any valid DMA or bus address for the platform.
+ * It can be given to a device to use as a DMA source or target. A CPU cannot
+ * reference a dma_addr_t directly because there may be translation between
+--- a/kernel/dma/swiotlb.c
++++ b/kernel/dma/swiotlb.c
+@@ -572,7 +572,8 @@ found:
+ for (i = 0; i < nslots; i++)
+ io_tlb_orig_addr[index+i] = orig_addr + (i << IO_TLB_SHIFT);
+ if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
+- (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
++ (!(attrs & DMA_ATTR_OVERWRITE) || dir == DMA_TO_DEVICE ||
++ dir == DMA_BIDIRECTIONAL))
+ swiotlb_bounce(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE);
+
+ return tlb_addr;
--- /dev/null
+From aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 Mon Sep 17 00:00:00 2001
+From: Halil Pasic <pasic@linux.ibm.com>
+Date: Sat, 5 Mar 2022 18:07:14 +0100
+Subject: swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
+
+From: Halil Pasic <pasic@linux.ibm.com>
+
+commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 upstream.
+
+Unfortunately, we ended up merging an old version of the patch "fix info
+leak with DMA_FROM_DEVICE" instead of merging the latest one. Christoph
+(the swiotlb maintainer), he asked me to create an incremental fix
+(after I have pointed this out the mix up, and asked him for guidance).
+So here we go.
+
+The main differences between what we got and what was agreed are:
+* swiotlb_sync_single_for_device is also required to do an extra bounce
+* We decided not to introduce DMA_ATTR_OVERWRITE until we have exploiters
+* The implantation of DMA_ATTR_OVERWRITE is flawed: DMA_ATTR_OVERWRITE
+ must take precedence over DMA_ATTR_SKIP_CPU_SYNC
+
+Thus this patch removes DMA_ATTR_OVERWRITE, and makes
+swiotlb_sync_single_for_device() bounce unconditionally (that is, also
+when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale
+data from the swiotlb buffer.
+
+Let me note, that if the size used with dma_sync_* API is less than the
+size used with dma_[un]map_*, under certain circumstances we may still
+end up with swiotlb not being transparent. In that sense, this is no
+perfect fix either.
+
+To get this bullet proof, we would have to bounce the entire
+mapping/bounce buffer. For that we would have to figure out the starting
+address, and the size of the mapping in
+swiotlb_sync_single_for_device(). While this does seem possible, there
+seems to be no firm consensus on how things are supposed to work.
+
+Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
+Fixes: ddbd89deb7d3 ("swiotlb: fix info leak with DMA_FROM_DEVICE")
+Cc: stable@vger.kernel.org
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/DMA-attributes.txt | 10 ----------
+ include/linux/dma-mapping.h | 8 --------
+ kernel/dma/swiotlb.c | 25 ++++++++++++++++---------
+ 3 files changed, 16 insertions(+), 27 deletions(-)
+
+--- a/Documentation/DMA-attributes.txt
++++ b/Documentation/DMA-attributes.txt
+@@ -156,13 +156,3 @@ accesses to DMA buffers in both privileg
+ subsystem that the buffer is fully accessible at the elevated privilege
+ level (and ideally inaccessible or at least read-only at the
+ lesser-privileged levels).
+-
+-DMA_ATTR_PRIVILEGED
+--------------------
+-
+-Some advanced peripherals such as remote processors and GPUs perform
+-accesses to DMA buffers in both privileged "supervisor" and unprivileged
+-"user" modes. This attribute is used to indicate to the DMA-mapping
+-subsystem that the buffer is fully accessible at the elevated privilege
+-level (and ideally inaccessible or at least read-only at the
+-lesser-privileged levels).
+--- a/include/linux/dma-mapping.h
++++ b/include/linux/dma-mapping.h
+@@ -71,14 +71,6 @@
+ #define DMA_ATTR_PRIVILEGED (1UL << 9)
+
+ /*
+- * This is a hint to the DMA-mapping subsystem that the device is expected
+- * to overwrite the entire mapped size, thus the caller does not require any
+- * of the previous buffer contents to be preserved. This allows
+- * bounce-buffering implementations to optimise DMA_FROM_DEVICE transfers.
+- */
+-#define DMA_ATTR_OVERWRITE (1UL << 10)
+-
+-/*
+ * A dma_addr_t can hold any valid DMA or bus address for the platform.
+ * It can be given to a device to use as a DMA source or target. A CPU cannot
+ * reference a dma_addr_t directly because there may be translation between
+--- a/kernel/dma/swiotlb.c
++++ b/kernel/dma/swiotlb.c
+@@ -571,10 +571,14 @@ found:
+ */
+ for (i = 0; i < nslots; i++)
+ io_tlb_orig_addr[index+i] = orig_addr + (i << IO_TLB_SHIFT);
+- if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
+- (!(attrs & DMA_ATTR_OVERWRITE) || dir == DMA_TO_DEVICE ||
+- dir == DMA_BIDIRECTIONAL))
+- swiotlb_bounce(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE);
++ /*
++ * When dir == DMA_FROM_DEVICE we could omit the copy from the orig
++ * to the tlb buffer, if we knew for sure the device will
++ * overwirte the entire current content. But we don't. Thus
++ * unconditional bounce may prevent leaking swiotlb content (i.e.
++ * kernel memory) to user-space.
++ */
++ swiotlb_bounce(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE);
+
+ return tlb_addr;
+ }
+@@ -649,11 +653,14 @@ void swiotlb_tbl_sync_single(struct devi
+ BUG_ON(dir != DMA_TO_DEVICE);
+ break;
+ case SYNC_FOR_DEVICE:
+- if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
+- swiotlb_bounce(orig_addr, tlb_addr,
+- size, DMA_TO_DEVICE);
+- else
+- BUG_ON(dir != DMA_FROM_DEVICE);
++ /*
++ * Unconditional bounce is necessary to avoid corruption on
++ * sync_*_for_cpu or dma_ummap_* when the device didn't
++ * overwrite the whole lengt of the bounce buffer.
++ */
++ swiotlb_bounce(orig_addr, tlb_addr,
++ size, DMA_TO_DEVICE);
++ BUG_ON(!valid_dma_direction(dir));
+ break;
+ default:
+ BUG();
--- /dev/null
+From foo@baz Fri Mar 25 10:09:45 AM CET 2022
+From: Chuansheng Liu <chuansheng.liu@intel.com>
+Date: Wed, 23 Feb 2022 08:20:24 +0800
+Subject: thermal: int340x: fix memory leak in int3400_notify()
+
+From: Chuansheng Liu <chuansheng.liu@intel.com>
+
+commit 3abea10e6a8f0e7804ed4c124bea2d15aca977c8 upstream.
+
+It is easy to hit the below memory leaks in my TigerLake platform:
+
+unreferenced object 0xffff927c8b91dbc0 (size 32):
+ comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s)
+ hex dump (first 32 bytes):
+ 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The
+ 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk.
+ backtrace:
+ [<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0
+ [<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0
+ [<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70
+ [<ffffffffc04cb662>] int3400_notify+0x82/0x120 [int3400_thermal]
+ [<ffffffff9c8b7358>] acpi_ev_notify_dispatch+0x54/0x71
+ [<ffffffff9c88f1a7>] acpi_os_execute_deferred+0x17/0x30
+ [<ffffffff9c2c2c0a>] process_one_work+0x21a/0x3f0
+ [<ffffffff9c2c2e2a>] worker_thread+0x4a/0x3b0
+ [<ffffffff9c2cb4dd>] kthread+0xfd/0x130
+ [<ffffffff9c201c1f>] ret_from_fork+0x1f/0x30
+
+Fix it by calling kfree() accordingly.
+
+Fixes: 38e44da59130 ("thermal: int3400_thermal: process "thermal table changed" event")
+Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
+Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+[sudip: adjust context]
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thermal/intel/int340x_thermal/int3400_thermal.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
++++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c
+@@ -216,6 +216,10 @@ static void int3400_notify(acpi_handle h
+ thermal_prop[4] = NULL;
+ kobject_uevent_env(&priv->thermal->device.kobj, KOBJ_CHANGE,
+ thermal_prop);
++ kfree(thermal_prop[0]);
++ kfree(thermal_prop[1]);
++ kfree(thermal_prop[2]);
++ kfree(thermal_prop[3]);
+ break;
+ default:
+ /* Ignore unknown notification codes sent to INT3400 device */
projects / thirdparty / kernel / stable-queue.git / commitdiff
