RFR: 8371918: aarch64: Incorrect pointer dereference in TemplateInterpreterGenerator::generate_native_entry

[Kurt Miller]

On Fri, 14 Nov 2025 17:41:56 GMT, Kurt Miller <kurt at openjdk.org> wrote:

> …rGenerator::generate_native_entry
> 
> I believe there's a incorrect pointer deference in `TemplateInterpreterGenerator::generate_native_entry()` in this part of the code:
> 
> 
> // get native function entry point in r10
>   {
>     Label L;
>     __ ldr(r10, Address(rmethod, Method::native_function_offset()));
>     ExternalAddress unsatisfied(SharedRuntime::native_method_throw_unsatisfied_link_error_entry());
>     __ lea(rscratch2, unsatisfied);
>     __ ldr(rscratch2, rscratch2);
>     __ cmp(r10, rscratch2);
>     __ br(Assembler::NE, L);
>     __ call_VM(noreg,
>                CAST_FROM_FN_PTR(address,
>                                 InterpreterRuntime::prepare_native_call),
>                rmethod);
>     __ get_method(rmethod);
>     __ ldr(r10, Address(rmethod, Method::native_function_offset()));
>     __ bind(L);
>   }
> 
> 
> If I understand this correctly, the entry point for unsatisfied link error is loaded into `rscratch2`. The next instruction, `ldr(rscratch2, rscratch2)`, dereferences that pointer and reads from the text segment the initial instructions at the entry point into `rscratch2`. It then compares the native method entry point in `r10` with the initial instructions loaded into `rscratch2` which will never match. I believe the intent here was to compare the native method entry point with the unsatisfied link error entry point and the `ldr(rscratch2, rscratch2)` instruction should be removed.
> 
> This was found on OpenBSD/aarch64. OpenBSD has a security feature where the text segments are marked execute only and do not allow reads independent of execution. the` ldr(rscratch2, rscratch2)` instruction causes a segfault because it is reading the text segment. While this bug was found on OpenBSD I believe it applies to all OS on aaarch64.
> 
> This change removes the errant aarch64 hotspot assembly instruction that was reading from libjvm.so .text segment.
> 
> Updated comment with markdown for code.

Here is a gdb session on OpenBSD/aarch64 without this patch showing the SEGFAULT where the `ldr(rscratch2, rscratch2)` instruction is attempting to load the initial instructions (`paciasp`) for `throw_unsatisfied_link_error` into `x9`:


Core was generated by `javac'.
Program terminated with signal SIGABRT, Aborted.
#0  thrkill () at /tmp/-:3

warning: 3	/tmp/-: No such file or directory
[Current thread is 1 (process 121574)]
(gdb) bt
#0  thrkill () at /tmp/-:3
#1  0x000000190c19873c in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2  0x00000019249f1470 [PAC] in os::abort (dump_core=true, siginfo=<optimized out>, context=<optimized out>) at /home/truk/jdk/jdk/src/hotspot/os/posix/os_posix.cpp:2226
#3  0x0000001924f43660 [PAC] in VMError::report_and_die (id=id at entry=11, message=<optimized out>, message at entry=0x1911d160d0 "", detail_fmt=<optimized out>, detail_args=..., 
    thread=<optimized out>, pc=0x19c269d9b8 ")\001@\371_\001\t\353A\004", siginfo=0x1911d16648, context=0x1911d16528, filename=0x0, lineno=0, size=0)
    at /home/truk/jdk/jdk/src/hotspot/share/utilities/vmError.cpp:1992
#4  0x0000001924f42df0 [PAC] in VMError::report_and_die (thread=0x1931a44800, sig=0, sig at entry=11, pc=0x0, siginfo=0x65, context=0x31, detail_fmt=0x0)
    at /home/truk/jdk/jdk/src/hotspot/share/utilities/vmError.cpp:1631
#5  0x0000001924f43d50 [PAC] in VMError::report_and_die (thread=<optimized out>, sig=11, pc=<optimized out>, siginfo=<optimized out>, context=<optimized out>)
    at /home/truk/jdk/jdk/src/hotspot/share/utilities/vmError.cpp:1651
#6  0x0000001924d0e098 [PAC] in JVM_handle_bsd_signal (sig=11, info=0x1911d16648, ucVoid=0x1911d16528, abort_if_unrecognized=1)
    at /home/truk/jdk/jdk/src/hotspot/os/posix/signals_posix.cpp:652
#7  <signal handler called>
#8  0x00000019c269d9b8 in ?? ()
#9  0x00000019c269ae70 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) frame 8
#8  0x00000019c269d9b8 in ?? ()
(gdb) x/i $pc
=> 0x19c269d9b8:	ldr	x9, [x9]
(gdb) x/i $x9
   0x1924b3fc08 <throw_unsatisfied_link_error(JNIEnv*, ...)>:	paciasp
(gdb) x/x $x9
0x1924b3fc08 <throw_unsatisfied_link_error(JNIEnv*, ...)>:	0xd503233f
(gdb) x/i $x10
   0x192aaad88c <Java_java_lang_System_registerNatives>:	bti	c

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28327#issuecomment-3533895412