- Linux-stable-mirror - lists.linaro.org

[PATCH] usb: dwc3: Skip resume if pm_runtime_set_active() fails

by Ray Chi

When the system begins to enter suspend mode, dwc3_suspend() is called by PM suspend. There is a problem that if someone interrupt the system suspend process between dwc3_suspend() and pm_suspend() of its parent device, PM suspend will be canceled and attempt to resume suspended devices so that dwc3_resume() will be called. However, dwc3 and its parent device (like the power domain or glue driver) may already be suspended by runtime PM in fact. If this sutiation happened, the pm_runtime_set_active() in dwc3_resume() will return an error since parent device was suspended. This can lead to unexpected behavior if DWC3 proceeds to execute dwc3_resume_common(). EX. RPM suspend: ... -> dwc3_runtime_suspend() -> rpm_suspend() of parent device ... PM suspend: ... -> dwc3_suspend() -> pm_suspend of parent device ^ interrupt, so resume suspended device ... <- dwc3_resume() <-/ ^ pm_runtime_set_active() returns error To prevent the problem, this commit will skip dwc3_resume_common() and return the error if pm_runtime_set_active() fails. Fixes: 68c26fe58182 ("usb: dwc3: set pm runtime active before resume common") Cc: stable(a)vger.kernel.org Signed-off-by: Ray Chi <raychi(a)google.com> --- drivers/usb/dwc3/core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index c22b8678e02e..7578c5133568 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -2609,12 +2609,15 @@ static int dwc3_resume(struct device *dev) pinctrl_pm_select_default_state(dev); pm_runtime_disable(dev); - pm_runtime_set_active(dev); + ret = pm_runtime_set_active(dev); + if (ret) + goto out; ret = dwc3_resume_common(dwc, PMSG_RESUME); if (ret) pm_runtime_set_suspended(dev); +out: pm_runtime_enable(dev); return ret; -- 2.47.1.613.gc27f4b7a9f-goog

3 weeks, 3 days

2
2
0 0

[tip: x86/urgent] x86/fpu: Ensure shadow stack is active before "getting" registers

by tip-bot2 for Rick Edgecombe

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: a9d9c33132d49329ada647e4514d210d15e31d81 Gitweb: https://git.kernel.org/tip/a9d9c33132d49329ada647e4514d210d15e31d81 Author: Rick Edgecombe <rick.p.edgecombe(a)intel.com> AuthorDate: Tue, 07 Jan 2025 15:30:56 -08:00 Committer: Dave Hansen <dave.hansen(a)linux.intel.com> CommitterDate: Tue, 07 Jan 2025 15:55:51 -08:00 x86/fpu: Ensure shadow stack is active before "getting" registers The x86 shadow stack support has its own set of registers. Those registers are XSAVE-managed, but they are "supervisor state components" which means that userspace can not touch them with XSAVE/XRSTOR. It also means that they are not accessible from the existing ptrace ABI for XSAVE state. Thus, there is a new ptrace get/set interface for it. The regset code that ptrace uses provides an ->active() handler in addition to the get/set ones. For shadow stack this ->active() handler verifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the thread struct. The ->active() handler is checked from some call sites of the regset get/set handlers, but not the ptrace ones. This was not understood when shadow stack support was put in place. As a result, both the set/get handlers can be called with XFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to return NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an ssp_active() check to avoid surprising the kernel with shadow stack behavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). That check just happened to avoid the warning. But the ->get() side wasn't so lucky. It can be called with shadow stacks disabled, triggering the warning in practice, as reported by Christina Schimpe: WARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0 [...] Call Trace: <TASK> ? show_regs+0x6e/0x80 ? ssp_get+0x89/0xa0 ? __warn+0x91/0x150 ? ssp_get+0x89/0xa0 ? report_bug+0x19d/0x1b0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x1d/0x80 ? asm_exc_invalid_op+0x1f/0x30 ? __pfx_ssp_get+0x10/0x10 ? ssp_get+0x89/0xa0 ? ssp_get+0x52/0xa0 __regset_get+0xad/0xf0 copy_regset_to_user+0x52/0xc0 ptrace_regset+0x119/0x140 ptrace_request+0x13c/0x850 ? wait_task_inactive+0x142/0x1d0 ? do_syscall_64+0x6d/0x90 arch_ptrace+0x102/0x300 [...] Ensure that shadow stacks are active in a thread before looking them up in the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are set at the same time, the active check ensures that there will be something to find in the XSAVE buffer. [ dhansen: changelog/subject tweaks ] Fixes: 2fab02b25ae7 ("x86: Add PTRACE interface for shadow stack") Reported-by: Christina Schimpe <christina.schimpe(a)intel.com> Signed-off-by: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Tested-by: Christina Schimpe <christina.schimpe(a)intel.com> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250107233056.235536-1-rick.p.edgecombe%40inte… --- arch/x86/kernel/fpu/regset.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/fpu/regset.c b/arch/x86/kernel/fpu/regset.c index 6bc1eb2..887b0b8 100644 --- a/arch/x86/kernel/fpu/regset.c +++ b/arch/x86/kernel/fpu/regset.c @@ -190,7 +190,8 @@ int ssp_get(struct task_struct *target, const struct user_regset *regset, struct fpu *fpu = &target->thread.fpu; struct cet_user_state *cetregs; - if (!cpu_feature_enabled(X86_FEATURE_USER_SHSTK)) + if (!cpu_feature_enabled(X86_FEATURE_USER_SHSTK) || + !ssp_active(target, regset)) return -ENODEV; sync_fpstate(fpu);

3 weeks, 3 days

1
0
0 0

[PATCH v2] x86: Check if shadow stack is active for ssp_get()

by Rick Edgecombe

The x86 shadow stack support has its own set of registers. Those registers are XSAVE-managed, but they are "supervisor state components" which means that userspace can't touch them with XSAVE/XRSTOR. It also means that they are not accessible from the existing ptrace ABI like the FPU register or GPRs. Thus, there is a new ptrace get/set interface for it. The regset code that ptrace uses provides an ->active() handler in addition to the get/set ones. For shadow stack this ->active() handler verifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the thread struct. The ->active() handler is checked from some callsites of the regset get/set handlers, but not the ptrace ones. This was not understood when shadow stack support was put in place. As a result, both the set/get handlers can be called with XFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to return NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an ssp_active() check to avoid surprising the kernel with shadow stack behavior when the kernel is not read for it (ARCH_SHSTK_SHSTK==0). That check just happened to avoid the warning. But the ->get() side wasn't so lucky. It can be called with shadow stacks disabled, triggering the warning in practice, as reported by Christina Schimpe: WARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0 [...] Call Trace: <TASK> ? show_regs+0x6e/0x80 ? ssp_get+0x89/0xa0 ? __warn+0x91/0x150 ? ssp_get+0x89/0xa0 ? report_bug+0x19d/0x1b0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x1d/0x80 ? asm_exc_invalid_op+0x1f/0x30 ? __pfx_ssp_get+0x10/0x10 ? ssp_get+0x89/0xa0 ? ssp_get+0x52/0xa0 __regset_get+0xad/0xf0 copy_regset_to_user+0x52/0xc0 ptrace_regset+0x119/0x140 ptrace_request+0x13c/0x850 ? wait_task_inactive+0x142/0x1d0 ? do_syscall_64+0x6d/0x90 arch_ptrace+0x102/0x300 [...] Ensure that shadow stacks are active in a thread before looking them up in the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are set at the same time, the active check ensures that there will be something to find in the XSAVE buffer. Fixes: 2fab02b25ae7 ("x86: Add PTRACE interface for shadow stack") Reported-by: Christina Schimpe <christina.schimpe(a)intel.com> Tested-by: Christina Schimpe <christina.schimpe(a)intel.com> Signed-off-by: Rick Edgecombe <rick.p.edgecombe(a)intel.com> Cc: stable(a)vger.kernel.org --- v2: - Incorporate log feedback from Dave here: https://lore.kernel.org/lkml/81d3af8f-bad8-4559-8a0f-3271dd7f0abc@intel.com/ arch/x86/kernel/fpu/regset.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/fpu/regset.c b/arch/x86/kernel/fpu/regset.c index 6bc1eb2a21bd..887b0b8e21e3 100644 --- a/arch/x86/kernel/fpu/regset.c +++ b/arch/x86/kernel/fpu/regset.c @@ -190,7 +190,8 @@ int ssp_get(struct task_struct *target, const struct user_regset *regset, struct fpu *fpu = &target->thread.fpu; struct cet_user_state *cetregs; - if (!cpu_feature_enabled(X86_FEATURE_USER_SHSTK)) + if (!cpu_feature_enabled(X86_FEATURE_USER_SHSTK) || + !ssp_active(target, regset)) return -ENODEV; sync_fpstate(fpu); -- 2.47.1

3 weeks, 3 days

1
0
0 0

Re: zram: Regression in at least linux-6.1.y tree

by Kenneth Van Alstyne

Somehow I missed this on my first search through lore.kernel.org, but this appears to be the same issue: https://lore.kernel.org/stable/Z3ytcILx4S1v_ueJ@codewreck.org/T/#u Thanks, -- Kenneth Van Alstyne, Jr. > On Jan 7, 2025, at 15:48, Kenneth Van Alstyne <kvanals(a)kvanals.org> wrote: > > Greetings and apologies if this isn't the proper process for reporting an issue in a LTS kernel per https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html. Happy to follow another process if more appropriate. > > Kernel 6.1.122 introduced a regression via commit ac3b5366b9b7c9d97b606532ceab43d2329a22f3 (backport of upstream commit 74363ec674cb172d8856de25776c8f3103f05e2f) in drivers/block/zram/zram_drv.c where attempting to set the size of /dev/zram0 after loading the zram kernel module results in a kernel NULL pointer dereference. > > That patch removed the following block from zram_reset_device(): > - if (!init_done(zram)) { > - up_write(&zram->init_lock); > - return; > - } > > However, without that, zram_reset_device subsequently calls zcomp_destroy on a device that has not been initialized, leading to the OOPS. Adding that block back does resolve the issue. In addition, the latest mainline kernel does not appear to exhibit these symptoms, but zram_drv.c seems to have been changed fairly substantially since kernel 6.1. > > Steps to reproduce: > > modprobe zram > zramctl /dev/zram0 --algorithm zstd --size 83886080k > > Kernel log: > > [ 184.410082] BUG: kernel NULL pointer dereference, address: 0000000000000000 > [ 184.416305] #PF: supervisor read access in kernel mode > [ 184.418201] #PF: error_code(0x0000) - not-present page > [ 184.418201] PGD 170d0b067 P4D 170d0b067 PUD 1718af067 PMD 0 > [ 184.418201] Oops: 0000 [#1] PREEMPT SMP NOPTI > [ 184.418201] CPU: 2 PID: 3584 Comm: zramctl Tainted: G O K 6.1.122 #1 > [ 184.418201] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014 > [ 184.418201] RIP: 0010:zcomp_cpu_dead+0x7/0x30 [zram] > [ 184.418201] Code: c7 d8 56 a9 c0 e8 63 f3 92 ed b8 f4 ff ff ff 5b e9 fe 10 d7 ed 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 89 ff <48> 8b 46 f0 48 03 04 fd c0 47 e7 ae 48 89 c7 48 8d 70 08 e8 11 fd > [ 184.418201] RSP: 0018:ffffaf9400a5fd28 EFLAGS: 00010246 > [ 184.418201] RAX: ffffffffc0a912d0 RBX: ffff89adefa1b2e0 RCX: 0000000000000010 > [ 184.418201] RDX: 0000000000000000 RSI: 0000000000000010 RDI: 0000000000000000 > [ 184.418201] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 > [ 184.418201] R10: 000000000000000a R11: f000000000000000 R12: 0000000000000aa0 > [ 184.418201] R13: 0000000000000000 R14: 0000000000000010 R15: ffff89aac0cb2e20 > [ 184.418201] FS: 00007fa6d240d740(0000) GS:ffff89adefa80000(0000) knlGS:0000000000000000 > [ 184.418201] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 184.418201] CR2: 0000000000000000 CR3: 0000000171fd4000 CR4: 00000000003506e0 > [ 184.418201] Call Trace: > [ 184.418201] <TASK> > [ 184.418201] ? __die_body+0x1a/0x60 > [ 184.418201] ? page_fault_oops+0xae/0x260 > [ 184.418201] ? exc_page_fault+0x67/0x140 > [ 184.418201] ? asm_exc_page_fault+0x22/0x30 > [ 184.418201] ? zcomp_cpu_up_prepare+0x90/0x90 [zram] > [ 184.418201] ? zcomp_cpu_dead+0x7/0x30 [zram] > [ 184.418201] ? zcomp_cpu_up_prepare+0x90/0x90 [zram] > [ 184.418201] cpuhp_invoke_callback+0xb4/0x4c0 > [ 184.418201] ? zcomp_cpu_up_prepare+0x90/0x90 [zram] > [ 184.418201] cpuhp_issue_call+0xeb/0x140 > [ 184.418201] __cpuhp_state_remove_instance+0xdb/0x1a0 > [ 184.418201] zcomp_destroy+0x1c/0x30 [zram] > [ 184.418201] zram_reset_device+0xf3/0x120 [zram] > [ 184.418201] reset_store+0x9d/0x100 [zram] > [ 184.418201] kernfs_fop_write_iter+0x11e/0x1b0 > [ 184.418201] vfs_write+0x2ae/0x3c0 > [ 184.418201] ksys_write+0x5c/0xe0 > [ 184.418201] do_syscall_64+0x32/0x80 > [ 184.552119] python3 (3612) used greatest stack depth: 11736 bytes left > [ 184.418201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 > [ 184.418201] RIP: 0033:0x7fa6d2506d00 > [ 184.418201] Code: 40 00 48 8b 15 29 91 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb af 0f 1f 00 80 3d e1 18 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55 > [ 184.418201] RSP: 002b:00007ffec8315ec8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 > [ 184.418201] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fa6d2506d00 > [ 184.418201] RDX: 0000000000000001 RSI: 00007ffec8315ee0 RDI: 0000000000000003 > [ 184.418201] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000001 > [ 184.418201] R10: 0000000000000004 R11: 0000000000000202 R12: 00007fa6d240d6c0 > [ 184.418201] R13: 00007ffec8315ee0 R14: 0000000000000003 R15: 00007ffec8315ed0 > [ 184.418201] </TASK> > [ 184.418201] Modules linked in: zram zsmalloc bcache crc64 ip6table_filter ip6_tables iptable_filter xt_conntrack iptable_mangle xt_connmark nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_tables x_tables vfat fat btrfs blake2b_generic xor raid6_pq libcrc32c dm_multipath dm_mod bridge stp llc bonding nfs lockd grace sunrpc fscache torch(O) ipmi_devintf ipmi_msghandler sr_mod kvm_amd mousedev cdrom virtio_blk kvm ata_generic pata_acpi irqbypass crc32c_intel aesni_intel ata_piix crypto_simd virtio_pci virtio_pci_legacy_dev psmouse virtio_pci_modern_dev i6300esb e1000 libata cryptd i2c_piix4 evdev procmemro(OK) noptrace(OK) > [ 184.418201] CR2: 0000000000000000 > [ 184.418201] ---[ end trace 0000000000000000 ]--- > [ 184.418201] RIP: 0010:zcomp_cpu_dead+0x7/0x30 [zram] > [ 184.418201] Code: c7 d8 56 a9 c0 e8 63 f3 92 ed b8 f4 ff ff ff 5b e9 fe 10 d7 ed 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 89 ff <48> 8b 46 f0 48 03 04 fd c0 47 e7 ae 48 89 c7 48 8d 70 08 e8 11 fd > [ 184.418201] RSP: 0018:ffffaf9400a5fd28 EFLAGS: 00010246 > [ 184.418201] RAX: ffffffffc0a912d0 RBX: ffff89adefa1b2e0 RCX: 0000000000000010 > [ 184.418201] RDX: 0000000000000000 RSI: 0000000000000010 RDI: 0000000000000000 > [ 184.418201] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 > [ 184.418201] R10: 000000000000000a R11: f000000000000000 R12: 0000000000000aa0 > [ 184.418201] R13: 0000000000000000 R14: 0000000000000010 R15: ffff89aac0cb2e20 > [ 184.418201] FS: 00007fa6d240d740(0000) GS:ffff89adefa80000(0000) knlGS:0000000000000000 > [ 184.418201] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 184.418201] CR2: 0000000000000000 CR3: 0000000171fd4000 CR4: 00000000003506e0 > [ 184.418201] Kernel panic - not syncing: Fatal exception > [ 184.418201] Kernel Offset: 0x2c800000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) > [ 184.418201] Rebooting in 120 seconds.. > > Thanks, > > -- > Kenneth Van Alstyne, Jr.

3 weeks, 4 days

1
0
0 0

[PATCH v4 4/5] arm64: cputype: Add MIDR_CORTEX_A76AE

by Douglas Anderson

From the TRM, MIDR_CORTEX_A76AE has a partnum of 0xDOE and an implementor of 0x41 (ARM). Add the values. Cc: stable(a)vger.kernel.org # dependency of the next fix in the series Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- (no changes since v3) Changes in v3: - New arch/arm64/include/asm/cputype.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index 488f8e751349..a345628fce51 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -75,6 +75,7 @@ #define ARM_CPU_PART_CORTEX_A76 0xD0B #define ARM_CPU_PART_NEOVERSE_N1 0xD0C #define ARM_CPU_PART_CORTEX_A77 0xD0D +#define ARM_CPU_PART_CORTEX_A76AE 0xD0E #define ARM_CPU_PART_NEOVERSE_V1 0xD40 #define ARM_CPU_PART_CORTEX_A78 0xD41 #define ARM_CPU_PART_CORTEX_A78AE 0xD42 @@ -158,6 +159,7 @@ #define MIDR_CORTEX_A76 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A76) #define MIDR_NEOVERSE_N1 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N1) #define MIDR_CORTEX_A77 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A77) +#define MIDR_CORTEX_A76AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A76AE) #define MIDR_NEOVERSE_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_V1) #define MIDR_CORTEX_A78 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78) #define MIDR_CORTEX_A78AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78AE) -- 2.47.1.613.gc27f4b7a9f-goog

3 weeks, 4 days

1
0
0 0

[PATCH v4 3/5] arm64: errata: Add KRYO 2XX/3XX/4XX silver cores to Spectre BHB safe list

by Douglas Anderson

Qualcomm has confirmed that, much like Cortex A53 and A55, KRYO 2XX/3XX/4XX silver cores are unaffected by Spectre BHB. Add them to the safe list. Fixes: 558c303c9734 ("arm64: Mitigate spectre style branch history side channels") Cc: stable(a)vger.kernel.org Cc: Scott Bauer <sbauer(a)quicinc.com> Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- Changes in v4: - Re-added KRYO 2XX/3XX/4XX silver patch after Qualcomm confirmed. Changes in v3: - Removed KRYO 2XX/3XX/4XX silver patch. Changes in v2: - New arch/arm64/kernel/proton-pack.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c index 17aa836fe46d..89405be53d8f 100644 --- a/arch/arm64/kernel/proton-pack.c +++ b/arch/arm64/kernel/proton-pack.c @@ -854,6 +854,9 @@ static bool is_spectre_bhb_safe(int scope) MIDR_ALL_VERSIONS(MIDR_CORTEX_A510), MIDR_ALL_VERSIONS(MIDR_CORTEX_A520), MIDR_ALL_VERSIONS(MIDR_BRAHMA_B53), + MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_2XX_SILVER), + MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_3XX_SILVER), + MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_SILVER), {}, }; static bool all_safe = true; -- 2.47.1.613.gc27f4b7a9f-goog

3 weeks, 4 days

1
0
0 0

[PATCH v4 1/5] arm64: errata: Add QCOM_KRYO_4XX_GOLD to the spectre_bhb_k24_list

by Douglas Anderson

Qualcomm Kryo 400-series Gold cores have a derivative of an ARM Cortex A76 in them. Since A76 needs Spectre mitigation via looping then the Kyro 400-series Gold cores also need Spectre mitigation via looping. Qualcomm has confirmed that the proper "k" value for Kryo 400-series Gold cores is 24. Fixes: 558c303c9734 ("arm64: Mitigate spectre style branch history side channels") Cc: stable(a)vger.kernel.org Cc: Scott Bauer <sbauer(a)quicinc.com> Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- Changes in v4: - Re-added QCOM_KRYO_4XX_GOLD k24 patch after Qualcomm confirmed. Changes in v3: - Removed QCOM_KRYO_4XX_GOLD k24 patch. Changes in v2: - Slight change to wording and notes of KRYO_4XX_GOLD patch arch/arm64/kernel/proton-pack.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c index da53722f95d4..e149efadff20 100644 --- a/arch/arm64/kernel/proton-pack.c +++ b/arch/arm64/kernel/proton-pack.c @@ -866,6 +866,7 @@ u8 spectre_bhb_loop_affected(int scope) MIDR_ALL_VERSIONS(MIDR_CORTEX_A76), MIDR_ALL_VERSIONS(MIDR_CORTEX_A77), MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1), + MIDR_ALL_VERSIONS(MIDR_QCOM_KRYO_4XX_GOLD), {}, }; static const struct midr_range spectre_bhb_k11_list[] = { -- 2.47.1.613.gc27f4b7a9f-goog

3 weeks, 4 days

1
0
0 0

[PATCH] nfs: Make NFS_FSCACHE select NETFS_SUPPORT instead of depending on it

by Dragan Simic

Having the NFS_FSCACHE option depend on the NETFS_SUPPORT options makes selecting NFS_FSCACHE impossible unless another option that additionally selects NETFS_SUPPORT is already selected. As a result, for example, being able to reach and select the NFS_FSCACHE option requires the CEPH_FS or CIFS option to be selected beforehand, which obviously doesn't make much sense. Let's correct this by making the NFS_FSCACHE option actually select the NETFS_SUPPORT option, instead of depending on it. Fixes: 915cd30cdea8 ("netfs, fscache: Combine fscache with netfs") Cc: stable(a)vger.kernel.org Reported-by: Diederik de Haas <didi.debian(a)cknow.org> Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> --- fs/nfs/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/nfs/Kconfig b/fs/nfs/Kconfig index 0eb20012792f..d3f76101ad4b 100644 --- a/fs/nfs/Kconfig +++ b/fs/nfs/Kconfig @@ -170,7 +170,8 @@ config ROOT_NFS config NFS_FSCACHE bool "Provide NFS client caching support" - depends on NFS_FS=m && NETFS_SUPPORT || NFS_FS=y && NETFS_SUPPORT=y + depends on NFS_FS + select NETFS_SUPPORT select FSCACHE help Say Y here if you want NFS data to be cached locally on disc through

3 weeks, 4 days

1
1
0 0

[PATCH] KEYS: trusted: dcp: fix improper sg use with CONFIG_VMAP_STACK=y

by David Gstir

With vmalloc stack addresses enabled (CONFIG_VMAP_STACK=y) DCP trusted keys can crash during en- and decryption of the blob encryption key via the DCP crypto driver. This is caused by improperly using sg_init_one() with vmalloc'd stack buffers (plain_key_blob). Fix this by always using kmalloc() for buffers we give to the DCP crypto driver. Cc: stable(a)vger.kernel.org # v6.10+ Fixes: 0e28bf61a5f9 ("KEYS: trusted: dcp: fix leak of blob encryption key") Signed-off-by: David Gstir <david(a)sigma-star.at> --- security/keys/trusted-keys/trusted_dcp.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/security/keys/trusted-keys/trusted_dcp.c b/security/keys/trusted-keys/trusted_dcp.c index e908c53a803c..7b6eb655df0c 100644 --- a/security/keys/trusted-keys/trusted_dcp.c +++ b/security/keys/trusted-keys/trusted_dcp.c @@ -201,12 +201,16 @@ static int trusted_dcp_seal(struct trusted_key_payload *p, char *datablob) { struct dcp_blob_fmt *b = (struct dcp_blob_fmt *)p->blob; int blen, ret; - u8 plain_blob_key[AES_KEYSIZE_128]; + u8 *plain_blob_key; blen = calc_blob_len(p->key_len); if (blen > MAX_BLOB_SIZE) return -E2BIG; + plain_blob_key = kmalloc(AES_KEYSIZE_128, GFP_KERNEL); + if (!plain_blob_key) + return -ENOMEM; + b->fmt_version = DCP_BLOB_VERSION; get_random_bytes(b->nonce, AES_KEYSIZE_128); get_random_bytes(plain_blob_key, AES_KEYSIZE_128); @@ -229,7 +233,8 @@ static int trusted_dcp_seal(struct trusted_key_payload *p, char *datablob) ret = 0; out: - memzero_explicit(plain_blob_key, sizeof(plain_blob_key)); + memzero_explicit(plain_blob_key, AES_KEYSIZE_128); + kfree(plain_blob_key); return ret; } @@ -238,7 +243,7 @@ static int trusted_dcp_unseal(struct trusted_key_payload *p, char *datablob) { struct dcp_blob_fmt *b = (struct dcp_blob_fmt *)p->blob; int blen, ret; - u8 plain_blob_key[AES_KEYSIZE_128]; + u8 *plain_blob_key = NULL; if (b->fmt_version != DCP_BLOB_VERSION) { pr_err("DCP blob has bad version: %i, expected %i\n", @@ -256,6 +261,12 @@ static int trusted_dcp_unseal(struct trusted_key_payload *p, char *datablob) goto out; } + plain_blob_key = kmalloc(AES_KEYSIZE_128, GFP_KERNEL); + if (!plain_blob_key) { + ret = -ENOMEM; + goto out; + } + ret = decrypt_blob_key(b->blob_key, plain_blob_key); if (ret) { pr_err("Unable to decrypt blob key: %i\n", ret); @@ -271,7 +282,10 @@ static int trusted_dcp_unseal(struct trusted_key_payload *p, char *datablob) ret = 0; out: - memzero_explicit(plain_blob_key, sizeof(plain_blob_key)); + if (plain_blob_key) { + memzero_explicit(plain_blob_key, AES_KEYSIZE_128); + kfree(plain_blob_key); + } return ret; } -- 2.47.0

3 weeks, 4 days

2
3
0 0

[PATCH] ACPI: resource: Add TongFang GM5HG0A to irq1_edge_low_force_override[]

by Hans de Goede

The TongFang GM5HG0A is a TongFang barebone design which is sold under various brand names. The ACPI IRQ override for the keyboard IRQ must be used on these AMD Zen laptops in order for the IRQ to work. At least on the SKIKK Vanaheim variant the DMI product- and board-name strings have been replaced by the OEM with "Vanaheim" so checking that board-name contains "GM5HG0A" as is usually done for TongFang barebones quirks does not work. The DMI OEM strings do contain "GM5HG0A". I have looked at the dmidecode for a few other TongFang devices and the TongFang code-name string being in the OEM strings seems to be something which is consistently true. Add a quirk checking one of the DMI_OEM_STRING(s) is "GM5HG0A" in the hope that this will work for other OEM versions of the "GM5HG0A" too. Link: https://www.skikk.eu/en/laptops/vanaheim-15-rtx-4060 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219614 Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/acpi/resource.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 7d6537ea176f..90aaec923889 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -653,6 +653,17 @@ static const struct dmi_system_id irq1_edge_low_force_override[] = { DMI_MATCH(DMI_BOARD_NAME, "GMxHGxx"), }, }, + { + /* + * TongFang GM5HG0A in case of the SKIKK Vanaheim relabel the + * board-name is changed, so check OEM strings instead. Note + * OEM string matches are always exact matches. + * https://bugzilla.kernel.org/show_bug.cgi?id=219614 + */ + .matches = { + DMI_EXACT_MATCH(DMI_OEM_STRING, "GM5HG0A"), + }, + }, { } }; -- 2.47.1

3 weeks, 4 days

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror