Hi,
commit 959cadf09dbae7b304f03e039b8d8e13c529e2dd Author: Peter Zijlstra peterz@infradead.org Date: Mon Oct 14 10:05:48 2024 -0700
x86/its: Use dynamic thunks for indirect branches
commit 872df34d7c51a79523820ea6a14860398c639b87 upstream.
was ported at v6.1.139 and leads to kernel crashes there after module unload operations.
Example trace: BUG: unable to handle page fault for address: ffff8fcb47dd4000 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 34801067 P4D 34801067 PUD 100148063 PMD 107dd5063 PTE 8000000107dd4161 Oops: 0003 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 378 Comm: modprobe Not tainted 6.1.139-01446-g753bd4a5f9a9 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:__change_page_attr_set_clr+0x49d/0x1280 Call Trace: <TASK> ? free_unref_page_prepare+0x80/0x4b0 set_direct_map_invalid_noflush+0x6e/0xa0 __vunmap+0x18c/0x3e0 __vfree+0x21/0xb0 vfree+0x2b/0x90 module_memfree+0x1b/0x50 free_module+0x17c/0x250 __do_sys_delete_module+0x337/0x4b0 __x64_sys_delete_module+0x15/0x30 x64_sys_call+0x3f9a/0x43a0 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f70755c0807 </TASK> Modules linked in: dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua [last unloaded: scsi_debug]
As mentioned in the blamed patch comment describing the backport adaptations:
[ pawan: CONFIG_EXECMEM and CONFIG_EXECMEM_ROX are not supported on backport kernel, made changes to use module_alloc() and set_memory_*() for dynamic thunks. ]
module_alloc/module_memfree in conjunction with memory protection routines were used. The allocated memory is vmalloc-based, and it ends up being ROX upon release inside its_free_mod().
Freeing of special permissioned memory in vmalloc requires its own handling. VM_FLUSH_RESET_PERMS flag was introduced for these purposes.
In-kernel users dealing with the stuff had to care about this explicitly before commit 4c4eb3ecc91f ("x86/modules: Set VM_FLUSH_RESET_PERMS in module_alloc()").
More recent kernels starting from 6.2 have the commit and are not affected.
So port it as a followup for ITS mitigation 6.1-series to fix the aforementioned failures.
The problem concerns 5.15-series (currently in stable-queue) as well. It needs its own patch to apply cleanly. Will send it shortly, too.
Found by Linux Verification Center (linuxtesting.org).
Thomas Gleixner (1): x86/modules: Set VM_FLUSH_RESET_PERMS in module_alloc()
arch/x86/kernel/ftrace.c | 2 -- arch/x86/kernel/kprobes/core.c | 1 - arch/x86/kernel/module.c | 9 +++++---- 3 files changed, 5 insertions(+), 7 deletions(-)
From: Thomas Gleixner tglx@linutronix.de
commit 4c4eb3ecc91f4fee6d6bf7cfbc1e21f2e38d19ff upstream.
Instead of resetting permissions all over the place when freeing module memory tell the vmalloc code to do so. Avoids the exercise for the next upcoming user.
Signed-off-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Link: https://lore.kernel.org/r/20220915111143.406703869@infradead.org Signed-off-by: Fedor Pchelkin pchelkin@ispras.ru --- arch/x86/kernel/ftrace.c | 2 -- arch/x86/kernel/kprobes/core.c | 1 - arch/x86/kernel/module.c | 9 +++++---- 3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c index e73743701530..48cf91625a16 100644 --- a/arch/x86/kernel/ftrace.c +++ b/arch/x86/kernel/ftrace.c @@ -415,8 +415,6 @@ create_trampoline(struct ftrace_ops *ops, unsigned int *tramp_size) /* ALLOC_TRAMP flags lets us know we created it */ ops->flags |= FTRACE_OPS_FL_ALLOC_TRAMP;
- set_vm_flush_reset_perms(trampoline); - if (likely(system_state != SYSTEM_BOOTING)) set_memory_ro((unsigned long)trampoline, npages); set_memory_x((unsigned long)trampoline, npages); diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c index 991f00c817e6..180c708879d2 100644 --- a/arch/x86/kernel/kprobes/core.c +++ b/arch/x86/kernel/kprobes/core.c @@ -427,7 +427,6 @@ void *alloc_insn_page(void) if (!page) return NULL;
- set_vm_flush_reset_perms(page); /* * First make the page read-only, and only then make it executable to * prevent it from being W+X in between. diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c index 7728060b640c..c34ea5e028c4 100644 --- a/arch/x86/kernel/module.c +++ b/arch/x86/kernel/module.c @@ -74,10 +74,11 @@ void *module_alloc(unsigned long size) return NULL;
p = __vmalloc_node_range(size, MODULE_ALIGN, - MODULES_VADDR + get_module_load_offset(), - MODULES_END, gfp_mask, - PAGE_KERNEL, VM_DEFER_KMEMLEAK, NUMA_NO_NODE, - __builtin_return_address(0)); + MODULES_VADDR + get_module_load_offset(), + MODULES_END, gfp_mask, PAGE_KERNEL, + VM_FLUSH_RESET_PERMS | VM_DEFER_KMEMLEAK, + NUMA_NO_NODE, __builtin_return_address(0)); + if (p && (kasan_alloc_module_shadow(p, size, gfp_mask) < 0)) { vfree(p); return NULL;
From: Fedor Pchelkin pchelkin@ispras.ru
From: Thomas Gleixner tglx@linutronix.de
commit 4c4eb3ecc91f4fee6d6bf7cfbc1e21f2e38d19ff upstream.
Instead of resetting permissions all over the place when freeing module memory tell the vmalloc code to do so. Avoids the exercise for the next upcoming user.
Signed-off-by: Thomas Gleixner tglx@linutronix.de Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Link: https://lore.kernel.org/r/20220915111143.406703869@infradead.org Signed-off-by: Fedor Pchelkin pchelkin@ispras.ru
I confirm this patch fixed the random crashing ontop of 6.1.139 I've experienced on our Icelake and Cascadelake servers, servers are working fine after appling the fix, thx!
Tested-by: Jack Wang jinpu.wang@ionos.com
linux-stable-mirror@lists.linaro.org
-
Fedor Pchelkin -
Jack Wang