From 9ed866e598c956e35fe61be1f73db1840d437e6c Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 25 Mar 2022 10:50:06 +0100 Subject: [PATCH] 5.4-stable patches added patches: alsa-cmipci-restore-aux-vol-on-suspend-resume.patch alsa-hda-realtek-add-quirk-for-asus-ga402.patch alsa-hda-realtek-fix-headset-mic-problem-for-a-hp-machine-with-alc671.patch alsa-oss-fix-pcm-oss-buffer-allocation-overflow.patch alsa-pci-fix-reading-of-swapped-values-from-pcmreg-in-ac97-codec.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 asoc-sti-fix-deadlock-via-snd_pcm_stop_xrun-call.patch drivers-net-xgene-fix-regression-in-crc-stripping.patch llc-fix-netdevice-reference-leaks-in-llc_ui_bind.patch netfilter-nf_tables-initialize-registers-in-nft_do_chain.patch swiotlb-fix-info-leak-with-dma_from_device.patch swiotlb-rework-fix-info-leak-with-dma_from_device.patch thermal-int340x-fix-memory-leak-in-int3400_notify.patch --- ...ci-restore-aux-vol-on-suspend-resume.patch | 43 ++++++ ...hda-realtek-add-quirk-for-asus-ga402.patch | 31 +++++ ...problem-for-a-hp-machine-with-alc671.patch | 32 +++++ ...x-pcm-oss-buffer-allocation-overflow.patch | 83 ++++++++++++ ...ped-values-from-pcmreg-in-ac97-codec.patch | 56 ++++++++ ...ck-during-pcm-reset-ioctl-operations.patch | 53 ++++++++ ...-for-playback-volumes-on-rode-nt-usb.patch | 41 ++++++ ...-deadlock-via-snd_pcm_stop_xrun-call.patch | 74 +++++++++++ ...gene-fix-regression-in-crc-stripping.patch | 57 ++++++++ ...evice-reference-leaks-in-llc_ui_bind.patch | 55 ++++++++ ...initialize-registers-in-nft_do_chain.patch | 29 +++++ queue-5.4/series | 14 ++ ...b-fix-info-leak-with-dma_from_device.patch | 104 +++++++++++++++ ...k-fix-info-leak-with-dma_from_device.patch | 123 ++++++++++++++++++ ...0x-fix-memory-leak-in-int3400_notify.patch | 54 ++++++++ 15 files changed, 849 insertions(+) create mode 100644 queue-5.4/alsa-cmipci-restore-aux-vol-on-suspend-resume.patch create mode 100644 queue-5.4/alsa-hda-realtek-add-quirk-for-asus-ga402.patch create mode 100644 queue-5.4/alsa-hda-realtek-fix-headset-mic-problem-for-a-hp-machine-with-alc671.patch create mode 100644 queue-5.4/alsa-oss-fix-pcm-oss-buffer-allocation-overflow.patch create mode 100644 queue-5.4/alsa-pci-fix-reading-of-swapped-values-from-pcmreg-in-ac97-codec.patch create mode 100644 queue-5.4/alsa-pcm-add-stream-lock-during-pcm-reset-ioctl-operations.patch create mode 100644 queue-5.4/alsa-usb-audio-add-mute-tlv-for-playback-volumes-on-rode-nt-usb.patch create mode 100644 queue-5.4/asoc-sti-fix-deadlock-via-snd_pcm_stop_xrun-call.patch create mode 100644 queue-5.4/drivers-net-xgene-fix-regression-in-crc-stripping.patch create mode 100644 queue-5.4/llc-fix-netdevice-reference-leaks-in-llc_ui_bind.patch create mode 100644 queue-5.4/netfilter-nf_tables-initialize-registers-in-nft_do_chain.patch create mode 100644 queue-5.4/swiotlb-fix-info-leak-with-dma_from_device.patch create mode 100644 queue-5.4/swiotlb-rework-fix-info-leak-with-dma_from_device.patch create mode 100644 queue-5.4/thermal-int340x-fix-memory-leak-in-int3400_notify.patch diff --git a/queue-5.4/alsa-cmipci-restore-aux-vol-on-suspend-resume.patch b/queue-5.4/alsa-cmipci-restore-aux-vol-on-suspend-resume.patch new file mode 100644 index 00000000000..4842f0dd4b9 --- /dev/null +++ b/queue-5.4/alsa-cmipci-restore-aux-vol-on-suspend-resume.patch @@ -0,0 +1,43 @@ +From c14231cc04337c2c2a937db084af342ce704dbde Mon Sep 17 00:00:00 2001 +From: Jonathan Teh +Date: Sun, 13 Mar 2022 19:56:17 +0000 +Subject: ALSA: cmipci: Restore aux vol on suspend/resume + +From: Jonathan Teh + +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 +Cc: +Link: https://lore.kernel.org/r/DBAPR04MB7366CB3EA9C8521C35C56E8B920E9@DBAPR04MB7366.eurprd04.prod.outlook.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.4/alsa-hda-realtek-add-quirk-for-asus-ga402.patch b/queue-5.4/alsa-hda-realtek-add-quirk-for-asus-ga402.patch new file mode 100644 index 00000000000..418f44cabb5 --- /dev/null +++ b/queue-5.4/alsa-hda-realtek-add-quirk-for-asus-ga402.patch @@ -0,0 +1,31 @@ +From b7557267c233b55d8e8d7ba4c68cf944fe2ec02c Mon Sep 17 00:00:00 2001 +From: Jason Zheng +Date: Sun, 13 Mar 2022 04:22:16 -0500 +Subject: ALSA: hda/realtek: Add quirk for ASUS GA402 + +From: Jason Zheng + +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 +Cc: +Link: https://lore.kernel.org/r/20220313092216.29858-1-jasonzheng2004@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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), diff --git a/queue-5.4/alsa-hda-realtek-fix-headset-mic-problem-for-a-hp-machine-with-alc671.patch b/queue-5.4/alsa-hda-realtek-fix-headset-mic-problem-for-a-hp-machine-with-alc671.patch new file mode 100644 index 00000000000..634bf927bd3 --- /dev/null +++ b/queue-5.4/alsa-hda-realtek-fix-headset-mic-problem-for-a-hp-machine-with-alc671.patch @@ -0,0 +1,32 @@ +From 882bd07f564f97fca6e42ce6ce627ce24ce1ef5a Mon Sep 17 00:00:00 2001 +From: huangwenhui +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 + +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 +Cc: +Link: https://lore.kernel.org/r/20220311093836.20754-1-huangwenhuia@uniontech.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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), diff --git a/queue-5.4/alsa-oss-fix-pcm-oss-buffer-allocation-overflow.patch b/queue-5.4/alsa-oss-fix-pcm-oss-buffer-allocation-overflow.patch new file mode 100644 index 00000000000..6f70f201cca --- /dev/null +++ b/queue-5.4/alsa-oss-fix-pcm-oss-buffer-allocation-overflow.patch @@ -0,0 +1,83 @@ +From efb6402c3c4a7c26d97c92d70186424097b6e366 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Fri, 18 Mar 2022 09:20:36 +0100 +Subject: ALSA: oss: Fix PCM OSS buffer allocation overflow + +From: Takashi Iwai + +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 +Cc: +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.4/alsa-pci-fix-reading-of-swapped-values-from-pcmreg-in-ac97-codec.patch b/queue-5.4/alsa-pci-fix-reading-of-swapped-values-from-pcmreg-in-ac97-codec.patch new file mode 100644 index 00000000000..8b8261a1ddd --- /dev/null +++ b/queue-5.4/alsa-pci-fix-reading-of-swapped-values-from-pcmreg-in-ac97-codec.patch @@ -0,0 +1,56 @@ +From 17aaf0193392cb3451bf0ac75ba396ec4cbded6e Mon Sep 17 00:00:00 2001 +From: Giacomo Guiduzzi +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 + +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 +Signed-off-by: Paolo Valente +Cc: +Link: https://lore.kernel.org/r/20220322200653.15862-1-guiduzzi.giacomo@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.4/alsa-pcm-add-stream-lock-during-pcm-reset-ioctl-operations.patch b/queue-5.4/alsa-pcm-add-stream-lock-during-pcm-reset-ioctl-operations.patch new file mode 100644 index 00000000000..6d95ec09ff8 --- /dev/null +++ b/queue-5.4/alsa-pcm-add-stream-lock-during-pcm-reset-ioctl-operations.patch @@ -0,0 +1,53 @@ +From 1f68915b2efd0d6bfd6e124aa63c94b3c69f127c Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Tue, 22 Mar 2022 18:13:25 +0100 +Subject: ALSA: pcm: Add stream lock during PCM reset ioctl operations + +From: Takashi Iwai + +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: +Reviewed-by: Jaroslav Kysela +Link: https://lore.kernel.org/r/20220322171325.4355-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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 = { diff --git a/queue-5.4/alsa-usb-audio-add-mute-tlv-for-playback-volumes-on-rode-nt-usb.patch b/queue-5.4/alsa-usb-audio-add-mute-tlv-for-playback-volumes-on-rode-nt-usb.patch new file mode 100644 index 00000000000..bae3e0b5b35 --- /dev/null +++ b/queue-5.4/alsa-usb-audio-add-mute-tlv-for-playback-volumes-on-rode-nt-usb.patch @@ -0,0 +1,41 @@ +From 0f306cca42fe879694fb5e2382748c43dc9e0196 Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +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 + +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 +Cc: +Link: https://lore.kernel.org/r/20220311201400.235892-1-lars@metafoo.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.4/asoc-sti-fix-deadlock-via-snd_pcm_stop_xrun-call.patch b/queue-5.4/asoc-sti-fix-deadlock-via-snd_pcm_stop_xrun-call.patch new file mode 100644 index 00000000000..2eea844908a --- /dev/null +++ b/queue-5.4/asoc-sti-fix-deadlock-via-snd_pcm_stop_xrun-call.patch @@ -0,0 +1,74 @@ +From 455c5653f50e10b4f460ef24e99f0044fbe3401c Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Tue, 15 Mar 2022 17:41:58 +0100 +Subject: ASoC: sti: Fix deadlock via snd_pcm_stop_xrun() call + +From: Takashi Iwai + +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 +Cc: Arnaud POULIQUEN +Cc: +Link: https://lore.kernel.org/r/20220315091319.3351522-1-daniel@0x0f.com +Signed-off-by: Takashi Iwai +Reviewed-by: Arnaud Pouliquen +Link: https://lore.kernel.org/r/20220315164158.19804-1-tiwai@suse.de +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.4/drivers-net-xgene-fix-regression-in-crc-stripping.patch b/queue-5.4/drivers-net-xgene-fix-regression-in-crc-stripping.patch new file mode 100644 index 00000000000..b92be010525 --- /dev/null +++ b/queue-5.4/drivers-net-xgene-fix-regression-in-crc-stripping.patch @@ -0,0 +1,57 @@ +From e9e6faeafaa00da1851bcf47912b0f1acae666b4 Mon Sep 17 00:00:00 2001 +From: Stephane Graber +Date: Tue, 22 Mar 2022 18:42:06 -0400 +Subject: drivers: net: xgene: Fix regression in CRC stripping + +From: Stephane Graber + +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 +Tested-by: Stephane Graber +Link: https://lore.kernel.org/r/20220322224205.752795-1-stgraber@ubuntu.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.4/llc-fix-netdevice-reference-leaks-in-llc_ui_bind.patch b/queue-5.4/llc-fix-netdevice-reference-leaks-in-llc_ui_bind.patch new file mode 100644 index 00000000000..017bde6705e --- /dev/null +++ b/queue-5.4/llc-fix-netdevice-reference-leaks-in-llc_ui_bind.patch @@ -0,0 +1,55 @@ +From 764f4eb6846f5475f1244767d24d25dd86528a4a Mon Sep 17 00:00:00 2001 +From: Eric Dumazet +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 + +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 +Reported-by: 赵子轩 +Reported-by: Stoyan Manolov +Link: https://lore.kernel.org/r/20220323004147.1990845-1-eric.dumazet@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.4/netfilter-nf_tables-initialize-registers-in-nft_do_chain.patch b/queue-5.4/netfilter-nf_tables-initialize-registers-in-nft_do_chain.patch new file mode 100644 index 00000000000..2a9c47decda --- /dev/null +++ b/queue-5.4/netfilter-nf_tables-initialize-registers-in-nft_do_chain.patch @@ -0,0 +1,29 @@ +From 4c905f6740a365464e91467aa50916555b28213d Mon Sep 17 00:00:00 2001 +From: Pablo Neira Ayuso +Date: Thu, 17 Mar 2022 12:04:42 +0100 +Subject: netfilter: nf_tables: initialize registers in nft_do_chain() + +From: Pablo Neira Ayuso + +commit 4c905f6740a365464e91467aa50916555b28213d upstream. + +Initialize registers to avoid stack leak into userspace. + +Fixes: 96518518cc41 ("netfilter: add nftables") +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.4/series b/queue-5.4/series index b35a5c56f01..e8fc479e7b2 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -5,3 +5,17 @@ net-ipv6-fix-skb_over_panic-in-__ip6_append_data.patch 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 diff --git a/queue-5.4/swiotlb-fix-info-leak-with-dma_from_device.patch b/queue-5.4/swiotlb-fix-info-leak-with-dma_from_device.patch new file mode 100644 index 00000000000..dd68c42c956 --- /dev/null +++ b/queue-5.4/swiotlb-fix-info-leak-with-dma_from_device.patch @@ -0,0 +1,104 @@ +From ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e Mon Sep 17 00:00:00 2001 +From: Halil Pasic +Date: Fri, 11 Feb 2022 02:12:52 +0100 +Subject: swiotlb: fix info leak with DMA_FROM_DEVICE + +From: Halil Pasic + +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 +Signed-off-by: Christoph Hellwig +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.4/swiotlb-rework-fix-info-leak-with-dma_from_device.patch b/queue-5.4/swiotlb-rework-fix-info-leak-with-dma_from_device.patch new file mode 100644 index 00000000000..db413987bb6 --- /dev/null +++ b/queue-5.4/swiotlb-rework-fix-info-leak-with-dma_from_device.patch @@ -0,0 +1,123 @@ +From aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 Mon Sep 17 00:00:00 2001 +From: Halil Pasic +Date: Sat, 5 Mar 2022 18:07:14 +0100 +Subject: swiotlb: rework "fix info leak with DMA_FROM_DEVICE" + +From: Halil Pasic + +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 +Fixes: ddbd89deb7d3 ("swiotlb: fix info leak with DMA_FROM_DEVICE") +Cc: stable@vger.kernel.org +Reviewed-by: Christoph Hellwig +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + 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(); diff --git a/queue-5.4/thermal-int340x-fix-memory-leak-in-int3400_notify.patch b/queue-5.4/thermal-int340x-fix-memory-leak-in-int3400_notify.patch new file mode 100644 index 00000000000..3907aadb5da --- /dev/null +++ b/queue-5.4/thermal-int340x-fix-memory-leak-in-int3400_notify.patch @@ -0,0 +1,54 @@ +From foo@baz Fri Mar 25 10:09:45 AM CET 2022 +From: Chuansheng Liu +Date: Wed, 23 Feb 2022 08:20:24 +0800 +Subject: thermal: int340x: fix memory leak in int3400_notify() + +From: Chuansheng Liu + +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: + [] __kmalloc_track_caller+0x2fe/0x4a0 + [] kvasprintf+0x65/0xd0 + [] kasprintf+0x4e/0x70 + [] int3400_notify+0x82/0x120 [int3400_thermal] + [] acpi_ev_notify_dispatch+0x54/0x71 + [] acpi_os_execute_deferred+0x17/0x30 + [] process_one_work+0x21a/0x3f0 + [] worker_thread+0x4a/0x3b0 + [] kthread+0xfd/0x130 + [] 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 +Cc: 4.14+ # 4.14+ +Signed-off-by: Rafael J. Wysocki +[sudip: adjust context] +Signed-off-by: Sudip Mukherjee +Signed-off-by: Greg Kroah-Hartman +--- + 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 */ -- 2.47.3