BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 (v6.13-rc6, PowerMac G4)

[Christophe Leroy]

Le 01/02/2025 à 15:14, Erhard Furtner a écrit :
> On Wed, 22 Jan 2025 19:23:00 +0100
> Christophe Leroy <christophe.leroy at 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