Bug#865303: Java JNI crashes post CVE-2017-1000364 fixes post 4.9.30-2+deb9u2
I am experiencing a related issue which is caused by calling the JNI
JVM init from python.
Steps to reproduce:
1. cd /usr/lib/x86_64-linux-gnu
2. sudo ln -s libpython3.5m.a libpython3.5.a
3. sudo ln -s libpython3.5m.so libpython3.5.so
4. python3 -m virtualenv -p python3 venv3
5. source venv3/bin/activate
6. JCC_JDK=/usr/lib/jvm/java-8-openjdk-amd64
7. pip install jcc --no-cache-dir
8. python -m jcc --package java.lang
Results obtained: SEGV
Results expected: command exits normally
Using 4.9.0-1 (pre-patch for CVE-2017-1000364): command exits normally.
It also works to run python under GDB, break before the JVM calls
os::pd_create_stack_guard_pages (os_linux.cpp:2985) and read enough
stack pages (using x/x) to force the kernel to move the stack guard
far enough for successful execution. This is similar behavior to
compiling C code with -fstack-check, which I assume Python is.
os::pd_create_stack_guard_pages calls mmap() to create the JVM's own
stack-guard pages (which are now unneeded?) which seems to cause linux
kernel to no longer be able to detect when the kernel's stack guard
pages need to be advanced down so the stack guard is then stuck in
place at whatever the largest size of the stack was when
os::pd_create_stack_guard_pages was called. The JVM isn't expecting a
(kernel-created) stack-guard page at this location so it grows the
stack (using alloca()), tries to write to it and SEGV.
Before os::pd_create_stack_guard_pages the linux kernel correctly
detects the page at the top of the stack as the stack page, as
reported by pmap(1) or (gdb) info proc maps. The stack pages are
marked by the kernel as [stack].
After os::pd_create_stack_guard_pages the linux kernel no longer
correctly detects the page the top of the stack as the stack page as
reported by pmap(1) or (gdb) info proc maps. The stack pages are NO
LONGER marked by the kernel as [stack]; and the kernel stack-guard
page is now frozen in place for the remainder of the process
execution.
--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
joshua2@ualberta.ca
Reply to: