Bug#865303: Java JNI crashes post CVE-2017-1000364 fixes post 4.9.30-2+deb9u2

[Joshua Campbell]

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
josh...@ualberta.ca

Bug#867314: openjdk-8-jre-headless: openjdk unwinder for gdb crashes

[Joshua Campbell]

The problem seems to be solved by

ln -s /usr/lib/debug/usr/lib/jvm/java-8-openjdk-amd64
/usr/lib/debug/usr/lib/jvm/java-1.8.0-openjdk-amd64

On Wed, Jul 5, 2017 at 10:36 AM, Joshua Charles Campbell
 wrote:
> Package: openjdk-8-jre-headless
> Version: 8u131-b11-2
> Severity: normal
>
> Dear Maintainer,
>
> When running python code that calls the JVM via JNI GDB can't install the
> openjdk unwinder.
>
> When running gdb --args python -m jcc --jar some-jar-file.jar and then running
> (just make a virtualenv, pip install jcc, and point it at some jar file):
>
> Starting program: /home/joshua/unnaturalcode/venv3/bin/python -m jcc --jar
> java/lex-java/target/lex-java-1.0-SNAPSHOT.jar
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Installing openjdk unwinder
> Traceback (most recent call last):
>   File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-
> amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 52, in 
> class Types(object):
>   File "/usr/share/gdb/auto-load/usr/lib/jvm/java-8-openjdk-
> amd64/jre/lib/amd64/server/libjvm.so-gdb.py", line 66, in Types
> nmethodp_t = gdb.lookup_type('nmethod').pointer()
> gdb.error: No type named nmethod.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7fffe47f22b4 in ?? ()
> (gdb) bt
> #0  0x7fffe47f22b4 in ?? ()
> #1  0x0246 in ?? ()
> #2  0x7fffe47f2160 in ?? ()
> #3  0x7fffc8c0 in ?? ()
> #4  0x7fffc860 in ?? ()
> #5  0x7600d075 in VM_Version::get_processor_features() ()
>from /usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/lib/amd64/server/libjvm.so
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb)
>
> Expected outcome: an actual stacktrace.
>
>
>
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers stable
>   APT policy: (990, 'stable'), (40, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_CA:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages openjdk-8-jre-headless depends on:
> ii  ca-certificates-java  20170531+nmu1
> ii  java-common   0.58
> ii  libc6 2.24-11+deb9u1
> ii  libcups2  2.2.1-8
> ii  libfontconfig12.11.0-6.7+b1
> ii  libfreetype6  2.6.3-3.2
> ii  libgcc1   1:6.3.0-18
> ii  libjpeg62-turbo   1:1.5.1-2
> ii  liblcms2-22.8-4
> ii  libnss3   2:3.26.2-1.1
> ii  libpcsclite1  1.8.20-1
> ii  libstdc++66.3.0-18
> ii  libx11-6  2:1.6.4-3
> ii  libxext6  2:1.3.3-1+b2
> ii  libxi62:1.7.9-1
> ii  libxrender1   1:0.9.10-1
> ii  libxtst6  2:1.2.3-1
> ii  multiarch-support 2.24-11+deb9u1
> ii  util-linux2.29.2-1
> ii  zlib1g1:1.2.8.dfsg-5
>
> openjdk-8-jre-headless recommends no packages.
>
> Versions of packages openjdk-8-jre-headless suggests:
> ii  fonts-dejavu-extra2.37-1
> pn  fonts-indic   
> ii  fonts-ipafont-gothic  00303-16
> ii  fonts-ipafont-mincho  00303-16
> pn  fonts-wqy-microhei
> pn  fonts-wqy-zenhei  
> ii  libnss-mdns   0.10-8
>
> -- no debconf information



-- 
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
josh...@ualberta.ca