--- /dev/null
+From 86a433862912f52597263aa224a9ed82bcd533bf Mon Sep 17 00:00:00 2001
+From: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
+Date: Wed, 5 Jun 2024 12:39:23 -0300
+Subject: ALSA: hda/realtek: Limit mic boost on N14AP7
+
+From: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
+
+commit 86a433862912f52597263aa224a9ed82bcd533bf upstream.
+
+The internal mic boost on the N14AP7 is too high. Fix this by applying the
+ALC269_FIXUP_LIMIT_INT_MIC_BOOST fixup to the machine to limit the gain.
+
+Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20240605153923.2837-1-edson.drosdeck@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
+@@ -9463,6 +9463,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x1b7d, 0xa831, "Ordissimo EVE2 ", ALC269VB_FIXUP_ORDISSIMO_EVE2), /* Also known as Malata PC-B1303 */
+ SND_PCI_QUIRK(0x1c06, 0x2013, "Lemote A1802", ALC269_FIXUP_LEMOTE_A1802),
+ SND_PCI_QUIRK(0x1c06, 0x2015, "Lemote A190X", ALC269_FIXUP_LEMOTE_A190X),
++ SND_PCI_QUIRK(0x1c6c, 0x122a, "Positivo N14AP7", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
+ SND_PCI_QUIRK(0x1c6c, 0x1251, "Positivo N14KP6-TG", ALC288_FIXUP_DELL1_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1d05, 0x1132, "TongFang PHxTxX1", ALC256_FIXUP_SET_COEF_DEFAULTS),
+ SND_PCI_QUIRK(0x1d05, 0x1096, "TongFang GMxMRxx", ALC269_FIXUP_NO_SHUTUP),
--- /dev/null
+From dfd239a039b3581ca25f932e66b6e2c2bf77c798 Mon Sep 17 00:00:00 2001
+From: Frank Li <Frank.Li@nxp.com>
+Date: Fri, 14 Jun 2024 11:06:32 -0400
+Subject: arm64: dts: imx8qm-mek: fix gpio number for reg_usdhc2_vmmc
+
+From: Frank Li <Frank.Li@nxp.com>
+
+commit dfd239a039b3581ca25f932e66b6e2c2bf77c798 upstream.
+
+The gpio in "reg_usdhc2_vmmc" should be 7 instead of 19.
+
+Cc: stable@vger.kernel.org
+Fixes: 307fd14d4b14 ("arm64: dts: imx: add imx8qm mek support")
+Reviewed-by: Peng Fan <peng.fan@nxp.com>
+Signed-off-by: Frank Li <Frank.Li@nxp.com>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
++++ b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
+@@ -32,7 +32,7 @@
+ regulator-name = "SD1_SPWR";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+- gpio = <&lsio_gpio4 19 GPIO_ACTIVE_HIGH>;
++ gpio = <&lsio_gpio4 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+ };
--- /dev/null
+From 4eb4e85c4f818491efc67e9373aa16b123c3f522 Mon Sep 17 00:00:00 2001
+From: Boris Burkov <boris@bur.io>
+Date: Fri, 7 Jun 2024 12:50:14 -0700
+Subject: btrfs: retry block group reclaim without infinite loop
+
+From: Boris Burkov <boris@bur.io>
+
+commit 4eb4e85c4f818491efc67e9373aa16b123c3f522 upstream.
+
+If inc_block_group_ro systematically fails (e.g. due to ETXTBUSY from
+swap) or btrfs_relocate_chunk systematically fails (from lack of
+space), then this worker becomes an infinite loop.
+
+At the very least, this strands the cleaner thread, but can also result
+in hung tasks/RCU stalls on PREEMPT_NONE kernels and if the
+reclaim_bgs_lock mutex is not contended.
+
+I believe the best long term fix is to manage reclaim via work queue,
+where we queue up a relocation on the triggering condition and re-queue
+on failure. In the meantime, this is an easy fix to apply to avoid the
+immediate pain.
+
+Fixes: 7e2718099438 ("btrfs: reinsert BGs failed to reclaim")
+CC: stable@vger.kernel.org # 6.6+
+Signed-off-by: Boris Burkov <boris@bur.io>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/block-group.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/block-group.c
++++ b/fs/btrfs/block-group.c
+@@ -1493,6 +1493,7 @@ void btrfs_reclaim_bgs_work(struct work_
+ container_of(work, struct btrfs_fs_info, reclaim_bgs_work);
+ struct btrfs_block_group *bg;
+ struct btrfs_space_info *space_info;
++ LIST_HEAD(retry_list);
+
+ if (!test_bit(BTRFS_FS_OPEN, &fs_info->flags))
+ return;
+@@ -1583,8 +1584,11 @@ void btrfs_reclaim_bgs_work(struct work_
+ }
+
+ next:
+- if (ret)
+- btrfs_mark_bg_to_reclaim(bg);
++ if (ret) {
++ /* Refcount held by the reclaim_bgs list after splice. */
++ btrfs_get_block_group(bg);
++ list_add_tail(&bg->bg_list, &retry_list);
++ }
+ btrfs_put_block_group(bg);
+
+ mutex_unlock(&fs_info->reclaim_bgs_lock);
+@@ -1604,6 +1608,9 @@ next:
+ spin_unlock(&fs_info->unused_bgs_lock);
+ mutex_unlock(&fs_info->reclaim_bgs_lock);
+ end:
++ spin_lock(&fs_info->unused_bgs_lock);
++ list_splice_tail(&retry_list, &fs_info->reclaim_bgs);
++ spin_unlock(&fs_info->unused_bgs_lock);
+ btrfs_exclop_finish(fs_info);
+ sb_end_write(fs_info->sb);
+ }
--- /dev/null
+From 49cc17967be95d64606d5684416ee51eec35e84a Mon Sep 17 00:00:00 2001
+From: Jani Nikula <jani.nikula@intel.com>
+Date: Fri, 14 Jun 2024 17:23:11 +0300
+Subject: drm/i915/mso: using joiner is not possible with eDP MSO
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jani Nikula <jani.nikula@intel.com>
+
+commit 49cc17967be95d64606d5684416ee51eec35e84a upstream.
+
+It's not possible to use the joiner at the same time with eDP MSO. When
+a panel needs MSO, it's not optional, so MSO trumps joiner.
+
+v3: Only change intel_dp_has_joiner(), leave debugfs alone (Ville)
+
+Fixes: bc71194e8897 ("drm/i915/edp: enable eDP MSO during link training")
+Cc: <stable@vger.kernel.org> # v5.13+
+Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
+Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1668
+Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240614142311.589089-1-jani.nikula@intel.com
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+(cherry picked from commit 8b5a92ca24eb96bb71e2a55e352687487d87687f)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_dp.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/gpu/drm/i915/display/intel_dp.c
++++ b/drivers/gpu/drm/i915/display/intel_dp.c
+@@ -226,6 +226,10 @@ bool intel_dp_can_bigjoiner(struct intel
+ struct intel_encoder *encoder = &intel_dig_port->base;
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
++ /* eDP MSO is not compatible with joiner */
++ if (intel_dp->mso_link_count)
++ return false;
++
+ return DISPLAY_VER(dev_priv) >= 12 ||
+ (DISPLAY_VER(dev_priv) == 11 &&
+ encoder->port != PORT_A);
--- /dev/null
+From a498df5421fd737d11bfd152428ba6b1c8538321 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Mon, 20 May 2024 09:11:45 -0400
+Subject: drm/radeon: fix UBSAN warning in kv_dpm.c
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit a498df5421fd737d11bfd152428ba6b1c8538321 upstream.
+
+Adds bounds check for sumo_vid_mapping_entry.
+
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/radeon/sumo_dpm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/radeon/sumo_dpm.c
++++ b/drivers/gpu/drm/radeon/sumo_dpm.c
+@@ -1621,6 +1621,8 @@ void sumo_construct_vid_mapping_table(st
+
+ for (i = 0; i < SUMO_MAX_HARDWARE_POWERLEVELS; i++) {
+ if (table[i].ulSupportedSCLK != 0) {
++ if (table[i].usVoltageIndex >= SUMO_MAX_NUMBER_VOLTAGES)
++ continue;
+ vid_mapping_table->entries[table[i].usVoltageIndex].vid_7bit =
+ table[i].usVoltageID;
+ vid_mapping_table->entries[table[i].usVoltageIndex].vid_2bit =
--- /dev/null
+From 5c8cfd592bb7632200b4edac8f2c7ec892ed9d81 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Thu, 20 Jun 2024 13:34:50 +0200
+Subject: dt-bindings: i2c: google,cros-ec-i2c-tunnel: correct path to i2c-controller schema
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 5c8cfd592bb7632200b4edac8f2c7ec892ed9d81 upstream.
+
+The referenced i2c-controller.yaml schema is provided by dtschema
+package (outside of Linux kernel), so use full path to reference it.
+
+Cc: stable@vger.kernel.org
+Fixes: 1acd4577a66f ("dt-bindings: i2c: convert i2c-cros-ec-tunnel to json-schema")
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml
++++ b/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml
+@@ -22,7 +22,7 @@ description: |
+ google,cros-ec-spi or google,cros-ec-i2c.
+
+ allOf:
+- - $ref: i2c-controller.yaml#
++ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+ properties:
+ compatible:
--- /dev/null
+From c1558bc57b8e5b4da5d821537cd30e2e660861d8 Mon Sep 17 00:00:00 2001
+From: Peter Oberparleiter <oberpar@linux.ibm.com>
+Date: Mon, 10 Jun 2024 11:27:43 +0200
+Subject: gcov: add support for GCC 14
+
+From: Peter Oberparleiter <oberpar@linux.ibm.com>
+
+commit c1558bc57b8e5b4da5d821537cd30e2e660861d8 upstream.
+
+Using gcov on kernels compiled with GCC 14 results in truncated 16-byte
+long .gcda files with no usable data. To fix this, update GCOV_COUNTERS
+to match the value defined by GCC 14.
+
+Tested with GCC versions 14.1.0 and 13.2.0.
+
+Link: https://lkml.kernel.org/r/20240610092743.1609845-1-oberpar@linux.ibm.com
+Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
+Reported-by: Allison Henderson <allison.henderson@oracle.com>
+Reported-by: Chuck Lever III <chuck.lever@oracle.com>
+Tested-by: Chuck Lever <chuck.lever@oracle.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/gcov/gcc_4_7.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/kernel/gcov/gcc_4_7.c
++++ b/kernel/gcov/gcc_4_7.c
+@@ -18,7 +18,9 @@
+ #include <linux/mm.h>
+ #include "gcov.h"
+
+-#if (__GNUC__ >= 10)
++#if (__GNUC__ >= 14)
++#define GCOV_COUNTERS 9
++#elif (__GNUC__ >= 10)
+ #define GCOV_COUNTERS 8
+ #elif (__GNUC__ >= 7)
+ #define GCOV_COUNTERS 9
--- /dev/null
+From 5a72477273066b5b357801ab2d315ef14949d402 Mon Sep 17 00:00:00 2001
+From: Grygorii Tertychnyi <grembeter@gmail.com>
+Date: Mon, 20 May 2024 17:39:32 +0200
+Subject: i2c: ocores: set IACK bit after core is enabled
+
+From: Grygorii Tertychnyi <grembeter@gmail.com>
+
+commit 5a72477273066b5b357801ab2d315ef14949d402 upstream.
+
+Setting IACK bit when core is disabled does not clear the "Interrupt Flag"
+bit in the status register, and the interrupt remains pending.
+
+Sometimes it causes failure for the very first message transfer, that is
+usually a device probe.
+
+Hence, set IACK bit after core is enabled to clear pending interrupt.
+
+Fixes: 18f98b1e3147 ("[PATCH] i2c: New bus driver for the OpenCores I2C controller")
+Signed-off-by: Grygorii Tertychnyi <grygorii.tertychnyi@leica-geosystems.com>
+Acked-by: Peter Korsgaard <peter@korsgaard.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i2c/busses/i2c-ocores.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/i2c/busses/i2c-ocores.c
++++ b/drivers/i2c/busses/i2c-ocores.c
+@@ -442,8 +442,8 @@ static int ocores_init(struct device *de
+ oc_setreg(i2c, OCI2C_PREHIGH, prescale >> 8);
+
+ /* Init the device */
+- oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
+ oc_setreg(i2c, OCI2C_CONTROL, ctrl | OCI2C_CTRL_EN);
++ oc_setreg(i2c, OCI2C_CMD, OCI2C_CMD_IACK);
+
+ return 0;
+ }
--- /dev/null
+From 01c8f9806bde438ca1c8cbbc439f0a14a6694f6c Mon Sep 17 00:00:00 2001
+From: Aleksandr Nogikh <nogikh@google.com>
+Date: Tue, 11 Jun 2024 15:32:29 +0200
+Subject: kcov: don't lose track of remote references during softirqs
+
+From: Aleksandr Nogikh <nogikh@google.com>
+
+commit 01c8f9806bde438ca1c8cbbc439f0a14a6694f6c upstream.
+
+In kcov_remote_start()/kcov_remote_stop(), we swap the previous KCOV
+metadata of the current task into a per-CPU variable. However, the
+kcov_mode_enabled(mode) check is not sufficient in the case of remote KCOV
+coverage: current->kcov_mode always remains KCOV_MODE_DISABLED for remote
+KCOV objects.
+
+If the original task that has invoked the KCOV_REMOTE_ENABLE ioctl happens
+to get interrupted and kcov_remote_start() is called, it ultimately leads
+to kcov_remote_stop() NOT restoring the original KCOV reference. So when
+the task exits, all registered remote KCOV handles remain active forever.
+
+The most uncomfortable effect (at least for syzkaller) is that the bug
+prevents the reuse of the same /sys/kernel/debug/kcov descriptor. If
+we obtain it in the parent process and then e.g. drop some
+capabilities and continuously fork to execute individual programs, at
+some point current->kcov of the forked process is lost,
+kcov_task_exit() takes no action, and all KCOV_REMOTE_ENABLE ioctls
+calls from subsequent forks fail.
+
+And, yes, the efficiency is also affected if we keep on losing remote
+kcov objects.
+a) kcov_remote_map keeps on growing forever.
+b) (If I'm not mistaken), we're also not freeing the memory referenced
+by kcov->area.
+
+Fix it by introducing a special kcov_mode that is assigned to the task
+that owns a KCOV remote object. It makes kcov_mode_enabled() return true
+and yet does not trigger coverage collection in __sanitizer_cov_trace_pc()
+and write_comp_data().
+
+[nogikh@google.com: replace WRITE_ONCE() with an ordinary assignment]
+ Link: https://lkml.kernel.org/r/20240614171221.2837584-1-nogikh@google.com
+Link: https://lkml.kernel.org/r/20240611133229.527822-1-nogikh@google.com
+Fixes: 5ff3b30ab57d ("kcov: collect coverage from interrupts")
+Signed-off-by: Aleksandr Nogikh <nogikh@google.com>
+Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
+Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
+Tested-by: Andrey Konovalov <andreyknvl@gmail.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Marco Elver <elver@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/kcov.h | 2 ++
+ kernel/kcov.c | 1 +
+ 2 files changed, 3 insertions(+)
+
+--- a/include/linux/kcov.h
++++ b/include/linux/kcov.h
+@@ -21,6 +21,8 @@ enum kcov_mode {
+ KCOV_MODE_TRACE_PC = 2,
+ /* Collecting comparison operands mode. */
+ KCOV_MODE_TRACE_CMP = 3,
++ /* The process owns a KCOV remote reference. */
++ KCOV_MODE_REMOTE = 4,
+ };
+
+ #define KCOV_IN_CTXSW (1 << 30)
+--- a/kernel/kcov.c
++++ b/kernel/kcov.c
+@@ -635,6 +635,7 @@ static int kcov_ioctl_locked(struct kcov
+ return -EINVAL;
+ kcov->mode = mode;
+ t->kcov = kcov;
++ t->kcov_mode = KCOV_MODE_REMOTE;
+ kcov->t = t;
+ kcov->remote = true;
+ kcov->remote_size = remote_arg->area_size;
--- /dev/null
+From f3ced000a2df53f4b12849e121769045a81a3b22 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Mon, 10 Jun 2024 18:48:45 -0700
+Subject: KVM: x86: Always sync PIR to IRR prior to scanning I/O APIC routes
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit f3ced000a2df53f4b12849e121769045a81a3b22 upstream.
+
+Sync pending posted interrupts to the IRR prior to re-scanning I/O APIC
+routes, irrespective of whether the I/O APIC is emulated by userspace or
+by KVM. If a level-triggered interrupt routed through the I/O APIC is
+pending or in-service for a vCPU, KVM needs to intercept EOIs on said
+vCPU even if the vCPU isn't the destination for the new routing, e.g. if
+servicing an interrupt using the old routing races with I/O APIC
+reconfiguration.
+
+Commit fceb3a36c29a ("KVM: x86: ioapic: Fix level-triggered EOI and
+userspace I/OAPIC reconfigure race") fixed the common cases, but
+kvm_apic_pending_eoi() only checks if an interrupt is in the local
+APIC's IRR or ISR, i.e. misses the uncommon case where an interrupt is
+pending in the PIR.
+
+Failure to intercept EOI can manifest as guest hangs with Windows 11 if
+the guest uses the RTC as its timekeeping source, e.g. if the VMM doesn't
+expose a more modern form of time to the guest.
+
+Cc: stable@vger.kernel.org
+Cc: Adamos Ttofari <attofari@amazon.de>
+Cc: Raghavendra Rao Ananta <rananta@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-ID: <20240611014845.82795-1-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/x86.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -9654,13 +9654,12 @@ static void vcpu_scan_ioapic(struct kvm_
+
+ bitmap_zero(vcpu->arch.ioapic_handled_vectors, 256);
+
++ static_call_cond(kvm_x86_sync_pir_to_irr)(vcpu);
++
+ if (irqchip_split(vcpu->kvm))
+ kvm_scan_ioapic_routes(vcpu, vcpu->arch.ioapic_handled_vectors);
+- else {
+- static_call_cond(kvm_x86_sync_pir_to_irr)(vcpu);
+- if (ioapic_in_kernel(vcpu->kvm))
+- kvm_ioapic_scan_entry(vcpu, vcpu->arch.ioapic_handled_vectors);
+- }
++ else if (ioapic_in_kernel(vcpu->kvm))
++ kvm_ioapic_scan_entry(vcpu, vcpu->arch.ioapic_handled_vectors);
+
+ if (is_guest_mode(vcpu))
+ vcpu->arch.load_eoi_exitmap_pending = true;
--- /dev/null
+From 6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2 Mon Sep 17 00:00:00 2001
+From: Ignat Korchagin <ignat@cloudflare.com>
+Date: Mon, 17 Jun 2024 22:02:05 +0100
+Subject: net: do not leave a dangling sk pointer, when socket creation fails
+
+From: Ignat Korchagin <ignat@cloudflare.com>
+
+commit 6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2 upstream.
+
+It is possible to trigger a use-after-free by:
+ * attaching an fentry probe to __sock_release() and the probe calling the
+ bpf_get_socket_cookie() helper
+ * running traceroute -I 1.1.1.1 on a freshly booted VM
+
+A KASAN enabled kernel will log something like below (decoded and stripped):
+==================================================================
+BUG: KASAN: slab-use-after-free in __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
+Read of size 8 at addr ffff888007110dd8 by task traceroute/299
+
+CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
+Call Trace:
+ <TASK>
+dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1))
+print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
+? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
+kasan_report (mm/kasan/report.c:603)
+? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
+kasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189)
+__sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29)
+bpf_get_socket_ptr_cookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092)
+bpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e
+bpf_trampoline_6442506592+0x47/0xaf
+__sock_release (net/socket.c:652)
+__sock_create (net/socket.c:1601)
+...
+Allocated by task 299 on cpu 2 at 78.328492s:
+kasan_save_stack (mm/kasan/common.c:48)
+kasan_save_track (mm/kasan/common.c:68)
+__kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338)
+kmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007)
+sk_prot_alloc (net/core/sock.c:2075)
+sk_alloc (net/core/sock.c:2134)
+inet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252)
+__sock_create (net/socket.c:1572)
+__sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706)
+__x64_sys_socket (net/socket.c:1718)
+do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
+entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
+
+Freed by task 299 on cpu 2 at 78.328502s:
+kasan_save_stack (mm/kasan/common.c:48)
+kasan_save_track (mm/kasan/common.c:68)
+kasan_save_free_info (mm/kasan/generic.c:582)
+poison_slab_object (mm/kasan/common.c:242)
+__kasan_slab_free (mm/kasan/common.c:256)
+kmem_cache_free (mm/slub.c:4437 mm/slub.c:4511)
+__sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208)
+inet_create (net/ipv4/af_inet.c:397 net/ipv4/af_inet.c:252)
+__sock_create (net/socket.c:1572)
+__sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706)
+__x64_sys_socket (net/socket.c:1718)
+do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
+entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
+
+Fix this by clearing the struct socket reference in sk_common_release() to cover
+all protocol families create functions, which may already attached the
+reference to the sk object with sock_init_data().
+
+Fixes: c5dbb89fc2ac ("bpf: Expose bpf_get_socket_cookie to tracing programs")
+Suggested-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/netdev/20240613194047.36478-1-kuniyu@amazon.com/T/
+Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Reviewed-by: D. Wythe <alibuda@linux.alibaba.com>
+Link: https://lore.kernel.org/r/20240617210205.67311-1-ignat@cloudflare.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/sock.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/core/sock.c
++++ b/net/core/sock.c
+@@ -3459,6 +3459,9 @@ void sk_common_release(struct sock *sk)
+
+ sk->sk_prot->unhash(sk);
+
++ if (sk->sk_socket)
++ sk->sk_socket->sk = NULL;
++
+ /*
+ * In this point socket cannot receive new packets, but it is possible
+ * that some packets are in flight because some CPU runs receiver and
acpica-revert-acpica-avoid-info-mapping-multiple-bar.patch
rdma-mlx5-add-check-for-srq-max_sge-attribute.patch
serial-stm32-rework-rx-over-dma.patch
+net-do-not-leave-a-dangling-sk-pointer-when-socket-creation-fails.patch
+btrfs-retry-block-group-reclaim-without-infinite-loop.patch
+kvm-x86-always-sync-pir-to-irr-prior-to-scanning-i-o-apic-routes.patch
+alsa-hda-realtek-limit-mic-boost-on-n14ap7.patch
+drm-i915-mso-using-joiner-is-not-possible-with-edp-mso.patch
+drm-radeon-fix-ubsan-warning-in-kv_dpm.c.patch
+gcov-add-support-for-gcc-14.patch
+kcov-don-t-lose-track-of-remote-references-during-softirqs.patch
+tcp-clear-tp-retrans_stamp-in-tcp_rcv_fastopen_synack.patch
+i2c-ocores-set-iack-bit-after-core-is-enabled.patch
+dt-bindings-i2c-google-cros-ec-i2c-tunnel-correct-path-to-i2c-controller-schema.patch
+arm64-dts-imx8qm-mek-fix-gpio-number-for-reg_usdhc2_vmmc.patch
--- /dev/null
+From 9e046bb111f13461d3f9331e24e974324245140e Mon Sep 17 00:00:00 2001
+From: Eric Dumazet <edumazet@google.com>
+Date: Fri, 14 Jun 2024 13:06:15 +0000
+Subject: tcp: clear tp->retrans_stamp in tcp_rcv_fastopen_synack()
+
+From: Eric Dumazet <edumazet@google.com>
+
+commit 9e046bb111f13461d3f9331e24e974324245140e upstream.
+
+Some applications were reporting ETIMEDOUT errors on apparently
+good looking flows, according to packet dumps.
+
+We were able to root cause the issue to an accidental setting
+of tp->retrans_stamp in the following scenario:
+
+- client sends TFO SYN with data.
+- server has TFO disabled, ACKs only SYN but not payload.
+- client receives SYNACK covering only SYN.
+- tcp_ack() eats SYN and sets tp->retrans_stamp to 0.
+- tcp_rcv_fastopen_synack() calls tcp_xmit_retransmit_queue()
+ to retransmit TFO payload w/o SYN, sets tp->retrans_stamp to "now",
+ but we are not in any loss recovery state.
+- TFO payload is ACKed.
+- we are not in any loss recovery state, and don't see any dupacks,
+ so we don't get to any code path that clears tp->retrans_stamp.
+- tp->retrans_stamp stays non-zero for the lifetime of the connection.
+- after first RTO, tcp_clamp_rto_to_user_timeout() clamps second RTO
+ to 1 jiffy due to bogus tp->retrans_stamp.
+- on clamped RTO with non-zero icsk_retransmits, retransmits_timed_out()
+ sets start_ts from tp->retrans_stamp from TFO payload retransmit
+ hours/days ago, and computes bogus long elapsed time for loss recovery,
+ and suffers ETIMEDOUT early.
+
+Fixes: a7abf3cd76e1 ("tcp: consider using standard rtx logic in tcp_rcv_fastopen_synack()")
+CC: stable@vger.kernel.org
+Co-developed-by: Neal Cardwell <ncardwell@google.com>
+Signed-off-by: Neal Cardwell <ncardwell@google.com>
+Co-developed-by: Yuchung Cheng <ycheng@google.com>
+Signed-off-by: Yuchung Cheng <ycheng@google.com>
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Link: https://lore.kernel.org/r/20240614130615.396837-1-edumazet@google.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/tcp_input.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/ipv4/tcp_input.c
++++ b/net/ipv4/tcp_input.c
+@@ -6104,6 +6104,7 @@ static bool tcp_rcv_fastopen_synack(stru
+ skb_rbtree_walk_from(data)
+ tcp_mark_skb_lost(sk, data);
+ tcp_xmit_retransmit_queue(sk);
++ tp->retrans_stamp = 0;
+ NET_INC_STATS(sock_net(sk),
+ LINUX_MIB_TCPFASTOPENACTIVEFAIL);
+ return true;
projects / thirdparty / kernel / stable-queue.git / commitdiff
