From: Greg Kroah-Hartman Date: Mon, 24 Jun 2024 17:47:28 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v6.1.96~34 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=81e29bf28de819c975ec38d67d1ed615544c4760;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: alsa-hda-realtek-limit-mic-boost-on-n14ap7.patch arm64-dts-imx8qm-mek-fix-gpio-number-for-reg_usdhc2_vmmc.patch btrfs-retry-block-group-reclaim-without-infinite-loop.patch drm-i915-mso-using-joiner-is-not-possible-with-edp-mso.patch drm-radeon-fix-ubsan-warning-in-kv_dpm.c.patch dt-bindings-i2c-google-cros-ec-i2c-tunnel-correct-path-to-i2c-controller-schema.patch gcov-add-support-for-gcc-14.patch i2c-ocores-set-iack-bit-after-core-is-enabled.patch kcov-don-t-lose-track-of-remote-references-during-softirqs.patch kvm-x86-always-sync-pir-to-irr-prior-to-scanning-i-o-apic-routes.patch net-do-not-leave-a-dangling-sk-pointer-when-socket-creation-fails.patch tcp-clear-tp-retrans_stamp-in-tcp_rcv_fastopen_synack.patch --- diff --git a/queue-5.15/alsa-hda-realtek-limit-mic-boost-on-n14ap7.patch b/queue-5.15/alsa-hda-realtek-limit-mic-boost-on-n14ap7.patch new file mode 100644 index 00000000000..ca515a44a7b --- /dev/null +++ b/queue-5.15/alsa-hda-realtek-limit-mic-boost-on-n14ap7.patch @@ -0,0 +1,31 @@ +From 86a433862912f52597263aa224a9ed82bcd533bf Mon Sep 17 00:00:00 2001 +From: Edson Juliano Drosdeck +Date: Wed, 5 Jun 2024 12:39:23 -0300 +Subject: ALSA: hda/realtek: Limit mic boost on N14AP7 + +From: Edson Juliano Drosdeck + +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 +Cc: +Link: https://lore.kernel.org/r/20240605153923.2837-1-edson.drosdeck@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 +@@ -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), diff --git a/queue-5.15/arm64-dts-imx8qm-mek-fix-gpio-number-for-reg_usdhc2_vmmc.patch b/queue-5.15/arm64-dts-imx8qm-mek-fix-gpio-number-for-reg_usdhc2_vmmc.patch new file mode 100644 index 00000000000..ac1f7b3d4e6 --- /dev/null +++ b/queue-5.15/arm64-dts-imx8qm-mek-fix-gpio-number-for-reg_usdhc2_vmmc.patch @@ -0,0 +1,32 @@ +From dfd239a039b3581ca25f932e66b6e2c2bf77c798 Mon Sep 17 00:00:00 2001 +From: Frank Li +Date: Fri, 14 Jun 2024 11:06:32 -0400 +Subject: arm64: dts: imx8qm-mek: fix gpio number for reg_usdhc2_vmmc + +From: Frank Li + +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 +Signed-off-by: Frank Li +Signed-off-by: Shawn Guo +Signed-off-by: Greg Kroah-Hartman +--- + 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; + }; + }; diff --git a/queue-5.15/btrfs-retry-block-group-reclaim-without-infinite-loop.patch b/queue-5.15/btrfs-retry-block-group-reclaim-without-infinite-loop.patch new file mode 100644 index 00000000000..6c2d9296599 --- /dev/null +++ b/queue-5.15/btrfs-retry-block-group-reclaim-without-infinite-loop.patch @@ -0,0 +1,66 @@ +From 4eb4e85c4f818491efc67e9373aa16b123c3f522 Mon Sep 17 00:00:00 2001 +From: Boris Burkov +Date: Fri, 7 Jun 2024 12:50:14 -0700 +Subject: btrfs: retry block group reclaim without infinite loop + +From: Boris Burkov + +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 +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } diff --git a/queue-5.15/drm-i915-mso-using-joiner-is-not-possible-with-edp-mso.patch b/queue-5.15/drm-i915-mso-using-joiner-is-not-possible-with-edp-mso.patch new file mode 100644 index 00000000000..6303bf29fad --- /dev/null +++ b/queue-5.15/drm-i915-mso-using-joiner-is-not-possible-with-edp-mso.patch @@ -0,0 +1,44 @@ +From 49cc17967be95d64606d5684416ee51eec35e84a Mon Sep 17 00:00:00 2001 +From: Jani Nikula +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 + +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: # v5.13+ +Cc: Ville Syrjala +Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1668 +Reviewed-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20240614142311.589089-1-jani.nikula@intel.com +Signed-off-by: Jani Nikula +(cherry picked from commit 8b5a92ca24eb96bb71e2a55e352687487d87687f) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.15/drm-radeon-fix-ubsan-warning-in-kv_dpm.c.patch b/queue-5.15/drm-radeon-fix-ubsan-warning-in-kv_dpm.c.patch new file mode 100644 index 00000000000..47aada28bf8 --- /dev/null +++ b/queue-5.15/drm-radeon-fix-ubsan-warning-in-kv_dpm.c.patch @@ -0,0 +1,30 @@ +From a498df5421fd737d11bfd152428ba6b1c8538321 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Mon, 20 May 2024 09:11:45 -0400 +Subject: drm/radeon: fix UBSAN warning in kv_dpm.c + +From: Alex Deucher + +commit a498df5421fd737d11bfd152428ba6b1c8538321 upstream. + +Adds bounds check for sumo_vid_mapping_entry. + +Reviewed-by: Mario Limonciello +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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 = diff --git a/queue-5.15/dt-bindings-i2c-google-cros-ec-i2c-tunnel-correct-path-to-i2c-controller-schema.patch b/queue-5.15/dt-bindings-i2c-google-cros-ec-i2c-tunnel-correct-path-to-i2c-controller-schema.patch new file mode 100644 index 00000000000..b7e891a35d7 --- /dev/null +++ b/queue-5.15/dt-bindings-i2c-google-cros-ec-i2c-tunnel-correct-path-to-i2c-controller-schema.patch @@ -0,0 +1,33 @@ +From 5c8cfd592bb7632200b4edac8f2c7ec892ed9d81 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +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 + +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 +Reviewed-by: Conor Dooley +Signed-off-by: Andi Shyti +Signed-off-by: Greg Kroah-Hartman +--- + 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: diff --git a/queue-5.15/gcov-add-support-for-gcc-14.patch b/queue-5.15/gcov-add-support-for-gcc-14.patch new file mode 100644 index 00000000000..c79dac8534c --- /dev/null +++ b/queue-5.15/gcov-add-support-for-gcc-14.patch @@ -0,0 +1,40 @@ +From c1558bc57b8e5b4da5d821537cd30e2e660861d8 Mon Sep 17 00:00:00 2001 +From: Peter Oberparleiter +Date: Mon, 10 Jun 2024 11:27:43 +0200 +Subject: gcov: add support for GCC 14 + +From: Peter Oberparleiter + +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 +Reported-by: Allison Henderson +Reported-by: Chuck Lever III +Tested-by: Chuck Lever +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #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 diff --git a/queue-5.15/i2c-ocores-set-iack-bit-after-core-is-enabled.patch b/queue-5.15/i2c-ocores-set-iack-bit-after-core-is-enabled.patch new file mode 100644 index 00000000000..a1e5dadd98b --- /dev/null +++ b/queue-5.15/i2c-ocores-set-iack-bit-after-core-is-enabled.patch @@ -0,0 +1,39 @@ +From 5a72477273066b5b357801ab2d315ef14949d402 Mon Sep 17 00:00:00 2001 +From: Grygorii Tertychnyi +Date: Mon, 20 May 2024 17:39:32 +0200 +Subject: i2c: ocores: set IACK bit after core is enabled + +From: Grygorii Tertychnyi + +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 +Acked-by: Peter Korsgaard +Cc: stable@vger.kernel.org +Signed-off-by: Andi Shyti +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.15/kcov-don-t-lose-track-of-remote-references-during-softirqs.patch b/queue-5.15/kcov-don-t-lose-track-of-remote-references-during-softirqs.patch new file mode 100644 index 00000000000..d1d5ab50843 --- /dev/null +++ b/queue-5.15/kcov-don-t-lose-track-of-remote-references-during-softirqs.patch @@ -0,0 +1,79 @@ +From 01c8f9806bde438ca1c8cbbc439f0a14a6694f6c Mon Sep 17 00:00:00 2001 +From: Aleksandr Nogikh +Date: Tue, 11 Jun 2024 15:32:29 +0200 +Subject: kcov: don't lose track of remote references during softirqs + +From: Aleksandr Nogikh + +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 +Reviewed-by: Dmitry Vyukov +Reviewed-by: Andrey Konovalov +Tested-by: Andrey Konovalov +Cc: Alexander Potapenko +Cc: Arnd Bergmann +Cc: Marco Elver +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.15/kvm-x86-always-sync-pir-to-irr-prior-to-scanning-i-o-apic-routes.patch b/queue-5.15/kvm-x86-always-sync-pir-to-irr-prior-to-scanning-i-o-apic-routes.patch new file mode 100644 index 00000000000..a5ff86070c3 --- /dev/null +++ b/queue-5.15/kvm-x86-always-sync-pir-to-irr-prior-to-scanning-i-o-apic-routes.patch @@ -0,0 +1,59 @@ +From f3ced000a2df53f4b12849e121769045a81a3b22 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +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 + +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 +Cc: Raghavendra Rao Ananta +Reviewed-by: Jim Mattson +Signed-off-by: Sean Christopherson +Message-ID: <20240611014845.82795-1-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.15/net-do-not-leave-a-dangling-sk-pointer-when-socket-creation-fails.patch b/queue-5.15/net-do-not-leave-a-dangling-sk-pointer-when-socket-creation-fails.patch new file mode 100644 index 00000000000..c2257452eda --- /dev/null +++ b/queue-5.15/net-do-not-leave-a-dangling-sk-pointer-when-socket-creation-fails.patch @@ -0,0 +1,95 @@ +From 6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2 Mon Sep 17 00:00:00 2001 +From: Ignat Korchagin +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 + +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: + +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 +Signed-off-by: Ignat Korchagin +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/netdev/20240613194047.36478-1-kuniyu@amazon.com/T/ +Reviewed-by: Kuniyuki Iwashima +Reviewed-by: D. Wythe +Link: https://lore.kernel.org/r/20240617210205.67311-1-ignat@cloudflare.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.15/series b/queue-5.15/series index 5467b53ea30..ab152739015 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -245,3 +245,15 @@ regulator-bd71815-fix-ramp-values.patch 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 diff --git a/queue-5.15/tcp-clear-tp-retrans_stamp-in-tcp_rcv_fastopen_synack.patch b/queue-5.15/tcp-clear-tp-retrans_stamp-in-tcp_rcv_fastopen_synack.patch new file mode 100644 index 00000000000..306ef8888cf --- /dev/null +++ b/queue-5.15/tcp-clear-tp-retrans_stamp-in-tcp_rcv_fastopen_synack.patch @@ -0,0 +1,57 @@ +From 9e046bb111f13461d3f9331e24e974324245140e Mon Sep 17 00:00:00 2001 +From: Eric Dumazet +Date: Fri, 14 Jun 2024 13:06:15 +0000 +Subject: tcp: clear tp->retrans_stamp in tcp_rcv_fastopen_synack() + +From: Eric Dumazet + +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 +Signed-off-by: Neal Cardwell +Co-developed-by: Yuchung Cheng +Signed-off-by: Yuchung Cheng +Signed-off-by: Eric Dumazet +Link: https://lore.kernel.org/r/20240614130615.396837-1-edumazet@google.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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;