futex(0x1ffffff81300000) on risc-v -> mm panic

[Alexandre Ghiti]

On 6/18/25 12:10, rtm at csail.mit.edu wrote:
> This program on risc-v:
>
> main(){
>    futex((void*) 0x1ffffff81300000, FUTEX_WAIT, 0, 0, 0, 0);


This address is far beyond what userspace is supposed to be able to 
access, even in sv57, see Documentation/arch/riscv/vm-layout.rst.

The problem is that access_ok() lets it go through and then gup returns 
a kernel mapping, which isn't good at all.

I can't reproduce the issue, but it seems like commit ad5643cf2f69 
("riscv: Define TASK_SIZE_MAX for __access_ok()") is the culprit, can 
you try reverting it?

Thanks,

Alex


> }
>
> results in:
>
> BUG: Bad page state in process a.out  pfn:81500
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81500
> flags: 0x2000(reserved|zone=0)
> raw: 0000000000002000 ff1c000000054008 ff1c000000054008 0000000000000000
> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
> Modules linked in:
> CPU: 0 UID: 0 PID: 105 Comm: a.out Not tainted 6.16.0-rc2-00067-gb61aa0e0059b #566 NONE
> Hardware name: riscv-virtio,qemu (DT)
> Call Trace:
> [<ffffffff80025b62>] dump_backtrace+0x1c/0x24
> [<ffffffff800023b8>] show_stack+0x28/0x34
> [<ffffffff800205d2>] dump_stack_lvl+0x48/0x66
> [<ffffffff80020604>] dump_stack+0x14/0x1c
> [<ffffffff80262098>] bad_page+0x118/0x15c
> [<ffffffff80264e96>] __free_frozen_pages+0x494/0x650
> [<ffffffff80266fe2>] free_frozen_pages+0xe/0x16
> [<ffffffff8020926c>] __folio_put+0x60/0xae
> [<ffffffff800ec23a>] get_futex_key+0x2da/0x44e
> [<ffffffff800f0474>] futex_wait_setup+0x52/0x23a
> [<ffffffff800f06da>] __futex_wait+0x7e/0xd8
> [<ffffffff800f0782>] futex_wait+0x4e/0xbc
> [<ffffffff800ed3a0>] do_futex+0x74/0x100
> [<ffffffff800ed4f4>] __riscv_sys_futex+0xc8/0x148
> [<ffffffff811e4930>] do_trap_ecall_u+0x84/0x11a
> [<ffffffff811f0b0e>] handle_exception+0x146/0x152
> Disabling lock debugging due to kernel taint
>
> and after running this program a few more times:
>
> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81500
> flags: 0x2000(reserved|zone=0)
> raw: 0000000000002000 ff1c000000054008 ff1c000000054008 0000000000000000
> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
> page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
> ------------[ cut here ]------------
> kernel BUG at ./include/linux/mm.h:1034!
> Kernel BUG [#1]
> Modules linked in:
> CPU: 0 UID: 0 PID: 110 Comm: a.out Tainted: G    B               6.16.0-rc2-00067-gb61aa0e0059b #566 NONE
> Tainted: [B]=BAD_PAGE
> Hardware name: riscv-virtio,qemu (DT)
> epc : get_futex_key+0x23c/0x44e
>   ra : get_futex_key+0x23c/0x44e
> ...
> [<ffffffff800ec19c>] get_futex_key+0x23c/0x44e
> [<ffffffff800f0474>] futex_wait_setup+0x52/0x23a
> [<ffffffff800f06da>] __futex_wait+0x7e/0xd8
> [<ffffffff800f0782>] futex_wait+0x4e/0xbc
> [<ffffffff800ed3a0>] do_futex+0x74/0x100
> [<ffffffff800ed4f4>] __riscv_sys_futex+0xc8/0x148
> [<ffffffff811e4930>] do_trap_ecall_u+0x84/0x11a
> [<ffffffff811f0b0e>] handle_exception+0x146/0x152
> Code: bdad a597 017c 8593 fa65 8526 7097 0014 80e7 a4a0 (9002) 8785
> ---[ end trace 0000000000000000 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
>
> get_futex_key() calls get_user_pages_fast(), which returns a
> PG_reserved page in one of the reserve_bootmem_region() areas. Beyond
> that I do not understand the situation.
>
> Robert Morris
> rtm at mit.edu
>