Le 01/02/2025 à 15:14, Erhard Furtner a écrit :
On Wed, 22 Jan 2025 19:23:00 +0100 Christophe Leroy <christophe.le...@csgroup.eu> wrote:I was able to reproduce it with v6.13 with QEMU when loading test_bpf module. On my side, the problem doesn't disappear when reverting of commit 32913f348229 ("futex: fix user access on powerpc") I bisected it to commit e4137f08816b ("mm, kasan, kmsan: instrument copy_from/to_kernel_nofault"), which makes a lot more sense to me. It might be a problem in the way patch_instruction() is implemented on powerpc, to be investigated.I think the problem is commit 37bc3e5fd764 ("powerpc/lib/code-patching: Use alternate map for patch_instruction()") Can you try the change below: diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c index af97fbb3c257..8a378fc19074 100644 --- a/arch/powerpc/lib/code-patching.c +++ b/arch/powerpc/lib/code-patching.c @@ -108,7 +108,7 @@ static int text_area_cpu_up(unsigned int cpu) unsigned long addr; int err; - area = get_vm_area(PAGE_SIZE, VM_ALLOC); + area = get_vm_area(PAGE_SIZE, 0); if (!area) { WARN_ONCE(1, "Failed to create text area for cpu %d\n", cpu);Checked on my Talos II (POWER9) too, to see whether ppc64 is also affected and here I still see the KASAN hit despite Christophes patch applied: BUG: KASAN: user-memory-access in copy_to_kernel_nofault+0x8c/0x1a0 Write of size 8 at addr 0000187e458f2000 by task systemd/1
Thanks for the report. That's something different. Previous report was: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 This is what my patch fixes. New report is: BUG: KASAN: user-memory-access in copy_to_kernel_nofault+0x8c/0x1a0 Christophe
