January 2024 - Linux-stable-mirror

[PATCH 6.7.y] Revert "drm/amd: Enable PCIe PME from D3"

by Jonathan Gray

This reverts commit 05f7a3475af0faa8bf77f8637c4a40349db4f78f. duplicated a change made in 6.7 6967741d26c87300a51b5e50d4acd104bc1a9759 Cc: stable(a)vger.kernel.org # 6.7 Signed-off-by: Jonathan Gray <jsg(a)jsg.id.au> --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index f4174eebe993..c0e8e030b96f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -2265,8 +2265,6 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, pci_wake_from_d3(pdev, TRUE); - pci_wake_from_d3(pdev, TRUE); - /* * For runpm implemented via BACO, PMFW will handle the * timing for BACO in and out: -- 2.43.0

1 year

2
1
0 0

[PATCH 4.19] x86/CPU/AMD: Fix disabling XSAVES on AMD family 0x17 due to erratum

by Maciej S. Szmigiero

From: "Maciej S. Szmigiero" <maciej.szmigiero(a)oracle.com> The stable kernel version backport of the patch disabling XSAVES on AMD Zen family 0x17 applied this change to the wrong function (init_amd_k6()), one which isn't called for Zen CPUs. Move the erratum to the init_amd_zn() function instead. Add an explicit family 0x17 check to the erratum so nothing will break if someone naively makes this kernel version call init_amd_zn() also for family 0x19 in the future (as the current upstream code does). Fixes: f028a7db9824 ("x86/CPU/AMD: Disable XSAVES on AMD family 0x17") Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero(a)oracle.com> --- arch/x86/kernel/cpu/amd.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 84667781c41d..5b75a4ff6802 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -271,15 +271,6 @@ static void init_amd_k6(struct cpuinfo_x86 *c) return; } #endif - /* - * Work around Erratum 1386. The XSAVES instruction malfunctions in - * certain circumstances on Zen1/2 uarch, and not all parts have had - * updated microcode at the time of writing (March 2023). - * - * Affected parts all have no supervisor XSAVE states, meaning that - * the XSAVEC instruction (which works fine) is equivalent. - */ - clear_cpu_cap(c, X86_FEATURE_XSAVES); } static void init_amd_k7(struct cpuinfo_x86 *c) @@ -979,6 +970,17 @@ static void init_amd_zn(struct cpuinfo_x86 *c) if (c->x86 == 0x19 && !cpu_has(c, X86_FEATURE_BTC_NO)) set_cpu_cap(c, X86_FEATURE_BTC_NO); } + + /* + * Work around Erratum 1386. The XSAVES instruction malfunctions in + * certain circumstances on Zen1/2 uarch, and not all parts have had + * updated microcode at the time of writing (March 2023). + * + * Affected parts all have no supervisor XSAVE states, meaning that + * the XSAVEC instruction (which works fine) is equivalent. + */ + if (c->x86 == 0x17) + clear_cpu_cap(c, X86_FEATURE_XSAVES); } static bool cpu_has_zenbleed_microcode(void)

1 year

2
1
0 0

[PATCH 6.6.y 00/17] bpf: backport of iterator and callback handling fixes

by Eduard Zingerman

This is a backport of two upstream patch-sets: 1. "exact states comparison for iterator convergence checks" https://lore.kernel.org/all/20231024000917.12153-1-eddyz87@gmail.com/ 2. "verify callbacks as if they are called unknown number of times" https://lore.kernel.org/all/20231121020701.26440-1-eddyz87@gmail.com/ Both patch-sets fix BPF verifier logic related to handling loops: for bpf iterators, and for helper functions that accept callback functions. The backport of (2) was requested as a response to bug report by Mateusz Gienieczko <mat.gienieczko(a)tum.de>. The (1) is a dependency of (2). The patch-set was tested by running BPF verifier selftests on my local qemu-based setup. Most of the commits could be cherry-picked but three required merging: | Action | Upstream commit | |--------+-------------------------------------------------------------------------------------------------| | pick | 3c4e420cb653 ("bpf: move explored_state() closer to the beginning of verifier.c ") | | pick | 4c97259abc9b ("bpf: extract same_callsites() as utility function ") | | merge | 2793a8b015f7 ("bpf: exact states comparison for iterator convergence checks ") | | pick | 389ede06c297 ("selftests/bpf: tests with delayed read/precision makrs in loop body ") | | pick | 2a0992829ea3 ("bpf: correct loop detection for iterators convergence ") | | pick | 64870feebecb ("selftests/bpf: test if state loops are detected in a tricky case ") | | pick | b4d8239534fd ("bpf: print full verifier states on infinite loop detection ") | | drop | dedd6c894110 ("Merge branch 'exact-states-comparison-for-iterator-convergence-checks' ") | |--------+-------------------------------------------------------------------------------------------------| | pick | 977bc146d4eb ("selftests/bpf: track tcp payload offset as scalar in xdp_synproxy ") | | pick | 87eb0152bcc1 ("selftests/bpf: track string payload offset as scalar in strobemeta ") | | pick | 683b96f9606a ("bpf: extract __check_reg_arg() utility function ") | | pick | 58124a98cb8e ("bpf: extract setup_func_entry() utility function ") | | merge | ab5cfac139ab ("bpf: verify callbacks as if they are called unknown number of times ") | | pick | 958465e217db ("selftests/bpf: tests for iterating callbacks ") | | pick | cafe2c21508a ("bpf: widening for callback iterators ") | | pick | 9f3330aa644d ("selftests/bpf: test widening for iterating callbacks ") | | merge | bb124da69c47 ("bpf: keep track of max number of bpf_loop callback iterations ") | | pick | 57e2a52deeb1 ("selftests/bpf: check if max number of bpf_loop iterations is tracked ") | | drop | acb12c859ac7 ("Merge branch 'verify-callbacks-as-if-they-are-called-unknown-number-of-times' ") | Note: I don't know how deal with merge commits, so I just dropped those. These commits are empty but contain cover letters for both series, so it might be useful to pick those (how?). Eduard Zingerman (17): bpf: move explored_state() closer to the beginning of verifier.c bpf: extract same_callsites() as utility function bpf: exact states comparison for iterator convergence checks selftests/bpf: tests with delayed read/precision makrs in loop body bpf: correct loop detection for iterators convergence selftests/bpf: test if state loops are detected in a tricky case bpf: print full verifier states on infinite loop detection selftests/bpf: track tcp payload offset as scalar in xdp_synproxy selftests/bpf: track string payload offset as scalar in strobemeta bpf: extract __check_reg_arg() utility function bpf: extract setup_func_entry() utility function bpf: verify callbacks as if they are called unknown number of times selftests/bpf: tests for iterating callbacks bpf: widening for callback iterators selftests/bpf: test widening for iterating callbacks bpf: keep track of max number of bpf_loop callback iterations selftests/bpf: check if max number of bpf_loop iterations is tracked include/linux/bpf_verifier.h | 32 + kernel/bpf/verifier.c | 875 ++++++++++++++---- .../selftests/bpf/prog_tests/verifier.c | 2 + tools/testing/selftests/bpf/progs/cb_refs.c | 1 + tools/testing/selftests/bpf/progs/iters.c | 695 ++++++++++++++ .../testing/selftests/bpf/progs/strobemeta.h | 78 +- .../bpf/progs/verifier_iterating_callbacks.c | 242 +++++ .../bpf/progs/verifier_subprog_precision.c | 86 +- .../selftests/bpf/progs/xdp_synproxy_kern.c | 84 +- 9 files changed, 1830 insertions(+), 265 deletions(-) create mode 100644 tools/testing/selftests/bpf/progs/verifier_iterating_callbacks.c -- 2.43.0

1 year

2
18
0 0

[PATCH 6.6.y] Revert "drm/amd: Enable PCIe PME from D3"

by Jonathan Gray

This reverts commit 847e6947afd3c46623172d2eabcfc2481ee8668e. duplicated a change made in 6.6.5 49227bea27ebcd260f0c94a3055b14bbd8605c5e Cc: stable(a)vger.kernel.org # 6.6 Signed-off-by: Jonathan Gray <jsg(a)jsg.id.au> --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 635b58553583..2c35036e4ba2 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -2197,8 +2197,6 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, pci_wake_from_d3(pdev, TRUE); - pci_wake_from_d3(pdev, TRUE); - /* * For runpm implemented via BACO, PMFW will handle the * timing for BACO in and out: -- 2.43.0

1 year

1
0
0 0

[PATCH 6.1.y] Revert "drm/amd: Enable PCIe PME from D3"

by Jonathan Gray

This reverts commit 0c8d252d0a20a412ec30859afef6393aecfdd3cd. duplicated a change made in 6.1.66 c6088429630048661e480ed28590e69a48c102d6 Cc: stable(a)vger.kernel.org # 6.1 Signed-off-by: Jonathan Gray <jsg(a)jsg.id.au> --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index a8e1f2cfe12d..b9983ca99eb7 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -2202,8 +2202,6 @@ static int amdgpu_pci_probe(struct pci_dev *pdev, pci_wake_from_d3(pdev, TRUE); - pci_wake_from_d3(pdev, TRUE); - /* * For runpm implemented via BACO, PMFW will handle the * timing for BACO in and out: -- 2.43.0

1 year

1
0
0 0

[PATCH 4.19] powerpc: Use always instead of always-y in for crtsavres.o

by Nathan Chancellor

This commit is for linux-4.19.y only, it has no direct upstream equivalent. Prior to commit 5f2fb52fac15 ("kbuild: rename hostprogs-y/always to hostprogs/always-y"), always-y did not exist, making the backport of mainline commit 1b1e38002648 ("powerpc: add crtsavres.o to always-y instead of extra-y") to linux-4.19.y as commit b7b85ec5ec15 ("powerpc: add crtsavres.o to always-y instead of extra-y") incorrect, breaking the build with linkers that need crtsavres.o: ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or directory Backporting the aforementioned kbuild commit is not suitable for stable due to its size and number of conflicts, so transform the always-y usage to an equivalent form using always, which resolves the build issues. Fixes: b7b85ec5ec15 ("powerpc: add crtsavres.o to always-y instead of extra-y") Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- arch/powerpc/lib/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 6f1e57182876..f0aa6fc8c6b2 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -21,8 +21,8 @@ obj-$(CONFIG_PPC32) += div64.o copy_32.o crtsavres.o strlen_32.o # 64-bit linker creates .sfpr on demand for final link (vmlinux), # so it is only needed for modules, and only for older linkers which # do not support --save-restore-funcs -ifeq ($(call ld-ifversion, -lt, 225000000, y),y) -always-$(CONFIG_PPC64) += crtsavres.o +ifeq ($(call ld-ifversion, -lt, 225000000, y)$(CONFIG_PPC64),yy) +always += crtsavres.o endif obj-$(CONFIG_PPC_BOOK3S_64) += copyuser_power7.o copypage_power7.o \ --- base-commit: b060cfd3f707ad3c8ae8322e1b149ba7e2cf33e0 change-id: 20240126-4-19-fix-lib-powerpc-backport-6f4a823adf1a Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

1 year

2
1
0 0

[PATCH 0/2] kvm: fix kmalloc bug in kvm_arch_prepare_memory_region on 5.10 stable kernel

by oficerovas＠altlinux.org

From: Alexander Ofitserov <oficerovas(a)altlinux.org> Syzkaller hit 'WARNING: kmalloc bug in kvm_arch_prepare_memory_region' bug. This bug is not a vulnerability and is reproduced only when running with root privileges for stable 5.10 kernel. Bug fixed by backported commits in next two patches. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 315 at mm/util.c:618 kvmalloc_node+0x163/0x170 mm/util.c:618 Modules linked in: ide_cd_mod cdrom ide_gd_mod ata_generic pata_acpi ata_piix libata scsi_mod ide_pci_generic ppdev joydev kvm_amd ccp kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd bochs_drm cryptd af_packet drm_vram_helper glue_helper drm_ttm_helper ttm psmouse evdev pcspkr drm_kms_helper input_leds piix cec ide_core rc_core intel_agp i2c_piix4 serio_raw intel_gtt parport_pc parport floppy tiny_power_button qemu_fw_cfg button sch_fq_codel drm fuse dm_mod binfmt_misc efi_pstore virtio_rng rng_core ip_tables x_tables autofs4 CPU: 1 PID: 315 Comm: syz-executor319 Not tainted 5.10.198-std-def-alt1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:kvmalloc_node+0x163/0x170 mm/util.c:618 Code: ed 41 81 cd 00 20 01 00 e9 6c ff ff ff e8 f5 f1 d0 ff 81 e5 00 20 00 00 31 ff 89 ee e8 16 ee d0 ff 85 ed 75 cc e8 dd f1 d0 ff <0f> 0b e9 e4 fe ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 fd RSP: 0018:ffff8881034c78a0 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000010101640 RCX: ffffffff817bff9a RDX: ffff8881185e0240 RSI: ffffffff817bffa3 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000001 R09: ffff8881034c7ac8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000008080b200 R13: 0000000000000000 R14: 00000000ffffffff R15: ffff8881034c7ab0 FS: 00007f4ee2a3d740(0000) GS:ffff888140280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000008 CR3: 0000000130906000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: kvm_arch_prepare_memory_region+0x141/0x5c0 [kvm] kvm_set_memslot+0x522/0x13d0 [kvm] __kvm_set_memory_region+0xb32/0xfe0 [kvm] kvm_vm_ioctl+0x6b7/0x1cd0 [kvm] vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19f/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f4ee2b3ad49 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ef 70 0d 00 f7 d8 64 89 01 48 RSP: 002b:00007fffa9df3428 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000056092b108330 RCX: 00007f4ee2b3ad49 RDX: 00000000200000c0 RSI: 000000004020ae46 RDI: 0000000000000004 RBP: 0000000000000000 R08: 000056092b108330 R09: 000056092b108330 R10: 000056092b108330 R11: 0000000000000246 R12: 000056092b108240 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 irq event stamp: 19075 hardirqs last enabled at (19085): [<ffffffff813489c0>] console_unlock+0xa40/0xca0 kernel/printk/printk.c:2561 hardirqs last disabled at (19092): [<ffffffff81348643>] console_unlock+0x6c3/0xca0 kernel/printk/printk.c:2476 softirqs last enabled at (19108): [<ffffffff836011d2>] asm_call_irq_on_stack+0x12/0x20 softirqs last disabled at (19101): [<ffffffff836011d2>] asm_call_irq_on_stack+0x12/0x20 ---[ end trace c4463afe05024b06 ]--- Syzkaller reproducer: # {Threaded:false Repeat:false RepeatTimes:0 Procs:1 Slowdown:1 Sandbox: Leak:false NetInjection:false NetDevices:false NetReset:false Cgroups:false BinfmtMisc:false CloseFDs:false KCSAN:false DevlinkPCI:false USB:false VhciInjection:false Wifi:false IEEE802154:false Sysctl:false UseTmpDir:false HandleSegv:false Repro:false Trace:false LegacyOptions:{Collide:false Fault:false FaultCall:0 FaultNth:0}} r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x0, 0x0) connect$pppl2tp(0xffffffffffffffff, &(0x7f00000000c0)=@pppol2tp={0x18, 0x1, {0x0, 0xffffffffffffffff, {0x2, 0x0, @rand_addr=0x64010101}}}, 0x26) r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0) ioctl$KVM_CREATE_DEVICE(r1, 0x4020ae46, &(0x7f00000000c0)) C reproducer: // autogenerated by syzkaller (https://github.com/google/syzkaller) #define _GNU_SOURCE #include <endian.h> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/syscall.h> #include <sys/types.h> #include <unistd.h> uint64_t r[2] = {0xffffffffffffffff, 0xffffffffffffffff}; int main(void) { syscall(__NR_mmap, 0x1ffff000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul); syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 7ul, 0x32ul, -1, 0ul); syscall(__NR_mmap, 0x21000000ul, 0x1000ul, 0ul, 0x32ul, -1, 0ul); intptr_t res = 0; memcpy((void*)0x20000000, "/dev/kvm\000", 9); res = syscall(__NR_openat, 0xffffffffffffff9cul, 0x20000000ul, 0ul, 0ul); if (res != -1) r[0] = res; *(uint16_t*)0x200000c0 = 0x18; *(uint32_t*)0x200000c2 = 1; *(uint32_t*)0x200000c6 = 0; *(uint32_t*)0x200000ca = -1; *(uint16_t*)0x200000ce = 2; *(uint16_t*)0x200000d0 = htobe16(0); *(uint32_t*)0x200000d2 = htobe32(0x64010101); *(uint16_t*)0x200000de = 0; *(uint16_t*)0x200000e0 = 0; *(uint16_t*)0x200000e2 = 0; *(uint16_t*)0x200000e4 = 0; syscall(__NR_connect, -1, 0x200000c0ul, 0x26ul); res = syscall(__NR_ioctl, r[0], 0xae01, 0ul); if (res != -1) r[1] = res; *(uint32_t*)0x200000c0 = 0; *(uint32_t*)0x200000c8 = 0; syscall(__NR_ioctl, r[1], 0x4020ae46, 0x200000c0ul); return 0; } [PATCH 1/2] mm: vmalloc: introduce array allocation functions [PATCH 2/2] KVM: use __vcalloc for very large allocations -- 2.42.1

1 year

4
7
0 0

[PATCH 5.15.y 00/11] ksmbd: backport patches from 6.8-rc1

by Namjae Jeon

This patchset is backport patches from 6.8-rc1. -- 2.25.1

1 year

2
18
0 0

[PATCH 5.4 0/2] backport add and use mode_strip_sgid in vfs_*() helpers

by Mahmoud Adam

These patches are a follow up fixes for CVE-2021-4037 & CVE-2018-13405, LTP test creat09.c & openat04.c reproduces the privilege escalation in v5.4, the two patches solves this and they are already backported to the other stable kernels.

1 year

5
6
0 0

Consider picking up "tpm: Enable hwrng only for Pluton on AMD CPUs" rather sooner than later

by Thorsten Leemhuis

Hi stable team, JFYI, yesterdays mainline commit 556857aa1d0855 ("wifi: ath11k: rely on mac80211 debugfs handling for vif") from Benjamin contains no stable tag, but a Fixes: tag for a 6.7 commit. So it guess you will pick it up anyway. Might be worth picking up rather sooner than later, as it fixes a regression that according to Kalle causes ath11k to crash during suspend: https://lore.kernel.org/all/874jfjiolh.fsf@kernel.org/ https://bugzilla.kernel.org/show_bug.cgi?id=218364 Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.

1 year

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2024