January 2025 - Linux-stable-mirror

[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

8 months, 1 week

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);

8 months, 1 week

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

8 months, 1 week

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.

8 months, 1 week

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

8 months, 1 week

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

8 months, 1 week

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

8 months, 1 week

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

8 months, 1 week

2
1
0 0

[PATCH] ACPI: resource: Add Asus Vivobook X1504VAP to irq1_level_low_skip_override[]

by Hans de Goede

Like the Vivobook X1704VAP the X1504VAP has its keyboard IRQ (1) described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh which breaks the keyboard. Add the X1504VAP to the irq1_level_low_skip_override[] quirk table to fix this. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219224 Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/acpi/resource.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 821867de43be..ab4c0e0b6b8e 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -440,6 +440,13 @@ static const struct dmi_system_id irq1_level_low_skip_override[] = { DMI_MATCH(DMI_BOARD_NAME, "S5602ZA"), }, }, + { + /* Asus Vivobook X1504VAP */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), + DMI_MATCH(DMI_BOARD_NAME, "X1504VAP"), + }, + }, { /* Asus Vivobook X1704VAP */ .matches = { -- 2.47.1

8 months, 1 week

2
1
0 0

[PATCH 6.1.y] sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers

by Alva Lan

From: Qun-Wei Lin <qun-wei.lin(a)mediatek.com> [ Upstream commit fd7b4f9f46d46acbc7af3a439bb0d869efdc5c58 ] When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ Link: https://lkml.kernel.org/r/20241113042544.19095-1-qun-wei.lin@mediatek.com Signed-off-by: Qun-Wei Lin <qun-wei.lin(a)mediatek.com> Cc: Andrew Yang <andrew.yang(a)mediatek.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Cc: Casper Li <casper.li(a)mediatek.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Chinwen Chang <chinwen.chang(a)mediatek.com> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Alva Lan <alvalan9(a)foxmail.com> --- include/linux/sched/task_stack.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/sched/task_stack.h b/include/linux/sched/task_stack.h index f158b025c175..d2117e1c8fa5 100644 --- a/include/linux/sched/task_stack.h +++ b/include/linux/sched/task_stack.h @@ -8,6 +8,7 @@ #include <linux/sched.h> #include <linux/magic.h> +#include <linux/kasan.h> #ifdef CONFIG_THREAD_INFO_IN_TASK @@ -88,6 +89,7 @@ static inline int object_is_on_stack(const void *obj) { void *stack = task_stack_page(current); + obj = kasan_reset_tag(obj); return (obj >= stack) && (obj < (stack + THREAD_SIZE)); } -- 2.39.4

8 months, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2025