--- /dev/null
+From ecb9c790999fd6c5af0f44783bd0217f0b89ec2b Mon Sep 17 00:00:00 2001
+From: Jan Engelhardt <jengelh@inai.de>
+Date: Thu, 5 Mar 2020 13:24:25 +0100
+Subject: acpi/x86: ignore unspecified bit positions in the ACPI global lock field
+
+From: Jan Engelhardt <jengelh@inai.de>
+
+commit ecb9c790999fd6c5af0f44783bd0217f0b89ec2b upstream.
+
+The value in "new" is constructed from "old" such that all bits defined
+as reserved by the ACPI spec[1] are left untouched. But if those bits
+do not happen to be all zero, "new < 3" will not evaluate to true.
+
+The firmware of the laptop(s) Medion MD63490 / Akoya P15648 comes with
+garbage inside the "FACS" ACPI table. The starting value is
+old=0x4944454d, therefore new=0x4944454e, which is >= 3. Mask off
+the reserved bits.
+
+[1] https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=206553
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Jan Engelhardt <jengelh@inai.de>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/acpi/boot.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/acpi/boot.c
++++ b/arch/x86/kernel/acpi/boot.c
+@@ -1717,7 +1717,7 @@ int __acpi_acquire_global_lock(unsigned
+ new = (((old & ~0x3) + 2) + ((old >> 1) & 0x1));
+ val = cmpxchg(lock, old, new);
+ } while (unlikely (val != old));
+- return (new < 3) ? -1 : 0;
++ return ((new & 0x3) < 3) ? -1 : 0;
+ }
+
+ int __acpi_release_global_lock(unsigned int *lock)
--- /dev/null
+From 3c6fd1f07ed03a04debbb9a9d782205f1ef5e2ab Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 8 Apr 2020 16:04:49 +0200
+Subject: ALSA: hda: Add driver blacklist
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 3c6fd1f07ed03a04debbb9a9d782205f1ef5e2ab upstream.
+
+The recent AMD platform exposes an HD-audio bus but without any actual
+codecs, which is internally tied with a USB-audio device, supposedly.
+It results in "no codecs" error of HD-audio bus driver, and it's
+nothing but a waste of resources.
+
+This patch introduces a static blacklist table for skipping such a
+known bogus PCI SSID entry. As of writing this patch, the known SSIDs
+are:
+* 1043:874f - ASUS ROG Zenith II / Strix
+* 1462:cb59 - MSI TRX40 Creator
+* 1462:cb60 - MSI TRX40
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206543
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200408140449.22319-2-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/hda_intel.c | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -1971,6 +1971,17 @@ static const struct hdac_io_ops pci_hda_
+ .dma_free_pages = dma_free_pages,
+ };
+
++/* Blacklist for skipping the whole probe:
++ * some HD-audio PCI entries are exposed without any codecs, and such devices
++ * should be ignored from the beginning.
++ */
++static const struct snd_pci_quirk driver_blacklist[] = {
++ SND_PCI_QUIRK(0x1043, 0x874f, "ASUS ROG Zenith II / Strix", 0),
++ SND_PCI_QUIRK(0x1462, 0xcb59, "MSI TRX40 Creator", 0),
++ SND_PCI_QUIRK(0x1462, 0xcb60, "MSI TRX40", 0),
++ {}
++};
++
+ static const struct hda_controller_ops pci_hda_ops = {
+ .disable_msi_reset_irq = disable_msi_reset_irq,
+ .substream_alloc_pages = substream_alloc_pages,
+@@ -1990,6 +2001,11 @@ static int azx_probe(struct pci_dev *pci
+ bool schedule_probe;
+ int err;
+
++ if (snd_pci_quirk_lookup(pci, driver_blacklist)) {
++ dev_info(&pci->dev, "Skipping the blacklisted device\n");
++ return -ENODEV;
++ }
++
+ if (dev >= SNDRV_CARDS)
+ return -ENODEV;
+ if (!enable[dev]) {
--- /dev/null
+From 0ad3f0b384d58f3bd1f4fb87d0af5b8f6866f41a Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 7 Apr 2020 10:44:01 +0200
+Subject: ALSA: hda: Fix potential access overflow in beep helper
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 0ad3f0b384d58f3bd1f4fb87d0af5b8f6866f41a upstream.
+
+The beep control helper function blindly stores the values in two
+stereo channels no matter whether the actual control is mono or
+stereo. This is practically harmless, but it annoys the recently
+introduced sanity check, resulting in an error when the checker is
+enabled.
+
+This patch corrects the behavior to store only on the defined array
+member.
+
+Fixes: 0401e8548eac ("ALSA: hda - Move beep helper functions to hda_beep.c")
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207139
+Reviewed-by: Jaroslav Kysela <perex@perex.cz>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200407084402.25589-2-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/hda_beep.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/sound/pci/hda/hda_beep.c
++++ b/sound/pci/hda/hda_beep.c
+@@ -310,8 +310,12 @@ int snd_hda_mixer_amp_switch_get_beep(st
+ {
+ struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+ struct hda_beep *beep = codec->beep;
++ int chs = get_amp_channels(kcontrol);
++
+ if (beep && (!beep->enabled || !ctl_has_mute(kcontrol))) {
+- ucontrol->value.integer.value[0] =
++ if (chs & 1)
++ ucontrol->value.integer.value[0] = beep->enabled;
++ if (chs & 2)
+ ucontrol->value.integer.value[1] = beep->enabled;
+ return 0;
+ }
--- /dev/null
+From c47914c00be346bc5b48c48de7b0da5c2d1a296c Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Tue, 7 Apr 2020 10:44:02 +0200
+Subject: ALSA: ice1724: Fix invalid access for enumerated ctl items
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit c47914c00be346bc5b48c48de7b0da5c2d1a296c upstream.
+
+The access to Analog Capture Source control value implemented in
+prodigy_hifi.c is wrong, as caught by the recently introduced sanity
+check; it should be accessing value.enumerated.item[] instead of
+value.integer.value[]. This patch corrects the wrong access pattern.
+
+Fixes: 6b8d6e5518e2 ("[ALSA] ICE1724: Added support for Audiotrak Prodigy 7.1 HiFi & HD2, Hercules Fortissimo IV")
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207139
+Reviewed-by: Jaroslav Kysela <perex@perex.cz>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200407084402.25589-3-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/ice1712/prodigy_hifi.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/pci/ice1712/prodigy_hifi.c
++++ b/sound/pci/ice1712/prodigy_hifi.c
+@@ -569,7 +569,7 @@ static int wm_adc_mux_enum_get(struct sn
+ struct snd_ice1712 *ice = snd_kcontrol_chip(kcontrol);
+
+ mutex_lock(&ice->gpio_mutex);
+- ucontrol->value.integer.value[0] = wm_get(ice, WM_ADC_MUX) & 0x1f;
++ ucontrol->value.enumerated.item[0] = wm_get(ice, WM_ADC_MUX) & 0x1f;
+ mutex_unlock(&ice->gpio_mutex);
+ return 0;
+ }
+@@ -583,7 +583,7 @@ static int wm_adc_mux_enum_put(struct sn
+
+ mutex_lock(&ice->gpio_mutex);
+ oval = wm_get(ice, WM_ADC_MUX);
+- nval = (oval & 0xe0) | ucontrol->value.integer.value[0];
++ nval = (oval & 0xe0) | ucontrol->value.enumerated.item[0];
+ if (nval != oval) {
+ wm_put(ice, WM_ADC_MUX, nval);
+ change = 1;
--- /dev/null
+From ae769d3556644888c964635179ef192995f40793 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Fri, 3 Apr 2020 09:25:15 +0200
+Subject: ALSA: pcm: oss: Fix regression by buffer overflow fix
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit ae769d3556644888c964635179ef192995f40793 upstream.
+
+The recent fix for the OOB access in PCM OSS plugins (commit
+f2ecf903ef06: "ALSA: pcm: oss: Avoid plugin buffer overflow") caused a
+regression on OSS applications. The patch introduced the size check
+in client and slave size calculations to limit to each plugin's buffer
+size, but I overlooked that some code paths call those without
+allocating the buffer but just for estimation.
+
+This patch fixes the bug by skipping the size check for those code
+paths while keeping checking in the actual transfer calls.
+
+Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
+Tested-and-reported-by: Jari Ruusu <jari.ruusu@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200403072515.25539-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_plugin.c | 32 ++++++++++++++++++++++++--------
+ 1 file changed, 24 insertions(+), 8 deletions(-)
+
+--- a/sound/core/oss/pcm_plugin.c
++++ b/sound/core/oss/pcm_plugin.c
+@@ -196,7 +196,9 @@ int snd_pcm_plugin_free(struct snd_pcm_p
+ return 0;
+ }
+
+-snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug, snd_pcm_uframes_t drv_frames)
++static snd_pcm_sframes_t plug_client_size(struct snd_pcm_substream *plug,
++ snd_pcm_uframes_t drv_frames,
++ bool check_size)
+ {
+ struct snd_pcm_plugin *plugin, *plugin_prev, *plugin_next;
+ int stream;
+@@ -209,7 +211,7 @@ snd_pcm_sframes_t snd_pcm_plug_client_si
+ if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ plugin = snd_pcm_plug_last(plug);
+ while (plugin && drv_frames > 0) {
+- if (drv_frames > plugin->buf_frames)
++ if (check_size && drv_frames > plugin->buf_frames)
+ drv_frames = plugin->buf_frames;
+ plugin_prev = plugin->prev;
+ if (plugin->src_frames)
+@@ -222,7 +224,7 @@ snd_pcm_sframes_t snd_pcm_plug_client_si
+ plugin_next = plugin->next;
+ if (plugin->dst_frames)
+ drv_frames = plugin->dst_frames(plugin, drv_frames);
+- if (drv_frames > plugin->buf_frames)
++ if (check_size && drv_frames > plugin->buf_frames)
+ drv_frames = plugin->buf_frames;
+ plugin = plugin_next;
+ }
+@@ -231,7 +233,9 @@ snd_pcm_sframes_t snd_pcm_plug_client_si
+ return drv_frames;
+ }
+
+-snd_pcm_sframes_t snd_pcm_plug_slave_size(struct snd_pcm_substream *plug, snd_pcm_uframes_t clt_frames)
++static snd_pcm_sframes_t plug_slave_size(struct snd_pcm_substream *plug,
++ snd_pcm_uframes_t clt_frames,
++ bool check_size)
+ {
+ struct snd_pcm_plugin *plugin, *plugin_prev, *plugin_next;
+ snd_pcm_sframes_t frames;
+@@ -252,14 +256,14 @@ snd_pcm_sframes_t snd_pcm_plug_slave_siz
+ if (frames < 0)
+ return frames;
+ }
+- if (frames > plugin->buf_frames)
++ if (check_size && frames > plugin->buf_frames)
+ frames = plugin->buf_frames;
+ plugin = plugin_next;
+ }
+ } else if (stream == SNDRV_PCM_STREAM_CAPTURE) {
+ plugin = snd_pcm_plug_last(plug);
+ while (plugin) {
+- if (frames > plugin->buf_frames)
++ if (check_size && frames > plugin->buf_frames)
+ frames = plugin->buf_frames;
+ plugin_prev = plugin->prev;
+ if (plugin->src_frames) {
+@@ -274,6 +278,18 @@ snd_pcm_sframes_t snd_pcm_plug_slave_siz
+ return frames;
+ }
+
++snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug,
++ snd_pcm_uframes_t drv_frames)
++{
++ return plug_client_size(plug, drv_frames, false);
++}
++
++snd_pcm_sframes_t snd_pcm_plug_slave_size(struct snd_pcm_substream *plug,
++ snd_pcm_uframes_t clt_frames)
++{
++ return plug_slave_size(plug, clt_frames, false);
++}
++
+ static int snd_pcm_plug_formats(struct snd_mask *mask, snd_pcm_format_t format)
+ {
+ struct snd_mask formats = *mask;
+@@ -628,7 +644,7 @@ snd_pcm_sframes_t snd_pcm_plug_write_tra
+ src_channels = dst_channels;
+ plugin = next;
+ }
+- return snd_pcm_plug_client_size(plug, frames);
++ return plug_client_size(plug, frames, true);
+ }
+
+ snd_pcm_sframes_t snd_pcm_plug_read_transfer(struct snd_pcm_substream *plug, struct snd_pcm_plugin_channel *dst_channels_final, snd_pcm_uframes_t size)
+@@ -638,7 +654,7 @@ snd_pcm_sframes_t snd_pcm_plug_read_tran
+ snd_pcm_sframes_t frames = size;
+ int err;
+
+- frames = snd_pcm_plug_slave_size(plug, frames);
++ frames = plug_slave_size(plug, frames, true);
+ if (frames < 0)
+ return frames;
+
--- /dev/null
+From 2a48218f8e23d47bd3e23cfdfb8aa9066f7dc3e6 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 8 Apr 2020 16:04:48 +0200
+Subject: ALSA: usb-audio: Add mixer workaround for TRX40 and co
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 2a48218f8e23d47bd3e23cfdfb8aa9066f7dc3e6 upstream.
+
+Some recent boards (supposedly with a new AMD platform) contain the
+USB audio class 2 device that is often tied with HD-audio. The device
+exposes an Input Gain Pad control (id=19, control=12) but this node
+doesn't behave correctly, returning an error for each inquiry of
+GET_MIN and GET_MAX that should have been mandatory.
+
+As a workaround, simply ignore this node by adding a usbmix_name_map
+table entry. The currently known devices are:
+* 0414:a002 - Gigabyte TRX40 Aorus Pro WiFi
+* 0b05:1916 - ASUS ROG Zenith II
+* 0b05:1917 - ASUS ROG Strix
+* 0db0:0d64 - MSI TRX40 Creator
+* 0db0:543d - MSI TRX40
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206543
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20200408140449.22319-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/mixer_maps.c | 28 ++++++++++++++++++++++++++++
+ 1 file changed, 28 insertions(+)
+
+--- a/sound/usb/mixer_maps.c
++++ b/sound/usb/mixer_maps.c
+@@ -363,6 +363,14 @@ static const struct usbmix_name_map dell
+ { 0 }
+ };
+
++/* Some mobos shipped with a dummy HD-audio show the invalid GET_MIN/GET_MAX
++ * response for Input Gain Pad (id=19, control=12). Skip it.
++ */
++static const struct usbmix_name_map asus_rog_map[] = {
++ { 19, NULL, 12 }, /* FU, Input Gain Pad */
++ {}
++};
++
+ /*
+ * Control map entries
+ */
+@@ -482,6 +490,26 @@ static struct usbmix_ctl_map usbmix_ctl_
+ .id = USB_ID(0x05a7, 0x1020),
+ .map = bose_companion5_map,
+ },
++ { /* Gigabyte TRX40 Aorus Pro WiFi */
++ .id = USB_ID(0x0414, 0xa002),
++ .map = asus_rog_map,
++ },
++ { /* ASUS ROG Zenith II */
++ .id = USB_ID(0x0b05, 0x1916),
++ .map = asus_rog_map,
++ },
++ { /* ASUS ROG Strix */
++ .id = USB_ID(0x0b05, 0x1917),
++ .map = asus_rog_map,
++ },
++ { /* MSI TRX40 Creator */
++ .id = USB_ID(0x0db0, 0x0d64),
++ .map = asus_rog_map,
++ },
++ { /* MSI TRX40 */
++ .id = USB_ID(0x0db0, 0x543d),
++ .map = asus_rog_map,
++ },
+ { 0 } /* terminator */
+ };
+
--- /dev/null
+From 968ae2caad0782db5dbbabb560d3cdefd2945d38 Mon Sep 17 00:00:00 2001
+From: Remi Pommarel <repk@triplefau.lt>
+Date: Sat, 29 Feb 2020 17:13:47 +0100
+Subject: ath9k: Handle txpower changes even when TPC is disabled
+
+From: Remi Pommarel <repk@triplefau.lt>
+
+commit 968ae2caad0782db5dbbabb560d3cdefd2945d38 upstream.
+
+When TPC is disabled IEEE80211_CONF_CHANGE_POWER event can be handled to
+reconfigure HW's maximum txpower.
+
+This fixes 0dBm txpower setting when user attaches to an interface for
+the first time with the following scenario:
+
+ieee80211_do_open()
+ ath9k_add_interface()
+ ath9k_set_txpower() /* Set TX power with not yet initialized
+ sc->hw->conf.power_level */
+
+ ieee80211_hw_config() /* Iniatilize sc->hw->conf.power_level and
+ raise IEEE80211_CONF_CHANGE_POWER */
+
+ ath9k_config() /* IEEE80211_CONF_CHANGE_POWER is ignored */
+
+This issue can be reproduced with the following:
+
+ $ modprobe -r ath9k
+ $ modprobe ath9k
+ $ wpa_supplicant -i wlan0 -c /tmp/wpa.conf &
+ $ iw dev /* Here TX power is either 0 or 3 depending on RF chain */
+ $ killall wpa_supplicant
+ $ iw dev /* TX power goes back to calibrated value and subsequent
+ calls will be fine */
+
+Fixes: 283dd11994cde ("ath9k: add per-vif TX power capability")
+Cc: stable@vger.kernel.org
+Signed-off-by: Remi Pommarel <repk@triplefau.lt>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/ath/ath9k/main.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/net/wireless/ath/ath9k/main.c
++++ b/drivers/net/wireless/ath/ath9k/main.c
+@@ -1455,6 +1455,9 @@ static int ath9k_config(struct ieee80211
+ ath_chanctx_set_channel(sc, ctx, &hw->conf.chandef);
+ }
+
++ if (changed & IEEE80211_CONF_CHANGE_POWER)
++ ath9k_set_txpower(sc, NULL);
++
+ mutex_unlock(&sc->mutex);
+ ath9k_ps_restore(sc);
+
--- /dev/null
+From 6a214a28132f19ace3d835a6d8f6422ec80ad200 Mon Sep 17 00:00:00 2001
+From: Sungbo Eo <mans0n@gorani.run>
+Date: Sat, 21 Mar 2020 22:38:42 +0900
+Subject: irqchip/versatile-fpga: Apply clear-mask earlier
+
+From: Sungbo Eo <mans0n@gorani.run>
+
+commit 6a214a28132f19ace3d835a6d8f6422ec80ad200 upstream.
+
+Clear its own IRQs before the parent IRQ get enabled, so that the
+remaining IRQs do not accidentally interrupt the parent IRQ controller.
+
+This patch also fixes a reboot bug on OX820 SoC, where the remaining
+rps-timer IRQ raises a GIC interrupt that is left pending. After that,
+the rps-timer IRQ is cleared during driver initialization, and there's
+no IRQ left in rps-irq when local_irq_enable() is called, which evokes
+an error message "unexpected IRQ trap".
+
+Fixes: bdd272cbb97a ("irqchip: versatile FPGA: support cascaded interrupts from DT")
+Signed-off-by: Sungbo Eo <mans0n@gorani.run>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20200321133842.2408823-1-mans0n@gorani.run
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/irqchip/irq-versatile-fpga.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/irqchip/irq-versatile-fpga.c
++++ b/drivers/irqchip/irq-versatile-fpga.c
+@@ -211,6 +211,9 @@ int __init fpga_irq_of_init(struct devic
+ if (of_property_read_u32(node, "valid-mask", &valid_mask))
+ valid_mask = 0;
+
++ writel(clear_mask, base + IRQ_ENABLE_CLEAR);
++ writel(clear_mask, base + FIQ_ENABLE_CLEAR);
++
+ /* Some chips are cascaded from a parent IRQ */
+ parent_irq = irq_of_parse_and_map(node, 0);
+ if (!parent_irq) {
+@@ -220,9 +223,6 @@ int __init fpga_irq_of_init(struct devic
+
+ fpga_irq_init(base, node->name, 0, parent_irq, valid_mask, node);
+
+- writel(clear_mask, base + IRQ_ENABLE_CLEAR);
+- writel(clear_mask, base + FIQ_ENABLE_CLEAR);
+-
+ /*
+ * On Versatile AB/PB, some secondary interrupts have a direct
+ * pass-thru to the primary controller for IRQs 20 and 22-31 which need
--- /dev/null
+From 2e356101e72ab1361821b3af024d64877d9a798d Mon Sep 17 00:00:00 2001
+From: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
+Date: Fri, 28 Feb 2020 12:41:51 +0800
+Subject: KEYS: reaching the keys quotas correctly
+
+From: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
+
+commit 2e356101e72ab1361821b3af024d64877d9a798d upstream.
+
+Currently, when we add a new user key, the calltrace as below:
+
+add_key()
+ key_create_or_update()
+ key_alloc()
+ __key_instantiate_and_link
+ generic_key_instantiate
+ key_payload_reserve
+ ......
+
+Since commit a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly"),
+we can reach max bytes/keys in key_alloc, but we forget to remove this
+limit when we reserver space for payload in key_payload_reserve. So we
+can only reach max keys but not max bytes when having delta between plen
+and type->def_datalen. Remove this limit when instantiating the key, so we
+can keep consistent with key_alloc.
+
+Also, fix the similar problem in keyctl_chown_key().
+
+Fixes: 0b77f5bfb45c ("keys: make the keyring quotas controllable through /proc/sys")
+Fixes: a08bf91ce28e ("KEYS: allow reaching the keys quotas exactly")
+Cc: stable@vger.kernel.org # 5.0.x
+Cc: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
+Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Reviewed-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/keys/key.c | 2 +-
+ security/keys/keyctl.c | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+--- a/security/keys/key.c
++++ b/security/keys/key.c
+@@ -382,7 +382,7 @@ int key_payload_reserve(struct key *key,
+ spin_lock(&key->user->lock);
+
+ if (delta > 0 &&
+- (key->user->qnbytes + delta >= maxbytes ||
++ (key->user->qnbytes + delta > maxbytes ||
+ key->user->qnbytes + delta < key->user->qnbytes)) {
+ ret = -EDQUOT;
+ }
+--- a/security/keys/keyctl.c
++++ b/security/keys/keyctl.c
+@@ -881,8 +881,8 @@ long keyctl_chown_key(key_serial_t id, u
+ key_quota_root_maxbytes : key_quota_maxbytes;
+
+ spin_lock(&newowner->lock);
+- if (newowner->qnkeys + 1 >= maxkeys ||
+- newowner->qnbytes + key->quotalen >= maxbytes ||
++ if (newowner->qnkeys + 1 > maxkeys ||
++ newowner->qnbytes + key->quotalen > maxbytes ||
+ newowner->qnbytes + key->quotalen <
+ newowner->qnbytes)
+ goto quota_overrun;
--- /dev/null
+From 1db56284b9da9056093681f28db48a09a243274b Mon Sep 17 00:00:00 2001
+From: Benoit Parrot <bparrot@ti.com>
+Date: Mon, 2 Mar 2020 14:56:52 +0100
+Subject: media: ti-vpe: cal: fix disable_irqs to only the intended target
+
+From: Benoit Parrot <bparrot@ti.com>
+
+commit 1db56284b9da9056093681f28db48a09a243274b upstream.
+
+disable_irqs() was mistakenly disabling all interrupts when called.
+This cause all port stream to stop even if only stopping one of them.
+
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Benoit Parrot <bparrot@ti.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/platform/ti-vpe/cal.c | 16 ++++++++--------
+ 1 file changed, 8 insertions(+), 8 deletions(-)
+
+--- a/drivers/media/platform/ti-vpe/cal.c
++++ b/drivers/media/platform/ti-vpe/cal.c
+@@ -548,16 +548,16 @@ static void enable_irqs(struct cal_ctx *
+
+ static void disable_irqs(struct cal_ctx *ctx)
+ {
++ u32 val;
++
+ /* Disable IRQ_WDMA_END 0/1 */
+- reg_write_field(ctx->dev,
+- CAL_HL_IRQENABLE_CLR(2),
+- CAL_HL_IRQ_CLEAR,
+- CAL_HL_IRQ_MASK(ctx->csi2_port));
++ val = 0;
++ set_field(&val, CAL_HL_IRQ_CLEAR, CAL_HL_IRQ_MASK(ctx->csi2_port));
++ reg_write(ctx->dev, CAL_HL_IRQENABLE_CLR(2), val);
+ /* Disable IRQ_WDMA_START 0/1 */
+- reg_write_field(ctx->dev,
+- CAL_HL_IRQENABLE_CLR(3),
+- CAL_HL_IRQ_CLEAR,
+- CAL_HL_IRQ_MASK(ctx->csi2_port));
++ val = 0;
++ set_field(&val, CAL_HL_IRQ_CLEAR, CAL_HL_IRQ_MASK(ctx->csi2_port));
++ reg_write(ctx->dev, CAL_HL_IRQENABLE_CLR(3), val);
+ /* Todo: Add VC_IRQ and CSI2_COMPLEXIO_IRQ handling */
+ reg_write(ctx->dev, CAL_CSI2_VC_IRQENABLE(1), 0);
+ }
--- /dev/null
+From 792a402c2840054533ef56279c212ef6da87d811 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Tue, 22 Jan 2019 14:18:42 -0600
+Subject: MIPS: OCTEON: irq: Fix potential NULL pointer dereference
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit 792a402c2840054533ef56279c212ef6da87d811 upstream.
+
+There is a potential NULL pointer dereference in case kzalloc()
+fails and returns NULL.
+
+Fix this by adding a NULL check on *cd*
+
+This bug was detected with the help of Coccinelle.
+
+Fixes: 64b139f97c01 ("MIPS: OCTEON: irq: add CIB and other fixes")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/cavium-octeon/octeon-irq.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/mips/cavium-octeon/octeon-irq.c
++++ b/arch/mips/cavium-octeon/octeon-irq.c
+@@ -2199,6 +2199,9 @@ static int octeon_irq_cib_map(struct irq
+ }
+
+ cd = kzalloc(sizeof(*cd), GFP_KERNEL);
++ if (!cd)
++ return -ENOMEM;
++
+ cd->host_data = host_data;
+ cd->bit = hw;
+
asoc-dapm-connect-virtual-mux-with-default-value.patch
asoc-dpcm-allow-start-or-stop-during-pause-for-backend.patch
asoc-topology-use-name_prefix-for-new-kcontrol.patch
+usb-gadget-f_fs-fix-use-after-free-issue-as-part-of-queue-failure.patch
+usb-gadget-composite-inform-controller-driver-of-self-powered.patch
+alsa-usb-audio-add-mixer-workaround-for-trx40-and-co.patch
+alsa-hda-add-driver-blacklist.patch
+alsa-hda-fix-potential-access-overflow-in-beep-helper.patch
+alsa-ice1724-fix-invalid-access-for-enumerated-ctl-items.patch
+alsa-pcm-oss-fix-regression-by-buffer-overflow-fix.patch
+media-ti-vpe-cal-fix-disable_irqs-to-only-the-intended-target.patch
+acpi-x86-ignore-unspecified-bit-positions-in-the-acpi-global-lock-field.patch
+thermal-devfreq_cooling-inline-all-stubs-for-config_devfreq_thermal-n.patch
+keys-reaching-the-keys-quotas-correctly.patch
+irqchip-versatile-fpga-apply-clear-mask-earlier.patch
+mips-octeon-irq-fix-potential-null-pointer-dereference.patch
+ath9k-handle-txpower-changes-even-when-tpc-is-disabled.patch
+signal-extend-exec_id-to-64bits.patch
+x86-entry-32-add-missing-asm_clac-to-general_protection-entry.patch
--- /dev/null
+From d1e7fd6462ca9fc76650fbe6ca800e35b24267da Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Mon, 30 Mar 2020 19:01:04 -0500
+Subject: signal: Extend exec_id to 64bits
+
+From: Eric W. Biederman <ebiederm@xmission.com>
+
+commit d1e7fd6462ca9fc76650fbe6ca800e35b24267da upstream.
+
+Replace the 32bit exec_id with a 64bit exec_id to make it impossible
+to wrap the exec_id counter. With care an attacker can cause exec_id
+wrap and send arbitrary signals to a newly exec'd parent. This
+bypasses the signal sending checks if the parent changes their
+credentials during exec.
+
+The severity of this problem can been seen that in my limited testing
+of a 32bit exec_id it can take as little as 19s to exec 65536 times.
+Which means that it can take as little as 14 days to wrap a 32bit
+exec_id. Adam Zabrocki has succeeded wrapping the self_exe_id in 7
+days. Even my slower timing is in the uptime of a typical server.
+Which means self_exec_id is simply a speed bump today, and if exec
+gets noticably faster self_exec_id won't even be a speed bump.
+
+Extending self_exec_id to 64bits introduces a problem on 32bit
+architectures where reading self_exec_id is no longer atomic and can
+take two read instructions. Which means that is is possible to hit
+a window where the read value of exec_id does not match the written
+value. So with very lucky timing after this change this still
+remains expoiltable.
+
+I have updated the update of exec_id on exec to use WRITE_ONCE
+and the read of exec_id in do_notify_parent to use READ_ONCE
+to make it clear that there is no locking between these two
+locations.
+
+Link: https://lore.kernel.org/kernel-hardening/20200324215049.GA3710@pi3.com.pl
+Fixes: 2.3.23pre2
+Cc: stable@vger.kernel.org
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/exec.c | 2 +-
+ include/linux/sched.h | 4 ++--
+ kernel/signal.c | 2 +-
+ 3 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/fs/exec.c
++++ b/fs/exec.c
+@@ -1353,7 +1353,7 @@ void setup_new_exec(struct linux_binprm
+
+ /* An exec changes our domain. We are no longer part of the thread
+ group */
+- current->self_exec_id++;
++ WRITE_ONCE(current->self_exec_id, current->self_exec_id + 1);
+ flush_signal_handlers(current, 0);
+ }
+ EXPORT_SYMBOL(setup_new_exec);
+--- a/include/linux/sched.h
++++ b/include/linux/sched.h
+@@ -1720,8 +1720,8 @@ struct task_struct {
+ struct seccomp seccomp;
+
+ /* Thread group tracking */
+- u32 parent_exec_id;
+- u32 self_exec_id;
++ u64 parent_exec_id;
++ u64 self_exec_id;
+ /* Protection of (de-)allocation: mm, files, fs, tty, keyrings, mems_allowed,
+ * mempolicy */
+ spinlock_t alloc_lock;
+--- a/kernel/signal.c
++++ b/kernel/signal.c
+@@ -1660,7 +1660,7 @@ bool do_notify_parent(struct task_struct
+ * This is only possible if parent == real_parent.
+ * Check if it has changed security domain.
+ */
+- if (tsk->parent_exec_id != tsk->parent->self_exec_id)
++ if (tsk->parent_exec_id != READ_ONCE(tsk->parent->self_exec_id))
+ sig = SIGCHLD;
+ }
+
--- /dev/null
+From 3f5b9959041e0db6dacbea80bb833bff5900999f Mon Sep 17 00:00:00 2001
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Date: Fri, 3 Apr 2020 22:51:33 +0200
+Subject: thermal: devfreq_cooling: inline all stubs for CONFIG_DEVFREQ_THERMAL=n
+
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+commit 3f5b9959041e0db6dacbea80bb833bff5900999f upstream.
+
+When CONFIG_DEVFREQ_THERMAL is disabled all functions except
+of_devfreq_cooling_register_power() were already inlined. Also inline
+the last function to avoid compile errors when multiple drivers call
+of_devfreq_cooling_register_power() when CONFIG_DEVFREQ_THERMAL is not
+set. Compilation failed with the following message:
+ multiple definition of `of_devfreq_cooling_register_power'
+(which then lists all usages of of_devfreq_cooling_register_power())
+
+Thomas Zimmermann reported this problem [0] on a kernel config with
+CONFIG_DRM_LIMA={m,y}, CONFIG_DRM_PANFROST={m,y} and
+CONFIG_DEVFREQ_THERMAL=n after both, the lima and panfrost drivers
+gained devfreq cooling support.
+
+[0] https://www.spinics.net/lists/dri-devel/msg252825.html
+
+Fixes: a76caf55e5b356 ("thermal: Add devfreq cooling")
+Cc: stable@vger.kernel.org
+Reported-by: Thomas Zimmermann <tzimmermann@suse.de>
+Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Tested-by: Thomas Zimmermann <tzimmermann@suse.de>
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Link: https://lore.kernel.org/r/20200403205133.1101808-1-martin.blumenstingl@googlemail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/devfreq_cooling.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/linux/devfreq_cooling.h
++++ b/include/linux/devfreq_cooling.h
+@@ -53,7 +53,7 @@ void devfreq_cooling_unregister(struct t
+
+ #else /* !CONFIG_DEVFREQ_THERMAL */
+
+-struct thermal_cooling_device *
++static inline struct thermal_cooling_device *
+ of_devfreq_cooling_register_power(struct device_node *np, struct devfreq *df,
+ struct devfreq_cooling_power *dfc_power)
+ {
--- /dev/null
+From 5e5caf4fa8d3039140b4548b6ab23dd17fce9b2c Mon Sep 17 00:00:00 2001
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Date: Mon, 3 Feb 2020 18:05:32 -0800
+Subject: usb: gadget: composite: Inform controller driver of self-powered
+
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+
+commit 5e5caf4fa8d3039140b4548b6ab23dd17fce9b2c upstream.
+
+Different configuration/condition may draw different power. Inform the
+controller driver of the change so it can respond properly (e.g.
+GET_STATUS request). This fixes an issue with setting MaxPower from
+configfs. The composite driver doesn't check this value when setting
+self-powered.
+
+Cc: stable@vger.kernel.org
+Fixes: 88af8bbe4ef7 ("usb: gadget: the start of the configfs interface")
+Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
+Signed-off-by: Felipe Balbi <balbi@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/composite.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/usb/gadget/composite.c
++++ b/drivers/usb/gadget/composite.c
+@@ -842,6 +842,11 @@ static int set_config(struct usb_composi
+ else
+ power = min(power, 900U);
+ done:
++ if (power <= USB_SELF_POWER_VBUS_MAX_DRAW)
++ usb_gadget_set_selfpowered(gadget);
++ else
++ usb_gadget_clear_selfpowered(gadget);
++
+ usb_gadget_vbus_draw(gadget, power);
+ if (result >= 0 && cdev->delayed_status)
+ result = USB_GADGET_DELAYED_STATUS;
+@@ -2273,6 +2278,7 @@ void composite_suspend(struct usb_gadget
+
+ cdev->suspended = 1;
+
++ usb_gadget_set_selfpowered(gadget);
+ usb_gadget_vbus_draw(gadget, 2);
+ }
+
+@@ -2301,6 +2307,9 @@ void composite_resume(struct usb_gadget
+ else
+ maxpower = min(maxpower, 900U);
+
++ if (maxpower > USB_SELF_POWER_VBUS_MAX_DRAW)
++ usb_gadget_clear_selfpowered(gadget);
++
+ usb_gadget_vbus_draw(gadget, maxpower);
+ }
+
--- /dev/null
+From f63ec55ff904b2f2e126884fcad93175f16ab4bb Mon Sep 17 00:00:00 2001
+From: Sriharsha Allenki <sallenki@codeaurora.org>
+Date: Thu, 26 Mar 2020 17:26:20 +0530
+Subject: usb: gadget: f_fs: Fix use after free issue as part of queue failure
+
+From: Sriharsha Allenki <sallenki@codeaurora.org>
+
+commit f63ec55ff904b2f2e126884fcad93175f16ab4bb upstream.
+
+In AIO case, the request is freed up if ep_queue fails.
+However, io_data->req still has the reference to this freed
+request. In the case of this failure if there is aio_cancel
+call on this io_data it will lead to an invalid dequeue
+operation and a potential use after free issue.
+Fix this by setting the io_data->req to NULL when the request
+is freed as part of queue failure.
+
+Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support")
+Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
+CC: stable <stable@vger.kernel.org>
+Reviewed-by: Peter Chen <peter.chen@nxp.com>
+Link: https://lore.kernel.org/r/20200326115620.12571-1-sallenki@codeaurora.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/gadget/function/f_fs.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/usb/gadget/function/f_fs.c
++++ b/drivers/usb/gadget/function/f_fs.c
+@@ -1036,6 +1036,7 @@ static ssize_t ffs_epfile_io(struct file
+
+ ret = usb_ep_queue(ep->ep, req, GFP_ATOMIC);
+ if (unlikely(ret)) {
++ io_data->req = NULL;
+ usb_ep_free_request(ep->ep, req);
+ goto error_lock;
+ }
--- /dev/null
+From 3d51507f29f2153a658df4a0674ec5b592b62085 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 25 Feb 2020 22:36:37 +0100
+Subject: x86/entry/32: Add missing ASM_CLAC to general_protection entry
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 3d51507f29f2153a658df4a0674ec5b592b62085 upstream.
+
+All exception entry points must have ASM_CLAC right at the
+beginning. The general_protection entry is missing one.
+
+Fixes: e59d1b0a2419 ("x86-32, smap: Add STAC/CLAC instructions to 32-bit kernel entry")
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
+Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
+Reviewed-by: Andy Lutomirski <luto@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20200225220216.219537887@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/entry/entry_32.S | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/entry/entry_32.S
++++ b/arch/x86/entry/entry_32.S
+@@ -1195,6 +1195,7 @@ ENTRY(int3)
+ END(int3)
+
+ ENTRY(general_protection)
++ ASM_CLAC
+ pushl $do_general_protection
+ jmp error_code
+ END(general_protection)
projects / thirdparty / kernel / stable-queue.git / commitdiff
