From: Greg Kroah-Hartman Date: Mon, 1 Jul 2024 14:27:45 +0000 (+0200) Subject: 6.9-stable patches X-Git-Tag: v4.19.317~83 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d575793d770c828d1462a5b5d84d32b8db2fd76b;p=thirdparty%2Fkernel%2Fstable-queue.git 6.9-stable patches added patches: alsa-hda-realtek-fix-mute-micmute-leds-don-t-work-for-elitebook-645-665-g11.patch btrfs-zoned-fix-initial-free-space-detection.patch cpu-fix-broken-cmdline-nosmp-and-maxcpus-0.patch cpu-hotplug-fix-dynstate-assignment-in-__cpuhp_setup_state_cpuslocked.patch cpufreq-intel_pstate-use-hwp-to-initialize-itmt-if-cppc-is-missing.patch csky-hexagon-fix-broken-sys_sync_file_range.patch drm-amd-display-send-dp_total_lttpr_cnt-during-detection-if-lttpr-is-present.patch drm-amdgpu-atomfirmware-fix-parsing-of-vram_info.patch drm-amdgpu-avoid-using-null-object-of-framebuffer.patch drm-drm_file-fix-pid-refcounting-race.patch drm-fbdev-dma-only-set-smem_start-is-enable-per-module-option.patch drm-i915-gt-fix-potential-uaf-by-revoke-of-fence-registers.patch drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_hd_modes.patch drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_ld_modes.patch hexagon-fix-fadvise64_64-calling-conventions.patch irqchip-loongson-eiointc-use-early_cpu_to_node-instead-of-cpu_to_node.patch irqchip-loongson-liointc-set-different-isrs-for-different-cores.patch kbuild-install-dtb-files-as-0644-in-makefile.dtbinst.patch net-can-j1939-enhanced-error-handling-for-tightly-received-rts-messages-in-xtp_rx_rts_session_new.patch net-can-j1939-initialize-unused-data-in-j1939_send_one.patch net-can-j1939-recover-socket-queue-on-can-bus-error-during-bam-transmission.patch nvmet-fc-remove-__counted_by-from-nvmet_fc_tgt_queue.fod.patch pci-msi-fix-uaf-in-msi_capability_init.patch sh-rework-sync_file_range-abi.patch tty-mcf-mcf54418-has-10-uarts.patch tty-mxser-remove-__counted_by-from-mxser_board.ports.patch --- diff --git a/queue-6.9/alsa-hda-realtek-fix-mute-micmute-leds-don-t-work-for-elitebook-645-665-g11.patch b/queue-6.9/alsa-hda-realtek-fix-mute-micmute-leds-don-t-work-for-elitebook-645-665-g11.patch new file mode 100644 index 00000000000..a0b8e2aff97 --- /dev/null +++ b/queue-6.9/alsa-hda-realtek-fix-mute-micmute-leds-don-t-work-for-elitebook-645-665-g11.patch @@ -0,0 +1,33 @@ +From 3cd59d8ef8df7d7a079f54d56502dae8f716b39b Mon Sep 17 00:00:00 2001 +From: Dirk Su +Date: Wed, 26 Jun 2024 10:14:36 +0800 +Subject: ALSA: hda/realtek: fix mute/micmute LEDs don't work for EliteBook 645/665 G11. + +From: Dirk Su + +commit 3cd59d8ef8df7d7a079f54d56502dae8f716b39b upstream. + +HP EliteBook 645/665 G11 needs ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF quirk to +make mic-mute/audio-mute working. + +Signed-off-by: Dirk Su +Cc: +Link: https://patch.msgid.link/20240626021437.77039-1-dirk.su@canonical.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_realtek.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -10187,6 +10187,9 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x103c, 0x8c7c, "HP ProBook 445 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), + SND_PCI_QUIRK(0x103c, 0x8c7d, "HP ProBook 465 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), + SND_PCI_QUIRK(0x103c, 0x8c7e, "HP ProBook 465 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), ++ SND_PCI_QUIRK(0x103c, 0x8c7f, "HP EliteBook 645 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), ++ SND_PCI_QUIRK(0x103c, 0x8c80, "HP EliteBook 645 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), ++ SND_PCI_QUIRK(0x103c, 0x8c81, "HP EliteBook 665 G11", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), + SND_PCI_QUIRK(0x103c, 0x8c89, "HP ProBook 460 G11", ALC236_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x8c8a, "HP EliteBook 630", ALC236_FIXUP_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x8c8c, "HP EliteBook 660", ALC236_FIXUP_HP_GPIO_LED), diff --git a/queue-6.9/btrfs-zoned-fix-initial-free-space-detection.patch b/queue-6.9/btrfs-zoned-fix-initial-free-space-detection.patch new file mode 100644 index 00000000000..b75da8f83e6 --- /dev/null +++ b/queue-6.9/btrfs-zoned-fix-initial-free-space-detection.patch @@ -0,0 +1,46 @@ +From b9fd2affe4aa99a4ca14ee87e1f38fea22ece52a Mon Sep 17 00:00:00 2001 +From: Naohiro Aota +Date: Tue, 11 Jun 2024 17:17:30 +0900 +Subject: btrfs: zoned: fix initial free space detection + +From: Naohiro Aota + +commit b9fd2affe4aa99a4ca14ee87e1f38fea22ece52a upstream. + +When creating a new block group, it calls btrfs_add_new_free_space() to add +the entire block group range into the free space accounting. +__btrfs_add_free_space_zoned() checks if size == block_group->length to +detect the initial free space adding, and proceed that case properly. + +However, if the zone_capacity == zone_size and the over-write speed is fast +enough, the entire zone can be over-written within one transaction. That +confuses __btrfs_add_free_space_zoned() to handle it as an initial free +space accounting. As a result, that block group becomes a strange state: 0 +used bytes, 0 zone_unusable bytes, but alloc_offset == zone_capacity (no +allocation anymore). + +The initial free space accounting can properly be checked by checking +alloc_offset too. + +Fixes: 98173255bddd ("btrfs: zoned: calculate free space from zone capacity") +CC: stable@vger.kernel.org # 6.1+ +Reviewed-by: Johannes Thumshirn +Signed-off-by: Naohiro Aota +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/free-space-cache.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/free-space-cache.c ++++ b/fs/btrfs/free-space-cache.c +@@ -2697,7 +2697,7 @@ static int __btrfs_add_free_space_zoned( + u64 offset = bytenr - block_group->start; + u64 to_free, to_unusable; + int bg_reclaim_threshold = 0; +- bool initial = (size == block_group->length); ++ bool initial = ((size == block_group->length) && (block_group->alloc_offset == 0)); + u64 reclaimable_unusable; + + WARN_ON(!initial && offset + size > block_group->zone_capacity); diff --git a/queue-6.9/cpu-fix-broken-cmdline-nosmp-and-maxcpus-0.patch b/queue-6.9/cpu-fix-broken-cmdline-nosmp-and-maxcpus-0.patch new file mode 100644 index 00000000000..0d2995ee4cd --- /dev/null +++ b/queue-6.9/cpu-fix-broken-cmdline-nosmp-and-maxcpus-0.patch @@ -0,0 +1,43 @@ +From 6ef8eb5125722c241fd60d7b0c872d5c2e5dd4ca Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Tue, 18 Jun 2024 16:13:36 +0800 +Subject: cpu: Fix broken cmdline "nosmp" and "maxcpus=0" + +From: Huacai Chen + +commit 6ef8eb5125722c241fd60d7b0c872d5c2e5dd4ca upstream. + +After the rework of "Parallel CPU bringup", the cmdline "nosmp" and +"maxcpus=0" parameters are not working anymore. These parameters set +setup_max_cpus to zero and that's handed to bringup_nonboot_cpus(). + +The code there does a decrement before checking for zero, which brings it +into the negative space and brings up all CPUs. + +Add a zero check at the beginning of the function to prevent this. + +[ tglx: Massaged change log ] + +Fixes: 18415f33e2ac4ab382 ("cpu/hotplug: Allow "parallel" bringup up to CPUHP_BP_KICK_AP_STATE") +Fixes: 06c6796e0304234da6 ("cpu/hotplug: Fix off by one in cpuhp_bringup_mask()") +Signed-off-by: Huacai Chen +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20240618081336.3996825-1-chenhuacai@loongson.cn +Signed-off-by: Greg Kroah-Hartman +--- + kernel/cpu.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/kernel/cpu.c ++++ b/kernel/cpu.c +@@ -1859,6 +1859,9 @@ static inline bool cpuhp_bringup_cpus_pa + + void __init bringup_nonboot_cpus(unsigned int max_cpus) + { ++ if (!max_cpus) ++ return; ++ + /* Try parallel bringup optimization if enabled */ + if (cpuhp_bringup_cpus_parallel(max_cpus)) + return; diff --git a/queue-6.9/cpu-hotplug-fix-dynstate-assignment-in-__cpuhp_setup_state_cpuslocked.patch b/queue-6.9/cpu-hotplug-fix-dynstate-assignment-in-__cpuhp_setup_state_cpuslocked.patch new file mode 100644 index 00000000000..3de0602ebb2 --- /dev/null +++ b/queue-6.9/cpu-hotplug-fix-dynstate-assignment-in-__cpuhp_setup_state_cpuslocked.patch @@ -0,0 +1,61 @@ +From 932d8476399f622aa0767a4a0a9e78e5341dc0e1 Mon Sep 17 00:00:00 2001 +From: Yuntao Wang +Date: Wed, 15 May 2024 21:45:54 +0800 +Subject: cpu/hotplug: Fix dynstate assignment in __cpuhp_setup_state_cpuslocked() + +From: Yuntao Wang + +commit 932d8476399f622aa0767a4a0a9e78e5341dc0e1 upstream. + +Commit 4205e4786d0b ("cpu/hotplug: Provide dynamic range for prepare +stage") added a dynamic range for the prepare states, but did not handle +the assignment of the dynstate variable in __cpuhp_setup_state_cpuslocked(). + +This causes the corresponding startup callback not to be invoked when +calling __cpuhp_setup_state_cpuslocked() with the CPUHP_BP_PREPARE_DYN +parameter, even though it should be. + +Currently, the users of __cpuhp_setup_state_cpuslocked(), for one reason or +another, have not triggered this bug. + +Fixes: 4205e4786d0b ("cpu/hotplug: Provide dynamic range for prepare stage") +Signed-off-by: Yuntao Wang +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20240515134554.427071-1-ytcoode@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + kernel/cpu.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/kernel/cpu.c ++++ b/kernel/cpu.c +@@ -2449,7 +2449,7 @@ EXPORT_SYMBOL_GPL(__cpuhp_state_add_inst + * The caller needs to hold cpus read locked while calling this function. + * Return: + * On success: +- * Positive state number if @state is CPUHP_AP_ONLINE_DYN; ++ * Positive state number if @state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN; + * 0 for all other states + * On failure: proper (negative) error code + */ +@@ -2472,7 +2472,7 @@ int __cpuhp_setup_state_cpuslocked(enum + ret = cpuhp_store_callbacks(state, name, startup, teardown, + multi_instance); + +- dynstate = state == CPUHP_AP_ONLINE_DYN; ++ dynstate = state == CPUHP_AP_ONLINE_DYN || state == CPUHP_BP_PREPARE_DYN; + if (ret > 0 && dynstate) { + state = ret; + ret = 0; +@@ -2503,8 +2503,8 @@ int __cpuhp_setup_state_cpuslocked(enum + out: + mutex_unlock(&cpuhp_state_mutex); + /* +- * If the requested state is CPUHP_AP_ONLINE_DYN, return the +- * dynamically allocated state in case of success. ++ * If the requested state is CPUHP_AP_ONLINE_DYN or CPUHP_BP_PREPARE_DYN, ++ * return the dynamically allocated state in case of success. + */ + if (!ret && dynstate) + return state; diff --git a/queue-6.9/cpufreq-intel_pstate-use-hwp-to-initialize-itmt-if-cppc-is-missing.patch b/queue-6.9/cpufreq-intel_pstate-use-hwp-to-initialize-itmt-if-cppc-is-missing.patch new file mode 100644 index 00000000000..882e2f359c9 --- /dev/null +++ b/queue-6.9/cpufreq-intel_pstate-use-hwp-to-initialize-itmt-if-cppc-is-missing.patch @@ -0,0 +1,64 @@ +From a1ff59784b277795a613beaa5d3dd9c5595c69a7 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Thu, 20 Jun 2024 18:14:53 +0200 +Subject: cpufreq: intel_pstate: Use HWP to initialize ITMT if CPPC is missing + +From: Rafael J. Wysocki + +commit a1ff59784b277795a613beaa5d3dd9c5595c69a7 upstream. + +It is reported that single-thread performance on some hybrid systems +dropped significantly after commit 7feec7430edd ("ACPI: CPPC: Only probe +for _CPC if CPPC v2 is acked") which prevented _CPC from being used if +the support for it had not been confirmed by the platform firmware. + +The problem is that if the platform firmware does not confirm CPPC v2 +support, cppc_get_perf_caps() returns an error which prevents the +intel_pstate driver from enabling ITMT. Consequently, the scheduler +does not get any hints on CPU performance differences, so in a hybrid +system some tasks may run on CPUs with lower capacity even though they +should be running on high-capacity CPUs. + +To address this, modify intel_pstate to use the information from +MSR_HWP_CAPABILITIES to enable ITMT if CPPC is not available (which is +done already if the highest performance number coming from CPPC is not +realistic). + +Fixes: 7feec7430edd ("ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked") +Closes: https://lore.kernel.org/linux-acpi/d01b0a1f-bd33-47fe-ab41-43843d8a374f@kfocus.org +Link: https://lore.kernel.org/linux-acpi/ZnD22b3Br1ng7alf@kf-XE +Reported-by: Aaron Rainbolt +Tested-by: Aaron Rainbolt +Cc: 5.19+ # 5.19+ +Link: https://patch.msgid.link/12460110.O9o76ZdvQC@rjwysocki.net +Signed-off-by: Rafael J. Wysocki +Reviewed-by: Mario Limonciello +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cpufreq/intel_pstate.c | 13 ++++++------- + 1 file changed, 6 insertions(+), 7 deletions(-) + +--- a/drivers/cpufreq/intel_pstate.c ++++ b/drivers/cpufreq/intel_pstate.c +@@ -357,15 +357,14 @@ static void intel_pstate_set_itmt_prio(i + int ret; + + ret = cppc_get_perf_caps(cpu, &cppc_perf); +- if (ret) +- return; +- + /* +- * On some systems with overclocking enabled, CPPC.highest_perf is hardcoded to 0xff. +- * In this case we can't use CPPC.highest_perf to enable ITMT. +- * In this case we can look at MSR_HWP_CAPABILITIES bits [8:0] to decide. ++ * If CPPC is not available, fall back to MSR_HWP_CAPABILITIES bits [8:0]. ++ * ++ * Also, on some systems with overclocking enabled, CPPC.highest_perf is ++ * hardcoded to 0xff, so CPPC.highest_perf cannot be used to enable ITMT. ++ * Fall back to MSR_HWP_CAPABILITIES then too. + */ +- if (cppc_perf.highest_perf == CPPC_MAX_PERF) ++ if (ret || cppc_perf.highest_perf == CPPC_MAX_PERF) + cppc_perf.highest_perf = HWP_HIGHEST_PERF(READ_ONCE(all_cpu_data[cpu]->hwp_cap_cached)); + + /* diff --git a/queue-6.9/csky-hexagon-fix-broken-sys_sync_file_range.patch b/queue-6.9/csky-hexagon-fix-broken-sys_sync_file_range.patch new file mode 100644 index 00000000000..5cf093f929b --- /dev/null +++ b/queue-6.9/csky-hexagon-fix-broken-sys_sync_file_range.patch @@ -0,0 +1,49 @@ +From 3339b99ef6fe38dac43b534cba3a8a0e29fb2eff Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 14 Jun 2024 09:54:20 +0200 +Subject: csky, hexagon: fix broken sys_sync_file_range + +From: Arnd Bergmann + +commit 3339b99ef6fe38dac43b534cba3a8a0e29fb2eff upstream. + +Both of these architectures require u64 function arguments to be +passed in even/odd pairs of registers or stack slots, which in case of +sync_file_range would result in a seven-argument system call that is +not currently possible. The system call is therefore incompatible with +all existing binaries. + +While it would be possible to implement support for seven arguments +like on mips, it seems better to use a six-argument version, either +with the normal argument order but misaligned as on most architectures +or with the reordered sync_file_range2() calling conventions as on +arm and powerpc. + +Cc: stable@vger.kernel.org +Acked-by: Guo Ren +Signed-off-by: Arnd Bergmann +Signed-off-by: Greg Kroah-Hartman +--- + arch/csky/include/uapi/asm/unistd.h | 1 + + arch/hexagon/include/uapi/asm/unistd.h | 1 + + 2 files changed, 2 insertions(+) + +--- a/arch/csky/include/uapi/asm/unistd.h ++++ b/arch/csky/include/uapi/asm/unistd.h +@@ -6,6 +6,7 @@ + #define __ARCH_WANT_SYS_CLONE3 + #define __ARCH_WANT_SET_GET_RLIMIT + #define __ARCH_WANT_TIME32_SYSCALLS ++#define __ARCH_WANT_SYNC_FILE_RANGE2 + #include + + #define __NR_set_thread_area (__NR_arch_specific_syscall + 0) +--- a/arch/hexagon/include/uapi/asm/unistd.h ++++ b/arch/hexagon/include/uapi/asm/unistd.h +@@ -36,5 +36,6 @@ + #define __ARCH_WANT_SYS_VFORK + #define __ARCH_WANT_SYS_FORK + #define __ARCH_WANT_TIME32_SYSCALLS ++#define __ARCH_WANT_SYNC_FILE_RANGE2 + + #include diff --git a/queue-6.9/drm-amd-display-send-dp_total_lttpr_cnt-during-detection-if-lttpr-is-present.patch b/queue-6.9/drm-amd-display-send-dp_total_lttpr_cnt-during-detection-if-lttpr-is-present.patch new file mode 100644 index 00000000000..f4c286ddd1c --- /dev/null +++ b/queue-6.9/drm-amd-display-send-dp_total_lttpr_cnt-during-detection-if-lttpr-is-present.patch @@ -0,0 +1,62 @@ +From 2ec6c7f802332d1eff16f03e7c757f1543ee1183 Mon Sep 17 00:00:00 2001 +From: Michael Strauss +Date: Tue, 28 Nov 2023 10:31:12 -0500 +Subject: drm/amd/display: Send DP_TOTAL_LTTPR_CNT during detection if LTTPR is present + +From: Michael Strauss + +commit 2ec6c7f802332d1eff16f03e7c757f1543ee1183 upstream. + +[WHY] +New register field added in DP2.1 SCR, needed for auxless ALPM + +[HOW] +Echo value read from 0xF0007 back to sink + +Reviewed-by: Wenjing Liu +Cc: Mario Limonciello +Cc: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Alex Hung +Signed-off-by: Michael Strauss +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c | 10 +++++++++- + drivers/gpu/drm/amd/display/include/dpcd_defs.h | 5 +++++ + 2 files changed, 14 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c ++++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c +@@ -1590,9 +1590,17 @@ static bool retrieve_link_cap(struct dc_ + return false; + } + +- if (dp_is_lttpr_present(link)) ++ if (dp_is_lttpr_present(link)) { + configure_lttpr_mode_transparent(link); + ++ // Echo TOTAL_LTTPR_CNT back downstream ++ core_link_write_dpcd( ++ link, ++ DP_TOTAL_LTTPR_CNT, ++ &link->dpcd_caps.lttpr_caps.phy_repeater_cnt, ++ sizeof(link->dpcd_caps.lttpr_caps.phy_repeater_cnt)); ++ } ++ + /* Read DP tunneling information. */ + status = dpcd_get_tunneling_device_data(link); + +--- a/drivers/gpu/drm/amd/display/include/dpcd_defs.h ++++ b/drivers/gpu/drm/amd/display/include/dpcd_defs.h +@@ -177,4 +177,9 @@ enum dpcd_psr_sink_states { + #define DP_SINK_PR_PIXEL_DEVIATION_PER_LINE 0x379 + #define DP_SINK_PR_MAX_NUMBER_OF_DEVIATION_LINE 0x37A + ++/* Remove once drm_dp_helper.h is updated upstream */ ++#ifndef DP_TOTAL_LTTPR_CNT ++#define DP_TOTAL_LTTPR_CNT 0xF000A /* 2.1 */ ++#endif ++ + #endif /* __DAL_DPCD_DEFS_H__ */ diff --git a/queue-6.9/drm-amdgpu-atomfirmware-fix-parsing-of-vram_info.patch b/queue-6.9/drm-amdgpu-atomfirmware-fix-parsing-of-vram_info.patch new file mode 100644 index 00000000000..f30761d12b1 --- /dev/null +++ b/queue-6.9/drm-amdgpu-atomfirmware-fix-parsing-of-vram_info.patch @@ -0,0 +1,35 @@ +From f6f49dda49db72e7a0b4ca32c77391d5ff5ce232 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Fri, 14 Jun 2024 13:48:26 -0400 +Subject: drm/amdgpu/atomfirmware: fix parsing of vram_info + +From: Alex Deucher + +commit f6f49dda49db72e7a0b4ca32c77391d5ff5ce232 upstream. + +v3.x changed the how vram width was encoded. The previous +implementation actually worked correctly for most boards. +Fix the implementation to work correctly everywhere. + +This fixes the vram width reported in the kernel log on +some boards. + +Reviewed-by: Hawking Zhang +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c +@@ -399,7 +399,7 @@ amdgpu_atomfirmware_get_vram_info(struct + mem_channel_number = vram_info->v30.channel_num; + mem_channel_width = vram_info->v30.channel_width; + if (vram_width) +- *vram_width = mem_channel_number * (1 << mem_channel_width); ++ *vram_width = mem_channel_number * 16; + break; + default: + return -EINVAL; diff --git a/queue-6.9/drm-amdgpu-avoid-using-null-object-of-framebuffer.patch b/queue-6.9/drm-amdgpu-avoid-using-null-object-of-framebuffer.patch new file mode 100644 index 00000000000..fb75cb4c3f8 --- /dev/null +++ b/queue-6.9/drm-amdgpu-avoid-using-null-object-of-framebuffer.patch @@ -0,0 +1,69 @@ +From bcfa48ff785bd121316592b131ff6531e3e696bb Mon Sep 17 00:00:00 2001 +From: Julia Zhang +Date: Mon, 3 Jun 2024 19:31:09 +0800 +Subject: drm/amdgpu: avoid using null object of framebuffer + +From: Julia Zhang + +commit bcfa48ff785bd121316592b131ff6531e3e696bb upstream. + +Instead of using state->fb->obj[0] directly, get object from framebuffer +by calling drm_gem_fb_get_obj() and return error code when object is +null to avoid using null object of framebuffer. + +Reported-by: Fusheng Huang +Signed-off-by: Julia Zhang +Reviewed-by: Huang Rui +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 18 ++++++++++++++++-- + 1 file changed, 16 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c +@@ -3,6 +3,7 @@ + #include + #include + #include ++#include + #include + + #include "amdgpu.h" +@@ -314,7 +315,13 @@ static int amdgpu_vkms_prepare_fb(struct + return 0; + } + afb = to_amdgpu_framebuffer(new_state->fb); +- obj = new_state->fb->obj[0]; ++ ++ obj = drm_gem_fb_get_obj(new_state->fb, 0); ++ if (!obj) { ++ DRM_ERROR("Failed to get obj from framebuffer\n"); ++ return -EINVAL; ++ } ++ + rbo = gem_to_amdgpu_bo(obj); + adev = amdgpu_ttm_adev(rbo->tbo.bdev); + +@@ -368,12 +375,19 @@ static void amdgpu_vkms_cleanup_fb(struc + struct drm_plane_state *old_state) + { + struct amdgpu_bo *rbo; ++ struct drm_gem_object *obj; + int r; + + if (!old_state->fb) + return; + +- rbo = gem_to_amdgpu_bo(old_state->fb->obj[0]); ++ obj = drm_gem_fb_get_obj(old_state->fb, 0); ++ if (!obj) { ++ DRM_ERROR("Failed to get obj from framebuffer\n"); ++ return; ++ } ++ ++ rbo = gem_to_amdgpu_bo(obj); + r = amdgpu_bo_reserve(rbo, false); + if (unlikely(r)) { + DRM_ERROR("failed to reserve rbo before unpin\n"); diff --git a/queue-6.9/drm-drm_file-fix-pid-refcounting-race.patch b/queue-6.9/drm-drm_file-fix-pid-refcounting-race.patch new file mode 100644 index 00000000000..b30d6d8f11f --- /dev/null +++ b/queue-6.9/drm-drm_file-fix-pid-refcounting-race.patch @@ -0,0 +1,79 @@ +From 4f2a129b33a2054e62273edd5a051c34c08d96e9 Mon Sep 17 00:00:00 2001 +From: Jann Horn +Date: Thu, 27 Jun 2024 11:26:00 +1000 +Subject: drm/drm_file: Fix pid refcounting race + +From: Jann Horn + +commit 4f2a129b33a2054e62273edd5a051c34c08d96e9 upstream. + +, Maxime Ripard +, Thomas Zimmermann + +filp->pid is supposed to be a refcounted pointer; however, before this +patch, drm_file_update_pid() only increments the refcount of a struct +pid after storing a pointer to it in filp->pid and dropping the +dev->filelist_mutex, making the following race possible: + +process A process B +========= ========= + begin drm_file_update_pid + mutex_lock(&dev->filelist_mutex) + rcu_replace_pointer(filp->pid, , 1) + mutex_unlock(&dev->filelist_mutex) +begin drm_file_update_pid +mutex_lock(&dev->filelist_mutex) +rcu_replace_pointer(filp->pid, , 1) +mutex_unlock(&dev->filelist_mutex) +get_pid() +synchronize_rcu() +put_pid() *** pid B reaches refcount 0 and is freed here *** + get_pid() *** UAF *** + synchronize_rcu() + put_pid() + +As far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y +because it requires RCU to detect a quiescent state in code that is not +explicitly calling into the scheduler. + +This race leads to use-after-free of a "struct pid". +It is probably somewhat hard to hit because process A has to pass +through a synchronize_rcu() operation while process B is between +mutex_unlock() and get_pid(). + +Fix it by ensuring that by the time a pointer to the current task's pid +is stored in the file, an extra reference to the pid has been taken. + +This fix also removes the condition for synchronize_rcu(); I think +that optimization is unnecessary complexity, since in that case we +would usually have bailed out on the lockless check above. + +Fixes: 1c7a387ffef8 ("drm: Update file owner during use") +Cc: +Signed-off-by: Jann Horn +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_file.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/drm_file.c ++++ b/drivers/gpu/drm/drm_file.c +@@ -469,14 +469,12 @@ void drm_file_update_pid(struct drm_file + + dev = filp->minor->dev; + mutex_lock(&dev->filelist_mutex); ++ get_pid(pid); + old = rcu_replace_pointer(filp->pid, pid, 1); + mutex_unlock(&dev->filelist_mutex); + +- if (pid != old) { +- get_pid(pid); +- synchronize_rcu(); +- put_pid(old); +- } ++ synchronize_rcu(); ++ put_pid(old); + } + + /** diff --git a/queue-6.9/drm-fbdev-dma-only-set-smem_start-is-enable-per-module-option.patch b/queue-6.9/drm-fbdev-dma-only-set-smem_start-is-enable-per-module-option.patch new file mode 100644 index 00000000000..e38a2b9a961 --- /dev/null +++ b/queue-6.9/drm-fbdev-dma-only-set-smem_start-is-enable-per-module-option.patch @@ -0,0 +1,97 @@ +From d92a7580392ad4681b1d4f9275d00b95375ebe01 Mon Sep 17 00:00:00 2001 +From: Thomas Zimmermann +Date: Mon, 17 Jun 2024 17:26:37 +0200 +Subject: drm/fbdev-dma: Only set smem_start is enable per module option + +From: Thomas Zimmermann + +commit d92a7580392ad4681b1d4f9275d00b95375ebe01 upstream. + +Only export struct fb_info.fix.smem_start if that is required by the +user and the memory does not come from vmalloc(). + +Setting struct fb_info.fix.smem_start breaks systems where DMA +memory is backed by vmalloc address space. An example error is +shown below. + +[ 3.536043] ------------[ cut here ]------------ +[ 3.540716] virt_to_phys used for non-linear address: 000000007fc4f540 (0xffff800086001000) +[ 3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98 +[ 3.565455] Modules linked in: +[ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted 6.6.23-06226-g4986cc3e1b75-dirty #250 +[ 3.577310] Hardware name: NXP i.MX95 19X19 board (DT) +[ 3.582452] Workqueue: events_unbound deferred_probe_work_func +[ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) +[ 3.595233] pc : __virt_to_phys+0x68/0x98 +[ 3.599246] lr : __virt_to_phys+0x68/0x98 +[ 3.603276] sp : ffff800083603990 +[ 3.677939] Call trace: +[ 3.680393] __virt_to_phys+0x68/0x98 +[ 3.684067] drm_fbdev_dma_helper_fb_probe+0x138/0x238 +[ 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0 +[ 3.695385] drm_fb_helper_initial_config+0x4c/0x68 +[ 3.700264] drm_fbdev_dma_client_hotplug+0x8c/0xe0 +[ 3.705161] drm_client_register+0x60/0xb0 +[ 3.709269] drm_fbdev_dma_setup+0x94/0x148 + +Additionally, DMA memory is assumed to by contiguous in physical +address space, which is not guaranteed by vmalloc(). + +Resolve this by checking the module flag drm_leak_fbdev_smem when +DRM allocated the instance of struct fb_info. Fbdev-dma then only +sets smem_start only if required (via FBINFO_HIDE_SMEM_START). Also +guarantee that the framebuffer is not located in vmalloc address +space. + +Signed-off-by: Thomas Zimmermann +Reported-by: Peng Fan (OSS) +Closes: https://lore.kernel.org/dri-devel/20240604080328.4024838-1-peng.fan@oss.nxp.com/ +Reported-by: Geert Uytterhoeven +Closes: https://lore.kernel.org/dri-devel/CAMuHMdX3N0szUvt1VTbroa2zrT1Nye_VzPb5qqCZ7z5gSm7HGw@mail.gmail.com/ +Fixes: a51c7663f144 ("drm/fb-helper: Consolidate CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM") +Tested-by: Geert Uytterhoeven +Reviewed-by: Daniel Vetter +Cc: # v6.4+ +Link: https://patchwork.freedesktop.org/patch/msgid/20240617152843.11886-1-tzimmermann@suse.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_fb_helper.c | 6 +++--- + drivers/gpu/drm/drm_fbdev_dma.c | 5 ++++- + 2 files changed, 7 insertions(+), 4 deletions(-) + +--- a/drivers/gpu/drm/drm_fb_helper.c ++++ b/drivers/gpu/drm/drm_fb_helper.c +@@ -524,6 +524,9 @@ struct fb_info *drm_fb_helper_alloc_info + if (!info) + return ERR_PTR(-ENOMEM); + ++ if (!drm_leak_fbdev_smem) ++ info->flags |= FBINFO_HIDE_SMEM_START; ++ + ret = fb_alloc_cmap(&info->cmap, 256, 0); + if (ret) + goto err_release; +@@ -1860,9 +1863,6 @@ __drm_fb_helper_initial_config_and_unloc + info = fb_helper->info; + info->var.pixclock = 0; + +- if (!drm_leak_fbdev_smem) +- info->flags |= FBINFO_HIDE_SMEM_START; +- + /* Need to drop locks to avoid recursive deadlock in + * register_framebuffer. This is ok because the only thing left to do is + * register the fbdev emulation instance in kernel_fb_helper_list. */ +--- a/drivers/gpu/drm/drm_fbdev_dma.c ++++ b/drivers/gpu/drm/drm_fbdev_dma.c +@@ -130,7 +130,10 @@ static int drm_fbdev_dma_helper_fb_probe + info->flags |= FBINFO_READS_FAST; /* signal caching */ + info->screen_size = sizes->surface_height * fb->pitches[0]; + info->screen_buffer = map.vaddr; +- info->fix.smem_start = page_to_phys(virt_to_page(info->screen_buffer)); ++ if (!(info->flags & FBINFO_HIDE_SMEM_START)) { ++ if (!drm_WARN_ON(dev, is_vmalloc_addr(info->screen_buffer))) ++ info->fix.smem_start = page_to_phys(virt_to_page(info->screen_buffer)); ++ } + info->fix.smem_len = info->screen_size; + + return 0; diff --git a/queue-6.9/drm-i915-gt-fix-potential-uaf-by-revoke-of-fence-registers.patch b/queue-6.9/drm-i915-gt-fix-potential-uaf-by-revoke-of-fence-registers.patch new file mode 100644 index 00000000000..83923f6f488 --- /dev/null +++ b/queue-6.9/drm-i915-gt-fix-potential-uaf-by-revoke-of-fence-registers.patch @@ -0,0 +1,84 @@ +From 996c3412a06578e9d779a16b9e79ace18125ab50 Mon Sep 17 00:00:00 2001 +From: Janusz Krzysztofik +Date: Mon, 3 Jun 2024 21:54:45 +0200 +Subject: drm/i915/gt: Fix potential UAF by revoke of fence registers + +From: Janusz Krzysztofik + +commit 996c3412a06578e9d779a16b9e79ace18125ab50 upstream. + +CI has been sporadically reporting the following issue triggered by +igt@i915_selftest@live@hangcheck on ADL-P and similar machines: + +<6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence +... +<6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled +<6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled +<3> [414.070354] Unable to pin Y-tiled fence; err:-4 +<3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) +... +<4>[ 609.603992] ------------[ cut here ]------------ +<2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! +<4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI +<4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 +<4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 +<4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] +<4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] +... +<4>[ 609.604271] Call Trace: +<4>[ 609.604273] +... +<4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] +<4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] +<4>[ 609.604977] force_unbind+0x24/0xa0 [i915] +<4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] +<4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] +<4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] +<4>[ 609.605440] process_scheduled_works+0x351/0x690 +... + +In the past, there were similar failures reported by CI from other IGT +tests, observed on other platforms. + +Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity +before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for +idleness of vma->active via fence_update(). That commit introduced +vma->fence->active in order for the fence_update() to be able to wait +selectively on that one instead of vma->active since only idleness of +fence registers was needed. But then, another commit 0d86ee35097a +("drm/i915/gt: Make fence revocation unequivocal") replaced the call to +fence_update() in i915_vma_revoke_fence() with only fence_write(), and +also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. +No justification was provided on why we might then expect idleness of +vma->fence->active without first waiting on it. + +The issue can be potentially caused by a race among revocation of fence +registers on one side and sequential execution of signal callbacks invoked +on completion of a request that was using them on the other, still +processed in parallel to revocation of those fence registers. Fix it by +waiting for idleness of vma->fence->active in i915_vma_revoke_fence(). + +Fixes: 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") +Closes: https://gitlab.freedesktop.org/drm/intel/issues/10021 +Signed-off-by: Janusz Krzysztofik +Cc: stable@vger.kernel.org # v5.8+ +Reviewed-by: Andi Shyti +Signed-off-by: Andi Shyti +Link: https://patchwork.freedesktop.org/patch/msgid/20240603195446.297690-2-janusz.krzysztofik@linux.intel.com +(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c ++++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c +@@ -298,6 +298,7 @@ void i915_vma_revoke_fence(struct i915_v + return; + + GEM_BUG_ON(fence->vma != vma); ++ i915_active_wait(&fence->active); + GEM_BUG_ON(!i915_active_is_idle(&fence->active)); + GEM_BUG_ON(atomic_read(&fence->pin_count)); + diff --git a/queue-6.9/drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_hd_modes.patch b/queue-6.9/drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_hd_modes.patch new file mode 100644 index 00000000000..e5ba75c58cb --- /dev/null +++ b/queue-6.9/drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_hd_modes.patch @@ -0,0 +1,43 @@ +From 6d411c8ccc0137a612e0044489030a194ff5c843 Mon Sep 17 00:00:00 2001 +From: Ma Ke +Date: Tue, 25 Jun 2024 16:10:29 +0800 +Subject: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes + +From: Ma Ke + +commit 6d411c8ccc0137a612e0044489030a194ff5c843 upstream. + +In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is +assigned to mode, which will lead to a possible NULL pointer dereference +on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). +Add a check to avoid null pointer dereference. + +Cc: stable@vger.kernel.org +Signed-off-by: Ma Ke +Signed-off-by: Lyude Paul +Link: https://patchwork.freedesktop.org/patch/msgid/20240625081029.2619437-1-make24@iscas.ac.cn +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c ++++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c +@@ -260,6 +260,8 @@ static int nv17_tv_get_hd_modes(struct d + if (modes[i].hdisplay == output_mode->hdisplay && + modes[i].vdisplay == output_mode->vdisplay) { + mode = drm_mode_duplicate(encoder->dev, output_mode); ++ if (!mode) ++ continue; + mode->type |= DRM_MODE_TYPE_PREFERRED; + + } else { +@@ -267,6 +269,8 @@ static int nv17_tv_get_hd_modes(struct d + modes[i].vdisplay, 60, false, + (output_mode->flags & + DRM_MODE_FLAG_INTERLACE), false); ++ if (!mode) ++ continue; + } + + /* CVT modes are sometimes unsuitable... */ diff --git a/queue-6.9/drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_ld_modes.patch b/queue-6.9/drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_ld_modes.patch new file mode 100644 index 00000000000..f2ed9a028e6 --- /dev/null +++ b/queue-6.9/drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_ld_modes.patch @@ -0,0 +1,33 @@ +From 66edf3fb331b6c55439b10f9862987b0916b3726 Mon Sep 17 00:00:00 2001 +From: Ma Ke +Date: Tue, 25 Jun 2024 16:18:28 +0800 +Subject: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes + +From: Ma Ke + +commit 66edf3fb331b6c55439b10f9862987b0916b3726 upstream. + +In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is +assigned to mode, which will lead to a possible NULL pointer dereference +on failure of drm_mode_duplicate(). Add a check to avoid npd. + +Cc: stable@vger.kernel.org +Signed-off-by: Ma Ke +Signed-off-by: Lyude Paul +Link: https://patchwork.freedesktop.org/patch/msgid/20240625081828.2620794-1-make24@iscas.ac.cn +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c ++++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c +@@ -209,6 +209,8 @@ static int nv17_tv_get_ld_modes(struct d + struct drm_display_mode *mode; + + mode = drm_mode_duplicate(encoder->dev, tv_mode); ++ if (!mode) ++ continue; + + mode->clock = tv_norm->tv_enc_mode.vrefresh * + mode->htotal / 1000 * diff --git a/queue-6.9/hexagon-fix-fadvise64_64-calling-conventions.patch b/queue-6.9/hexagon-fix-fadvise64_64-calling-conventions.patch new file mode 100644 index 00000000000..9388861776c --- /dev/null +++ b/queue-6.9/hexagon-fix-fadvise64_64-calling-conventions.patch @@ -0,0 +1,52 @@ +From 896842284c6ccba25ec9d78b7b6e62cdd507c083 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Thu, 20 Jun 2024 15:24:11 +0200 +Subject: hexagon: fix fadvise64_64 calling conventions + +From: Arnd Bergmann + +commit 896842284c6ccba25ec9d78b7b6e62cdd507c083 upstream. + +fadvise64_64() has two 64-bit arguments at the wrong alignment +for hexagon, which turns them into a 7-argument syscall that is +not supported by Linux. + +The downstream musl port for hexagon actually asks for a 6-argument +version the same way we do it on arm, csky, powerpc, so make the +kernel do it the same way to avoid having to change both. + +Link: https://github.com/quic/musl/blob/hexagon/arch/hexagon/syscall_arch.h#L78 +Cc: stable@vger.kernel.org +Signed-off-by: Arnd Bergmann +Signed-off-by: Greg Kroah-Hartman +--- + arch/hexagon/include/asm/syscalls.h | 6 ++++++ + arch/hexagon/kernel/syscalltab.c | 7 +++++++ + 2 files changed, 13 insertions(+) + create mode 100644 arch/hexagon/include/asm/syscalls.h + +--- /dev/null ++++ b/arch/hexagon/include/asm/syscalls.h +@@ -0,0 +1,6 @@ ++/* SPDX-License-Identifier: GPL-2.0 */ ++ ++#include ++ ++asmlinkage long sys_hexagon_fadvise64_64(int fd, int advice, ++ u32 a2, u32 a3, u32 a4, u32 a5); +--- a/arch/hexagon/kernel/syscalltab.c ++++ b/arch/hexagon/kernel/syscalltab.c +@@ -14,6 +14,13 @@ + #undef __SYSCALL + #define __SYSCALL(nr, call) [nr] = (call), + ++SYSCALL_DEFINE6(hexagon_fadvise64_64, int, fd, int, advice, ++ SC_ARG64(offset), SC_ARG64(len)) ++{ ++ return ksys_fadvise64_64(fd, SC_VAL64(loff_t, offset), SC_VAL64(loff_t, len), advice); ++} ++#define sys_fadvise64_64 sys_hexagon_fadvise64_64 ++ + void *sys_call_table[__NR_syscalls] = { + #include + }; diff --git a/queue-6.9/irqchip-loongson-eiointc-use-early_cpu_to_node-instead-of-cpu_to_node.patch b/queue-6.9/irqchip-loongson-eiointc-use-early_cpu_to_node-instead-of-cpu_to_node.patch new file mode 100644 index 00000000000..cefad33c8de --- /dev/null +++ b/queue-6.9/irqchip-loongson-eiointc-use-early_cpu_to_node-instead-of-cpu_to_node.patch @@ -0,0 +1,70 @@ +From 2d64eaeeeda5659d52da1af79d237269ba3c2d2c Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Sun, 23 Jun 2024 11:41:13 +0800 +Subject: irqchip/loongson-eiointc: Use early_cpu_to_node() instead of cpu_to_node() + +From: Huacai Chen + +commit 2d64eaeeeda5659d52da1af79d237269ba3c2d2c upstream. + +Multi-bridge machines required that all eiointc controllers in the system +are initialized, otherwise the system does not boot. + +The initialization happens on the boot CPU during early boot and relies on +cpu_to_node() for identifying the individual nodes. + +That works when the number of possible CPUs is large enough, but with a +command line limit, e.g. "nr_cpus=$N" for kdump, but fails when the CPUs +of the secondary nodes are not covered. + +During early ACPI enumeration all CPU to node mappings are recorded up to +CONFIG_NR_CPUS. These are accessible via early_cpu_to_node() even in the +case that "nr_cpus=N" truncates the number of possible CPUs and only +provides the possible CPUs via cpu_to_node() translation. + +Change the node lookup in the driver to use early_cpu_to_node() so that +even with a limitation on the number of possible CPUs all eointc instances +are initialized. + +This can't obviously cure the case where CONFIG_NR_CPUS is too small. + +[ tglx: Massaged changelog ] + +Fixes: 64cc451e45e1 ("irqchip/loongson-eiointc: Fix incorrect use of acpi_get_vec_parent") +Signed-off-by: Huacai Chen +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20240623034113.1808727-1-chenhuacai@loongson.cn +Signed-off-by: Greg Kroah-Hartman +--- + drivers/irqchip/irq-loongson-eiointc.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/irqchip/irq-loongson-eiointc.c ++++ b/drivers/irqchip/irq-loongson-eiointc.c +@@ -15,6 +15,7 @@ + #include + #include + #include ++#include + + #define EIOINTC_REG_NODEMAP 0x14a0 + #define EIOINTC_REG_IPMAP 0x14c0 +@@ -339,7 +340,7 @@ static int __init pch_msi_parse_madt(uni + int node; + + if (cpu_has_flatmode) +- node = cpu_to_node(eiointc_priv[nr_pics - 1]->node * CORES_PER_EIO_NODE); ++ node = early_cpu_to_node(eiointc_priv[nr_pics - 1]->node * CORES_PER_EIO_NODE); + else + node = eiointc_priv[nr_pics - 1]->node; + +@@ -431,7 +432,7 @@ int __init eiointc_acpi_init(struct irq_ + goto out_free_handle; + + if (cpu_has_flatmode) +- node = cpu_to_node(acpi_eiointc->node * CORES_PER_EIO_NODE); ++ node = early_cpu_to_node(acpi_eiointc->node * CORES_PER_EIO_NODE); + else + node = acpi_eiointc->node; + acpi_set_vec_parent(node, priv->eiointc_domain, pch_group); diff --git a/queue-6.9/irqchip-loongson-liointc-set-different-isrs-for-different-cores.patch b/queue-6.9/irqchip-loongson-liointc-set-different-isrs-for-different-cores.patch new file mode 100644 index 00000000000..4a2dadaf13a --- /dev/null +++ b/queue-6.9/irqchip-loongson-liointc-set-different-isrs-for-different-cores.patch @@ -0,0 +1,53 @@ +From a9c3ee5d0fdb069b54902300df6ac822027f3b0a Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Sat, 22 Jun 2024 12:33:38 +0800 +Subject: irqchip/loongson-liointc: Set different ISRs for different cores + +From: Huacai Chen + +commit a9c3ee5d0fdb069b54902300df6ac822027f3b0a upstream. + +The liointc hardware provides separate Interrupt Status Registers (ISR) for +each core. The current code uses always the ISR of core #0, which works +during boot because by default all interrupts are routed to core #0. + +When the interrupt routing changes in the firmware configuration then this +causes interrupts to be lost because they are not configured in the +corresponding core. + +Use the core index to access the correct ISR instead of a hardcoded 0. + +[ tglx: Massaged changelog ] + +Fixes: 0858ed035a85 ("irqchip/loongson-liointc: Add ACPI init support") +Co-developed-by: Tianli Xiong +Signed-off-by: Tianli Xiong +Signed-off-by: Huacai Chen +Signed-off-by: Thomas Gleixner +Cc: +Link: https://lore.kernel.org/r/20240622043338.1566945-1-chenhuacai@loongson.cn +Signed-off-by: Greg Kroah-Hartman +--- + drivers/irqchip/irq-loongson-liointc.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/irqchip/irq-loongson-liointc.c ++++ b/drivers/irqchip/irq-loongson-liointc.c +@@ -28,7 +28,7 @@ + + #define LIOINTC_INTC_CHIP_START 0x20 + +-#define LIOINTC_REG_INTC_STATUS (LIOINTC_INTC_CHIP_START + 0x20) ++#define LIOINTC_REG_INTC_STATUS(core) (LIOINTC_INTC_CHIP_START + 0x20 + (core) * 8) + #define LIOINTC_REG_INTC_EN_STATUS (LIOINTC_INTC_CHIP_START + 0x04) + #define LIOINTC_REG_INTC_ENABLE (LIOINTC_INTC_CHIP_START + 0x08) + #define LIOINTC_REG_INTC_DISABLE (LIOINTC_INTC_CHIP_START + 0x0c) +@@ -217,7 +217,7 @@ static int liointc_init(phys_addr_t addr + goto out_free_priv; + + for (i = 0; i < LIOINTC_NUM_CORES; i++) +- priv->core_isr[i] = base + LIOINTC_REG_INTC_STATUS; ++ priv->core_isr[i] = base + LIOINTC_REG_INTC_STATUS(i); + + for (i = 0; i < LIOINTC_NUM_PARENT; i++) + priv->handler[i].parent_int_map = parent_int_map[i]; diff --git a/queue-6.9/kbuild-install-dtb-files-as-0644-in-makefile.dtbinst.patch b/queue-6.9/kbuild-install-dtb-files-as-0644-in-makefile.dtbinst.patch new file mode 100644 index 00000000000..7333ff93fff --- /dev/null +++ b/queue-6.9/kbuild-install-dtb-files-as-0644-in-makefile.dtbinst.patch @@ -0,0 +1,45 @@ +From 9cc5f3bf63aa98bd7cc7ce8a8599077fde13283e Mon Sep 17 00:00:00 2001 +From: Dragan Simic +Date: Mon, 10 Jun 2024 07:21:12 +0200 +Subject: kbuild: Install dtb files as 0644 in Makefile.dtbinst + +From: Dragan Simic + +commit 9cc5f3bf63aa98bd7cc7ce8a8599077fde13283e upstream. + +The compiled dtb files aren't executable, so install them with 0644 as their +permission mode, instead of defaulting to 0755 for the permission mode and +installing them with the executable bits set. + +Some Linux distributions, including Debian, [1][2][3] already include fixes +in their kernel package build recipes to change the dtb file permissions to +0644 in their kernel packages. These changes, when additionally propagated +into the long-term kernel versions, will allow such distributions to remove +their downstream fixes. + +[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/642 +[2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/749 +[3] https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.8.12-1/debian/rules.real#L193 + +Cc: Diederik de Haas +Cc: +Fixes: aefd80307a05 ("kbuild: refactor Makefile.dtbinst more") +Signed-off-by: Dragan Simic +Reviewed-by: Nicolas Schier +Signed-off-by: Masahiro Yamada +Signed-off-by: Greg Kroah-Hartman +--- + scripts/Makefile.dtbinst | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/scripts/Makefile.dtbinst ++++ b/scripts/Makefile.dtbinst +@@ -17,7 +17,7 @@ include $(srctree)/scripts/Kbuild.includ + dst := $(INSTALL_DTBS_PATH) + + quiet_cmd_dtb_install = INSTALL $@ +- cmd_dtb_install = install -D $< $@ ++ cmd_dtb_install = install -D -m 0644 $< $@ + + $(dst)/%: $(obj)/% + $(call cmd,dtb_install) diff --git a/queue-6.9/net-can-j1939-enhanced-error-handling-for-tightly-received-rts-messages-in-xtp_rx_rts_session_new.patch b/queue-6.9/net-can-j1939-enhanced-error-handling-for-tightly-received-rts-messages-in-xtp_rx_rts_session_new.patch new file mode 100644 index 00000000000..fb672f1e135 --- /dev/null +++ b/queue-6.9/net-can-j1939-enhanced-error-handling-for-tightly-received-rts-messages-in-xtp_rx_rts_session_new.patch @@ -0,0 +1,73 @@ +From d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb Mon Sep 17 00:00:00 2001 +From: Oleksij Rempel +Date: Fri, 17 Nov 2023 13:49:59 +0100 +Subject: net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new + +From: Oleksij Rempel + +commit d3e2904f71ea0fe7eaff1d68a2b0363c888ea0fb upstream. + +This patch enhances error handling in scenarios with RTS (Request to +Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE +backtraces with a new error handling method. This provides clearer error +messages and allows for the early termination of problematic sessions. +Previously, sessions were only released at the end of j1939_xtp_rx_rts(). + +Potentially this could be reproduced with something like: +testj1939 -r vcan0:0x80 & +while true; do + # send first RTS + cansend vcan0 18EC8090#1014000303002301; + # send second RTS + cansend vcan0 18EC8090#1014000303002301; + # send abort + cansend vcan0 18EC8090#ff00000000002301; +done + +Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") +Reported-by: syzbot+daa36413a5cedf799ae4@syzkaller.appspotmail.com +Cc: stable@vger.kernel.org +Signed-off-by: Oleksij Rempel +Link: https://lore.kernel.org/all/20231117124959.961171-1-o.rempel@pengutronix.de +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + net/can/j1939/transport.c | 19 +++++++++++++++++-- + 1 file changed, 17 insertions(+), 2 deletions(-) + +--- a/net/can/j1939/transport.c ++++ b/net/can/j1939/transport.c +@@ -1593,8 +1593,8 @@ j1939_session *j1939_xtp_rx_rts_session_ + struct j1939_sk_buff_cb skcb = *j1939_skb_to_cb(skb); + struct j1939_session *session; + const u8 *dat; ++ int len, ret; + pgn_t pgn; +- int len; + + netdev_dbg(priv->ndev, "%s\n", __func__); + +@@ -1653,7 +1653,22 @@ j1939_session *j1939_xtp_rx_rts_session_ + session->tskey = priv->rx_tskey++; + j1939_sk_errqueue(session, J1939_ERRQUEUE_RX_RTS); + +- WARN_ON_ONCE(j1939_session_activate(session)); ++ ret = j1939_session_activate(session); ++ if (ret) { ++ /* Entering this scope indicates an issue with the J1939 bus. ++ * Possible scenarios include: ++ * - A time lapse occurred, and a new session was initiated ++ * due to another packet being sent correctly. This could ++ * have been caused by too long interrupt, debugger, or being ++ * out-scheduled by another task. ++ * - The bus is receiving numerous erroneous packets, either ++ * from a malfunctioning device or during a test scenario. ++ */ ++ netdev_alert(priv->ndev, "%s: 0x%p: concurrent session with same addr (%02x %02x) is already active.\n", ++ __func__, session, skcb.addr.sa, skcb.addr.da); ++ j1939_session_put(session); ++ return NULL; ++ } + + return session; + } diff --git a/queue-6.9/net-can-j1939-initialize-unused-data-in-j1939_send_one.patch b/queue-6.9/net-can-j1939-initialize-unused-data-in-j1939_send_one.patch new file mode 100644 index 00000000000..63a2a56815e --- /dev/null +++ b/queue-6.9/net-can-j1939-initialize-unused-data-in-j1939_send_one.patch @@ -0,0 +1,112 @@ +From b7cdf1dd5d2a2d8200efd98d1893684db48fe134 Mon Sep 17 00:00:00 2001 +From: Shigeru Yoshida +Date: Fri, 17 May 2024 12:59:53 +0900 +Subject: net: can: j1939: Initialize unused data in j1939_send_one() + +From: Shigeru Yoshida + +commit b7cdf1dd5d2a2d8200efd98d1893684db48fe134 upstream. + +syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one() +creates full frame including unused data, but it doesn't initialize +it. This causes the kernel-infoleak issue. Fix this by initializing +unused data. + +[1] +BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] +BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] +BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] +BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] +BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] +BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 + instrument_copy_to_user include/linux/instrumented.h:114 [inline] + copy_to_user_iter lib/iov_iter.c:24 [inline] + iterate_ubuf include/linux/iov_iter.h:29 [inline] + iterate_and_advance2 include/linux/iov_iter.h:245 [inline] + iterate_and_advance include/linux/iov_iter.h:271 [inline] + _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 + copy_to_iter include/linux/uio.h:196 [inline] + memcpy_to_msg include/linux/skbuff.h:4113 [inline] + raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008 + sock_recvmsg_nosec net/socket.c:1046 [inline] + sock_recvmsg+0x2c4/0x340 net/socket.c:1068 + ____sys_recvmsg+0x18a/0x620 net/socket.c:2803 + ___sys_recvmsg+0x223/0x840 net/socket.c:2845 + do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939 + __sys_recvmmsg net/socket.c:3018 [inline] + __do_sys_recvmmsg net/socket.c:3041 [inline] + __se_sys_recvmmsg net/socket.c:3034 [inline] + __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034 + x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + +Uninit was created at: + slab_post_alloc_hook mm/slub.c:3804 [inline] + slab_alloc_node mm/slub.c:3845 [inline] + kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 + kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 + __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 + alloc_skb include/linux/skbuff.h:1313 [inline] + alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 + sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 + sock_alloc_send_skb include/net/sock.h:1842 [inline] + j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline] + j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline] + j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277 + sock_sendmsg_nosec net/socket.c:730 [inline] + __sock_sendmsg+0x30f/0x380 net/socket.c:745 + ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 + ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 + __sys_sendmsg net/socket.c:2667 [inline] + __do_sys_sendmsg net/socket.c:2676 [inline] + __se_sys_sendmsg net/socket.c:2674 [inline] + __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 + x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + +Bytes 12-15 of 16 are uninitialized +Memory access of size 16 starts at ffff888120969690 +Data copied to user address 00000000200017c0 + +CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 + +Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") +Reported-and-tested-by: syzbot+5681e40d297b30f5b513@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=5681e40d297b30f5b513 +Acked-by: Oleksij Rempel +Signed-off-by: Shigeru Yoshida +Link: https://lore.kernel.org/all/20240517035953.2617090-1-syoshida@redhat.com +Cc: stable@vger.kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + net/can/j1939/main.c | 6 +----- + 1 file changed, 1 insertion(+), 5 deletions(-) + +--- a/net/can/j1939/main.c ++++ b/net/can/j1939/main.c +@@ -30,10 +30,6 @@ MODULE_ALIAS("can-proto-" __stringify(CA + /* CAN_HDR: #bytes before can_frame data part */ + #define J1939_CAN_HDR (offsetof(struct can_frame, data)) + +-/* CAN_FTR: #bytes beyond data part */ +-#define J1939_CAN_FTR (sizeof(struct can_frame) - J1939_CAN_HDR - \ +- sizeof(((struct can_frame *)0)->data)) +- + /* lowest layer */ + static void j1939_can_recv(struct sk_buff *iskb, void *data) + { +@@ -342,7 +338,7 @@ int j1939_send_one(struct j1939_priv *pr + memset(cf, 0, J1939_CAN_HDR); + + /* make it a full can frame again */ +- skb_put(skb, J1939_CAN_FTR + (8 - dlc)); ++ skb_put_zero(skb, 8 - dlc); + + canid = CAN_EFF_FLAG | + (skcb->priority << 26) | diff --git a/queue-6.9/net-can-j1939-recover-socket-queue-on-can-bus-error-during-bam-transmission.patch b/queue-6.9/net-can-j1939-recover-socket-queue-on-can-bus-error-during-bam-transmission.patch new file mode 100644 index 00000000000..890f4e39d16 --- /dev/null +++ b/queue-6.9/net-can-j1939-recover-socket-queue-on-can-bus-error-during-bam-transmission.patch @@ -0,0 +1,41 @@ +From 9ad1da14ab3bf23087ae45fe399d84a109ddb81a Mon Sep 17 00:00:00 2001 +From: Oleksij Rempel +Date: Tue, 28 May 2024 09:06:48 +0200 +Subject: net: can: j1939: recover socket queue on CAN bus error during BAM transmission +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Oleksij Rempel + +commit 9ad1da14ab3bf23087ae45fe399d84a109ddb81a upstream. + +Addresses an issue where a CAN bus error during a BAM transmission +could stall the socket queue, preventing further transmissions even +after the bus error is resolved. The fix activates the next queued +session after the error recovery, allowing communication to continue. + +Fixes: 9d71dd0c70099 ("can: add support of SAE J1939 protocol") +Cc: stable@vger.kernel.org +Reported-by: Alexander Hölzl +Tested-by: Alexander Hölzl +Signed-off-by: Oleksij Rempel +Link: https://lore.kernel.org/all/20240528070648.1947203-1-o.rempel@pengutronix.de +Cc: stable@vger.kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + net/can/j1939/transport.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/net/can/j1939/transport.c ++++ b/net/can/j1939/transport.c +@@ -1681,6 +1681,8 @@ static int j1939_xtp_rx_rts_session_acti + + j1939_session_timers_cancel(session); + j1939_session_cancel(session, J1939_XTP_ABORT_BUSY); ++ if (session->transmission) ++ j1939_session_deactivate_activate_next(session); + + return -EBUSY; + } diff --git a/queue-6.9/nvmet-fc-remove-__counted_by-from-nvmet_fc_tgt_queue.fod.patch b/queue-6.9/nvmet-fc-remove-__counted_by-from-nvmet_fc_tgt_queue.fod.patch new file mode 100644 index 00000000000..cc754764430 --- /dev/null +++ b/queue-6.9/nvmet-fc-remove-__counted_by-from-nvmet_fc_tgt_queue.fod.patch @@ -0,0 +1,65 @@ +From 440e2051c577896275c0e0513ec26964e04c7810 Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Wed, 29 May 2024 14:42:40 -0700 +Subject: nvmet-fc: Remove __counted_by from nvmet_fc_tgt_queue.fod[] + +From: Nathan Chancellor + +commit 440e2051c577896275c0e0513ec26964e04c7810 upstream. + +Work for __counted_by on generic pointers in structures (not just +flexible array members) has started landing in Clang 19 (current tip of +tree). During the development of this feature, a restriction was added +to __counted_by to prevent the flexible array member's element type from +including a flexible array member itself such as: + + struct foo { + int count; + char buf[]; + }; + + struct bar { + int count; + struct foo data[] __counted_by(count); + }; + +because the size of data cannot be calculated with the standard array +size formula: + + sizeof(struct foo) * count + +This restriction was downgraded to a warning but due to CONFIG_WERROR, +it can still break the build. The application of __counted_by on the fod +member of 'struct nvmet_fc_tgt_queue' triggers this restriction, +resulting in: + + drivers/nvme/target/fc.c:151:2: error: 'counted_by' should not be applied to an array with element of unknown size because 'struct nvmet_fc_fcp_iod' is a struct type with a flexible array member. This will be an error in a future compiler version [-Werror,-Wbounds-safety-counted-by-elt-type-unknown-size] + 151 | struct nvmet_fc_fcp_iod fod[] __counted_by(sqsize); + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 1 error generated. + +Remove this use of __counted_by to fix the warning/error. However, +rather than remove it altogether, leave it commented, as it may be +possible to support this in future compiler releases. + +Cc: stable@vger.kernel.org +Closes: https://github.com/ClangBuiltLinux/linux/issues/2027 +Fixes: ccd3129aca28 ("nvmet-fc: Annotate struct nvmet_fc_tgt_queue with __counted_by") +Signed-off-by: Nathan Chancellor +Signed-off-by: Keith Busch +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/target/fc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/nvme/target/fc.c ++++ b/drivers/nvme/target/fc.c +@@ -148,7 +148,7 @@ struct nvmet_fc_tgt_queue { + struct workqueue_struct *work_q; + struct kref ref; + /* array of fcp_iods */ +- struct nvmet_fc_fcp_iod fod[] __counted_by(sqsize); ++ struct nvmet_fc_fcp_iod fod[] /* __counted_by(sqsize) */; + } __aligned(sizeof(unsigned long long)); + + struct nvmet_fc_hostport { diff --git a/queue-6.9/pci-msi-fix-uaf-in-msi_capability_init.patch b/queue-6.9/pci-msi-fix-uaf-in-msi_capability_init.patch new file mode 100644 index 00000000000..f8a2c278ca1 --- /dev/null +++ b/queue-6.9/pci-msi-fix-uaf-in-msi_capability_init.patch @@ -0,0 +1,112 @@ +From 9eee5330656bf92f51cb1f09b2dc9f8cf975b3d1 Mon Sep 17 00:00:00 2001 +From: Mostafa Saleh +Date: Mon, 24 Jun 2024 20:37:28 +0000 +Subject: PCI/MSI: Fix UAF in msi_capability_init + +From: Mostafa Saleh + +commit 9eee5330656bf92f51cb1f09b2dc9f8cf975b3d1 upstream. + +KFENCE reports the following UAF: + + BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488 + + Use-after-free read at 0x0000000024629571 (in kfence-#12): + __pci_enable_msi_range+0x2c0/0x488 + pci_alloc_irq_vectors_affinity+0xec/0x14c + pci_alloc_irq_vectors+0x18/0x28 + + kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128 + + allocated by task 81 on cpu 7 at 10.808142s: + __kmem_cache_alloc_node+0x1f0/0x2bc + kmalloc_trace+0x44/0x138 + msi_alloc_desc+0x3c/0x9c + msi_domain_insert_msi_desc+0x30/0x78 + msi_setup_msi_desc+0x13c/0x184 + __pci_enable_msi_range+0x258/0x488 + pci_alloc_irq_vectors_affinity+0xec/0x14c + pci_alloc_irq_vectors+0x18/0x28 + + freed by task 81 on cpu 7 at 10.811436s: + msi_domain_free_descs+0xd4/0x10c + msi_domain_free_locked.part.0+0xc0/0x1d8 + msi_domain_alloc_irqs_all_locked+0xb4/0xbc + pci_msi_setup_msi_irqs+0x30/0x4c + __pci_enable_msi_range+0x2a8/0x488 + pci_alloc_irq_vectors_affinity+0xec/0x14c + pci_alloc_irq_vectors+0x18/0x28 + +Descriptor allocation done in: +__pci_enable_msi_range + msi_capability_init + msi_setup_msi_desc + msi_insert_msi_desc + msi_domain_insert_msi_desc + msi_alloc_desc + ... + +Freed in case of failure in __msi_domain_alloc_locked() +__pci_enable_msi_range + msi_capability_init + pci_msi_setup_msi_irqs + msi_domain_alloc_irqs_all_locked + msi_domain_alloc_locked + __msi_domain_alloc_locked => fails + msi_domain_free_locked + ... + +That failure propagates back to pci_msi_setup_msi_irqs() in +msi_capability_init() which accesses the descriptor for unmasking in the +error exit path. + +Cure it by copying the descriptor and using the copy for the error exit path +unmask operation. + +[ tglx: Massaged change log ] + +Fixes: bf6e054e0e3f ("genirq/msi: Provide msi_device_populate/destroy_sysfs()") +Suggested-by: Thomas Gleixner +Signed-off-by: Mostafa Saleh +Signed-off-by: Thomas Gleixner +Cc: Bjorn Heelgas +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20240624203729.1094506-1-smostafa@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/msi/msi.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +--- a/drivers/pci/msi/msi.c ++++ b/drivers/pci/msi/msi.c +@@ -349,7 +349,7 @@ static int msi_capability_init(struct pc + struct irq_affinity *affd) + { + struct irq_affinity_desc *masks = NULL; +- struct msi_desc *entry; ++ struct msi_desc *entry, desc; + int ret; + + /* Reject multi-MSI early on irq domain enabled architectures */ +@@ -374,6 +374,12 @@ static int msi_capability_init(struct pc + /* All MSIs are unmasked by default; mask them all */ + entry = msi_first_desc(&dev->dev, MSI_DESC_ALL); + pci_msi_mask(entry, msi_multi_mask(entry)); ++ /* ++ * Copy the MSI descriptor for the error path because ++ * pci_msi_setup_msi_irqs() will free it for the hierarchical ++ * interrupt domain case. ++ */ ++ memcpy(&desc, entry, sizeof(desc)); + + /* Configure MSI capability structure */ + ret = pci_msi_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSI); +@@ -393,7 +399,7 @@ static int msi_capability_init(struct pc + goto unlock; + + err: +- pci_msi_unmask(entry, msi_multi_mask(entry)); ++ pci_msi_unmask(&desc, msi_multi_mask(&desc)); + pci_free_msi_irqs(dev); + fail: + dev->msi_enabled = 0; diff --git a/queue-6.9/series b/queue-6.9/series index d0a25ef86fb..d8744c2277e 100644 --- a/queue-6.9/series +++ b/queue-6.9/series @@ -159,3 +159,29 @@ serial-8250_omap-implementation-of-errata-i2310.patch serial-imx-set-receiver-level-before-starting-uart.patch serial-core-introduce-uart_port_tx_limited_flags.patch serial-bcm63xx-uart-fix-tx-after-conversion-to-uart_port_tx_limited.patch +alsa-hda-realtek-fix-mute-micmute-leds-don-t-work-for-elitebook-645-665-g11.patch +tty-mxser-remove-__counted_by-from-mxser_board.ports.patch +tty-mcf-mcf54418-has-10-uarts.patch +net-can-j1939-initialize-unused-data-in-j1939_send_one.patch +net-can-j1939-recover-socket-queue-on-can-bus-error-during-bam-transmission.patch +net-can-j1939-enhanced-error-handling-for-tightly-received-rts-messages-in-xtp_rx_rts_session_new.patch +pci-msi-fix-uaf-in-msi_capability_init.patch +nvmet-fc-remove-__counted_by-from-nvmet_fc_tgt_queue.fod.patch +cpufreq-intel_pstate-use-hwp-to-initialize-itmt-if-cppc-is-missing.patch +irqchip-loongson-eiointc-use-early_cpu_to_node-instead-of-cpu_to_node.patch +cpu-fix-broken-cmdline-nosmp-and-maxcpus-0.patch +cpu-hotplug-fix-dynstate-assignment-in-__cpuhp_setup_state_cpuslocked.patch +irqchip-loongson-liointc-set-different-isrs-for-different-cores.patch +kbuild-install-dtb-files-as-0644-in-makefile.dtbinst.patch +sh-rework-sync_file_range-abi.patch +btrfs-zoned-fix-initial-free-space-detection.patch +csky-hexagon-fix-broken-sys_sync_file_range.patch +hexagon-fix-fadvise64_64-calling-conventions.patch +drm-drm_file-fix-pid-refcounting-race.patch +drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_ld_modes.patch +drm-fbdev-dma-only-set-smem_start-is-enable-per-module-option.patch +drm-amdgpu-avoid-using-null-object-of-framebuffer.patch +drm-i915-gt-fix-potential-uaf-by-revoke-of-fence-registers.patch +drm-nouveau-dispnv04-fix-null-pointer-dereference-in-nv17_tv_get_hd_modes.patch +drm-amd-display-send-dp_total_lttpr_cnt-during-detection-if-lttpr-is-present.patch +drm-amdgpu-atomfirmware-fix-parsing-of-vram_info.patch diff --git a/queue-6.9/sh-rework-sync_file_range-abi.patch b/queue-6.9/sh-rework-sync_file_range-abi.patch new file mode 100644 index 00000000000..9cfdd48bde0 --- /dev/null +++ b/queue-6.9/sh-rework-sync_file_range-abi.patch @@ -0,0 +1,72 @@ +From 30766f1105d6d2459c3b9fe34a3e52b637a72950 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Tue, 11 Jun 2024 22:12:43 +0200 +Subject: sh: rework sync_file_range ABI + +From: Arnd Bergmann + +commit 30766f1105d6d2459c3b9fe34a3e52b637a72950 upstream. + +The unusual function calling conventions on SuperH ended up causing +sync_file_range to have the wrong argument order, with the 'flags' +argument getting sorted before 'nbytes' by the compiler. + +In userspace, I found that musl, glibc, uclibc and strace all expect the +normal calling conventions with 'nbytes' last, so changing the kernel +to match them should make all of those work. + +In order to be able to also fix libc implementations to work with existing +kernels, they need to be able to tell which ABI is used. An easy way +to do this is to add yet another system call using the sync_file_range2 +ABI that works the same on all architectures. + +Old user binaries can now work on new kernels, and new binaries can +try the new sync_file_range2() to work with new kernels or fall back +to the old sync_file_range() version if that doesn't exist. + +Cc: stable@vger.kernel.org +Fixes: 75c92acdd5b1 ("sh: Wire up new syscalls.") +Acked-by: John Paul Adrian Glaubitz +Signed-off-by: Arnd Bergmann +Signed-off-by: Greg Kroah-Hartman +--- + arch/sh/kernel/sys_sh32.c | 11 +++++++++++ + arch/sh/kernel/syscalls/syscall.tbl | 3 ++- + 2 files changed, 13 insertions(+), 1 deletion(-) + +--- a/arch/sh/kernel/sys_sh32.c ++++ b/arch/sh/kernel/sys_sh32.c +@@ -59,3 +59,14 @@ asmlinkage int sys_fadvise64_64_wrapper( + (u64)len0 << 32 | len1, advice); + #endif + } ++ ++/* ++ * swap the arguments the way that libc wants them instead of ++ * moving flags ahead of the 64-bit nbytes argument ++ */ ++SYSCALL_DEFINE6(sh_sync_file_range6, int, fd, SC_ARG64(offset), ++ SC_ARG64(nbytes), unsigned int, flags) ++{ ++ return ksys_sync_file_range(fd, SC_VAL64(loff_t, offset), ++ SC_VAL64(loff_t, nbytes), flags); ++} +--- a/arch/sh/kernel/syscalls/syscall.tbl ++++ b/arch/sh/kernel/syscalls/syscall.tbl +@@ -321,7 +321,7 @@ + 311 common set_robust_list sys_set_robust_list + 312 common get_robust_list sys_get_robust_list + 313 common splice sys_splice +-314 common sync_file_range sys_sync_file_range ++314 common sync_file_range sys_sh_sync_file_range6 + 315 common tee sys_tee + 316 common vmsplice sys_vmsplice + 317 common move_pages sys_move_pages +@@ -395,6 +395,7 @@ + 385 common pkey_alloc sys_pkey_alloc + 386 common pkey_free sys_pkey_free + 387 common rseq sys_rseq ++388 common sync_file_range2 sys_sync_file_range2 + # room for arch specific syscalls + 393 common semget sys_semget + 394 common semctl sys_semctl diff --git a/queue-6.9/tty-mcf-mcf54418-has-10-uarts.patch b/queue-6.9/tty-mcf-mcf54418-has-10-uarts.patch new file mode 100644 index 00000000000..dbe211d0cbc --- /dev/null +++ b/queue-6.9/tty-mcf-mcf54418-has-10-uarts.patch @@ -0,0 +1,32 @@ +From 7c92a8bd53f24d50c8cf4aba53bb75505b382fed Mon Sep 17 00:00:00 2001 +From: Jean-Michel Hautbois +Date: Thu, 20 Jun 2024 18:29:59 +0200 +Subject: tty: mcf: MCF54418 has 10 UARTS + +From: Jean-Michel Hautbois + +commit 7c92a8bd53f24d50c8cf4aba53bb75505b382fed upstream. + +Most of the colfires have up to 5 UARTs but MCF54418 has up-to 10 ! +Change the maximum value authorized. + +Signed-off-by: Jean-Michel Hautbois +Cc: stable +Fixes: 2545cf6e94b4 ("m68knommu: allow 4 coldfire serial ports") +Link: https://lore.kernel.org/r/20240620-upstream-uart-v1-1-a9d0d95fb19e@yoseli.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/mcf.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/tty/serial/mcf.c ++++ b/drivers/tty/serial/mcf.c +@@ -462,7 +462,7 @@ static const struct uart_ops mcf_uart_op + .verify_port = mcf_verify_port, + }; + +-static struct mcf_uart mcf_ports[4]; ++static struct mcf_uart mcf_ports[10]; + + #define MCF_MAXPORTS ARRAY_SIZE(mcf_ports) + diff --git a/queue-6.9/tty-mxser-remove-__counted_by-from-mxser_board.ports.patch b/queue-6.9/tty-mxser-remove-__counted_by-from-mxser_board.ports.patch new file mode 100644 index 00000000000..ee82b533fde --- /dev/null +++ b/queue-6.9/tty-mxser-remove-__counted_by-from-mxser_board.ports.patch @@ -0,0 +1,66 @@ +From 1c07c9be87dd3dd0634033bf08728b32465f08fb Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Wed, 29 May 2024 14:29:42 -0700 +Subject: tty: mxser: Remove __counted_by from mxser_board.ports[] + +From: Nathan Chancellor + +commit 1c07c9be87dd3dd0634033bf08728b32465f08fb upstream. + +Work for __counted_by on generic pointers in structures (not just +flexible array members) has started landing in Clang 19 (current tip of +tree). During the development of this feature, a restriction was added +to __counted_by to prevent the flexible array member's element type from +including a flexible array member itself such as: + + struct foo { + int count; + char buf[]; + }; + + struct bar { + int count; + struct foo data[] __counted_by(count); + }; + +because the size of data cannot be calculated with the standard array +size formula: + + sizeof(struct foo) * count + +This restriction was downgraded to a warning but due to CONFIG_WERROR, +it can still break the build. The application of __counted_by on the +ports member of 'struct mxser_board' triggers this restriction, +resulting in: + + drivers/tty/mxser.c:291:2: error: 'counted_by' should not be applied to an array with element of unknown size because 'struct mxser_port' is a struct type with a flexible array member. This will be an error in a future compiler version [-Werror,-Wbounds-safety-counted-by-elt-type-unknown-size] + 291 | struct mxser_port ports[] __counted_by(nports); + | ^~~~~~~~~~~~~~~~~~~~~~~~~ + 1 error generated. + +Remove this use of __counted_by to fix the warning/error. However, +rather than remove it altogether, leave it commented, as it may be +possible to support this in future compiler releases. + +Cc: +Closes: https://github.com/ClangBuiltLinux/linux/issues/2026 +Fixes: f34907ecca71 ("mxser: Annotate struct mxser_board with __counted_by") +Signed-off-by: Nathan Chancellor +Link: https://lore.kernel.org/r/20240529-drop-counted-by-ports-mxser-board-v1-1-0ab217f4da6d@kernel.org +Signed-off-by: Kees Cook +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/mxser.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/tty/mxser.c ++++ b/drivers/tty/mxser.c +@@ -288,7 +288,7 @@ struct mxser_board { + enum mxser_must_hwid must_hwid; + speed_t max_baud; + +- struct mxser_port ports[] __counted_by(nports); ++ struct mxser_port ports[] /* __counted_by(nports) */; + }; + + static DECLARE_BITMAP(mxser_boards, MXSER_BOARDS);