January 2024 - Linux-stable-mirror

Stable bugfix backport request of "KVM: x86: smm: preserve interrupt shadow in SMRAM"?

by Dongli Zhang

Hi Maxim and Paolo, This is the linux-stable backport request regarding the below patch. KVM: x86: smm: preserve interrupt shadow in SMRAM https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… According to the below link, there may be a backport to stable kernels, while I do not see it in the stable kernels. https://gitlab.com/qemu-project/qemu/-/issues/1198 Would you mind sharing if there is already any existing backport, or please let me know if I can send the backport to the linux-stable? There are many conflicts unless we backport the entire patchset, e.g.,: I choose 0x7f1a/0x7ecb for 32-bit/64-bit int_shadow in the smram. -------------------------------- From 90f492c865a4b7ca6187a4fc9eebe451f3d6c17e Mon Sep 17 00:00:00 2001 From: Maxim Levitsky <mlevitsk(a)redhat.com> Date: Fri, 26 Jan 2024 14:03:59 -0800 Subject: [PATCH linux-5.15.y 1/1] KVM: x86: smm: preserve interrupt shadow in SMRAM [ Upstream commit fb28875fd7da184079150295da7ee8d80a70917e ] When #SMI is asserted, the CPU can be in interrupt shadow due to sti or mov ss. It is not mandatory in Intel/AMD prm to have the #SMI blocked during the shadow, and on top of that, since neither SVM nor VMX has true support for SMI window, waiting for one instruction would mean single stepping the guest. Instead, allow #SMI in this case, but both reset the interrupt window and stash its value in SMRAM to restore it on exit from SMM. This fixes rare failures seen mostly on windows guests on VMX, when #SMI falls on the sti instruction which mainfest in VM entry failure due to EFLAGS.IF not being set, but STI interrupt window still being set in the VMCS. Signed-off-by: Maxim Levitsky <mlevitsk(a)redhat.com> Message-Id: <20221025124741.228045-24-mlevitsk(a)redhat.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Backport fb28875fd7da184079150295da7ee8d80a70917e from a big patchset merge: [PATCH RESEND v4 00/23] SMM emulation and interrupt shadow fixes https://lore.kernel.org/all/20221025124741.228045-1-mlevitsk@redhat.com/ Since only the last patch is backported, there are many conflicts. The core idea of the patch: - Save the interruptibility before entering SMM. - Load the interruptibility after leaving SMM. Although the real offsets in smram buffer are the same, the bugfix and the UEK5 use different offsets in the function calls. Here are some examples. 32-bit: bugfix UEK6 smbase -> 0xFEF8 -> 0x7ef8 cr4 -> 0xFF14 -> 0x7f14 int_shadow -> 0xFF1A -> n/a eip -> 0xFFF0 -> 0x7ff0 cr0 -> 0xFFFC -> 0x7ffc 64-bit: bugfix UEK6 int_shadow -> 0xFECB -> n/a efer -> 0xFEd0 -> 0x7ed0 smbase -> 0xFF00 -> 0x7f00 cr4 -> 0xFF48 -> 0x7f48 cr0 -> 0xFF58 -> 0x7f58 rip -> 0xFF78 -> 0x7f78 Therefore, we choose the below offsets for int_shadow: 32-bit: int_shadow = 0x7f1a 64-bit: int_shadow = 0x7ecb Signed-off-by: Dongli Zhang <dongli.zhang(a)oracle.com> --- arch/x86/kvm/emulate.c | 15 +++++++++++++-- arch/x86/kvm/x86.c | 6 ++++++ 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index 98b25a7..00df781b 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -2438,7 +2438,7 @@ static int rsm_load_state_32(struct x86_emulate_ctxt *ctxt, struct desc_ptr dt; u16 selector; u32 val, cr0, cr3, cr4; - int i; + int i, r; cr0 = GET_SMSTATE(u32, smstate, 0x7ffc); cr3 = GET_SMSTATE(u32, smstate, 0x7ff8); @@ -2488,7 +2488,15 @@ static int rsm_load_state_32(struct x86_emulate_ctxt *ctxt, ctxt->ops->set_smbase(ctxt, GET_SMSTATE(u32, smstate, 0x7ef8)); - return rsm_enter_protected_mode(ctxt, cr0, cr3, cr4); + r = rsm_enter_protected_mode(ctxt, cr0, cr3, cr4); + + if (r != X86EMUL_CONTINUE) + return r; + + static_call(kvm_x86_set_interrupt_shadow)(ctxt->vcpu, 0); + ctxt->interruptibility = GET_SMSTATE(u8, smstate, 0x7f1a); + + return r; } #ifdef CONFIG_X86_64 @@ -2559,6 +2567,9 @@ static int rsm_load_state_64(struct x86_emulate_ctxt *ctxt, return r; } + static_call(kvm_x86_set_interrupt_shadow)(ctxt->vcpu, 0); + ctxt->interruptibility = GET_SMSTATE(u8, smstate, 0x7ecb); + return X86EMUL_CONTINUE; } #endif diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index aa6f700..6b30d40 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -9400,6 +9400,8 @@ static void enter_smm_save_state_32(struct kvm_vcpu *vcpu, char *buf) /* revision id */ put_smstate(u32, buf, 0x7efc, 0x00020000); put_smstate(u32, buf, 0x7ef8, vcpu->arch.smbase); + + put_smstate(u8, buf, 0x7f1a, static_call(kvm_x86_get_interrupt_shadow)(vcpu)); } #ifdef CONFIG_X86_64 @@ -9454,6 +9456,8 @@ static void enter_smm_save_state_64(struct kvm_vcpu *vcpu, char *buf) for (i = 0; i < 6; i++) enter_smm_save_seg_64(vcpu, buf, i); + + put_smstate(u8, buf, 0x7ecb, static_call(kvm_x86_get_interrupt_shadow)(vcpu)); } #endif @@ -9490,6 +9494,8 @@ static void enter_smm(struct kvm_vcpu *vcpu) kvm_set_rflags(vcpu, X86_EFLAGS_FIXED); kvm_rip_write(vcpu, 0x8000); + static_call(kvm_x86_set_interrupt_shadow)(vcpu, 0); + cr0 = vcpu->arch.cr0 & ~(X86_CR0_PE | X86_CR0_EM | X86_CR0_TS | X86_CR0_PG); static_call(kvm_x86_set_cr0)(vcpu, cr0); vcpu->arch.cr0 = cr0; -- 1.8.3.1 -------------------------------- Thank you very much! Dongli Zhang

1 year, 4 months

2
5
0 0

[PATCH] drm/amd/display: pbn_div need be updated for hotplug event

by Alex Deucher

From: Wayne Lin <wayne.lin(a)amd.com> link_rate sometime will be changed when DP MST connector hotplug, so pbn_div also need be updated; otherwise, it will mismatch with link_rate, causes no output in external monitor. This is a backport of commit 9cdef4f72037 ("drm/amd/display: pbn_div need be updated for hotplug event") to 6.1. This fixes a display light up failure on some docking stations. Cc: stable(a)vger.kernel.org Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Reviewed-by: Jerry Zuo <jerry.zuo(a)amd.com> Acked-by: Rodrigo Siqueira <rodrigo.siqueira(a)amd.com> Signed-off-by: Wade Wang <wade.wang(a)hp.com> Signed-off-by: Wayne Lin <wayne.lin(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 9cdef4f720376ef0fb0febce1ed2377c19e531f9) --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 13e0b521e3db..f02e509d5fac 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -6677,8 +6677,7 @@ static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder, if (IS_ERR(mst_state)) return PTR_ERR(mst_state); - if (!mst_state->pbn_div) - mst_state->pbn_div = dm_mst_get_pbn_divider(aconnector->mst_port->dc_link); + mst_state->pbn_div = dm_mst_get_pbn_divider(aconnector->mst_port->dc_link); if (!state->duplicated) { int max_bpc = conn_state->max_requested_bpc; -- 2.42.0

1 year, 4 months

2
1
0 0

[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, 4 months

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, 4 months

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, 4 months

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, 4 months

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, 4 months

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, 4 months

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 months

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, 4 months

2
18
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2024