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

[Christophe Leroy <christophe.leroy@csgroup.eu>]

Le 21/01/2025 à 22:00, Erhard Furtner a écrit :
> On Sun, 19 Jan 2025 22:06:42 +0530
> Madhavan Srinivasan <maddy@linux.ibm.com> wrote:
> 
>> On 1/12/25 6:28 PM, Erhard Furtner wrote:
>>> Greetings!
>>>
>>> I am getting this at bootup on my PowerMac G4 with a KASAN-enabled kernel 6.13-rc6:
>>
>> Sorry for the delayed response,
>>
>> Are you seeing this only in this kernel or this is the recent
>> kernel you tried to boot?
> 
> Meanwhile I bisected the bug. Offending commit is:
> 
>   # git bisect good
> 32913f348229c9f72dda45fc2c08c6d9dfcd3d6d is the first bad commit
> commit 32913f348229c9f72dda45fc2c08c6d9dfcd3d6d
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Mon Dec 9 10:00:25 2024 -0800
> 
>      futex: fix user access on powerpc
>      
>      The powerpc user access code is special, and unlike other architectures
>      distinguishes between user access for reading and writing.
>      
>      And commit 43a43faf5376 ("futex: improve user space accesses") messed
>      that up.  It went undetected elsewhere, but caused ppc32 to fail early
>      during boot, because the user access had been started with
>      user_read_access_begin(), but then finished off with just a plain
>      "user_access_end()".
>      
>      Note that the address-masking user access helpers don't even have that
>      read-vs-write distinction, so if powerpc ever wants to do address
>      masking tricks, we'll have to do some extra work for it.
>      
>      [ Make sure to also do it for the EFAULT case, as pointed out by
>        Christophe Leroy ]
>      
>      Reported-by: Andreas Schwab <schwab@linux-m68k.org>
>      Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>      Link: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F87bjxl6b0i.fsf%40igel.home%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Cd75d39f3c9b04d5a3aef08dd3a5ea6e9%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638730900391403538%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=unzkFDX%2BfA1H%2F%2BIvbuBqFRH9ZJVN6vuJJkOegIDtHlw%3D&reserved=0
>      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> 
>   kernel/futex/futex.h | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> 
> Indeed, reverting 32913f348229c9f72dda45fc2c08c6d9dfcd3d6d on top of v6.13 makes the KASAN hit disappear.

That looks terribly odd.

On G4, user_read_access_begin() and user_read_access_end() are no-op 
because book3s/32 can only protect user access by kernel against write. 
Read is always granted.

So the bug must be an indirect side effect of what user_access_end() 
does. user_access_end() does a sync. Would the lack of sync (once 
replaced user_access_end() by user_read_access_end() ) lead to some odd 
re-ordering ? Or another possibility is that user_access_end() is called 
on some kernel address (I see in the description of commit 43a43faf5376 
("futex: improve user space accesses") that the replaced __get_user() 
was expected to work on kernel adresses) ? Calling user_access_begin() 
and user_access_end() is unexpected and there is no guard so it could 
lead to strange segment settings which hides a KASAN hit. But once the 
fix the issue the KASAN resurfaces ? Could this be the problem ?

Do you have a way to reproduce the bug on QEMU ? It would enable me to 
investigate it further.

Christophe