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

-- 
2.49.0

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>