I got the following crash on Freebsd/Riscv64 using Syzkaller: --- Kernel Version: FreeBSD 14.0-CURRENT #2 main-8e59ec29e: Fri Aug 26 22:25:12 CST 2022 --- Report: --- panic: pmap_l2_to_l3: PA out of range, PA: 0x0 cpuid = 0 time = 1661807909 KDB: stack backtrace: db_trace_self() at db_trace_self db_trace_self_wrapper() at db_trace_self_wrapper+0x66 kdb_backtrace() at kdb_backtrace+0x3c vpanic() at vpanic+0x1bc panic() at panic+0x26 pmap_remove_pages() at pmap_remove_pages+0xb16 vmspace_exit() at vmspace_exit+0x184 exit1() at exit1+0x744 sys_exit() at sys_exit+0x10 do_trap_user() at do_trap_user+0x3f0 cpu_exception_handler_user() at cpu_exception_handler_user+0x72 --- exception 8, tval = 0 KDB: enter: panic [ thread pid 85498 tid 209553 ] Stopped at kdb_enter+0x8c: sd zero,0(s1) --- There are no reproducer available.
I have a fix for this one, which will be available soon. I observed the issue after exiting a gdb session, in which the target program was run more than once. This can be reproduced reliably.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=9d1aef84021f4e99d37f4e9149a8799c3d9e5e03 commit 9d1aef84021f4e99d37f4e9149a8799c3d9e5e03 Author: Mitchell Horne <mhorne@FreeBSD.org> AuthorDate: 2022-10-05 17:11:02 +0000 Commit: Mitchell Horne <mhorne@FreeBSD.org> CommitDate: 2022-10-06 22:02:38 +0000 riscv: handle superpage in pmap_enter_quick_locked() Previously, if pmap_enter_l2() was asked to re-map an existing superpage (the result of madvise(MADV_WILLNEED) on a mapped range), it could 'fail' to do so, falling back to trying pmap_enter_quick_locked() for each 4K virtual page. Because this function does not check if the l2 entry it finds is a superpage, it would proceed, sometimes resulting in the creation of false PV entries. If the relevant range was later munmap'ed, the system would panic during the process' exit in pmap_remove_pages(), while attempting to clean up the PV entries for mappings which no longer exist. Instead, we should return early in the presence of an existing superpage, as is done in other pmaps. PR: 266108 Reviewed by: markj, alc MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D36563 sys/riscv/riscv/pmap.c | 2 ++ 1 file changed, 2 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=472294b86549d6cb7562cff4f702010a34565c87 commit 472294b86549d6cb7562cff4f702010a34565c87 Author: Mitchell Horne <mhorne@FreeBSD.org> AuthorDate: 2022-10-05 17:11:02 +0000 Commit: Mitchell Horne <mhorne@FreeBSD.org> CommitDate: 2022-10-13 14:05:20 +0000 riscv: handle superpage in pmap_enter_quick_locked() Previously, if pmap_enter_l2() was asked to re-map an existing superpage (the result of madvise(MADV_WILLNEED) on a mapped range), it could 'fail' to do so, falling back to trying pmap_enter_quick_locked() for each 4K virtual page. Because this function does not check if the l2 entry it finds is a superpage, it would proceed, sometimes resulting in the creation of false PV entries. If the relevant range was later munmap'ed, the system would panic during the process' exit in pmap_remove_pages(), while attempting to clean up the PV entries for mappings which no longer exist. Instead, we should return early in the presence of an existing superpage, as is done in other pmaps. PR: 266108 Reviewed by: markj, alc MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D36563 (cherry picked from commit 9d1aef84021f4e99d37f4e9149a8799c3d9e5e03) sys/riscv/riscv/pmap.c | 2 ++ 1 file changed, 2 insertions(+)
*** Bug 267225 has been marked as a duplicate of this bug. ***