Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5241 > unrolled thread

Kernel: Fix for CVE-2017-1000364 (mm: enlarge stack guard gap) breaks java application

Back to article view | Back to linux.debian.security

Contents

  Kernel: Fix for CVE-2017-1000364 (mm: enlarge stack guard gap)  breaks java application Stephan Seitz <stse+debian@fsing.rootsland.net> - 2017-06-26 14:50 +0200
    Re: Kernel: Fix for CVE-2017-1000364 (mm: enlarge stack guard gap)  breaks java application Salvatore Bonaccorso <carnil@debian.org> - 2017-06-27 22:20 +0200
      Re: Kernel: Fix for CVE-2017-1000364 (mm: enlarge stack guard gap)  breaks java application Stephan Seitz <stse+debian@fsing.rootsland.net> - 2017-06-28 10:30 +0200
      Re: Kernel: Fix for CVE-2017-1000364 (mm: enlarge stack guard gap)  breaks java application Rene Engelhard <rene@debian.org> - 2017-07-02 12:30 +0200

#5241 — Kernel: Fix for CVE-2017-1000364 (mm: enlarge stack guard gap) breaks java application

[Multipart message — attachments visible in raw view] — view raw

Hi!

The kernel fix for CVE-2017-1000364 (mm: enlarge stack guard gap) breaks 
java application (or at least some), see 
https://stackoverflow.com/questions/44719488/segmentation-fault-when-starting-jvm-using-jpype

You can change the stack guard gap via kernel parameter:

stack_guard_gap=	[MM]
override the default stack gap protection. The value is in page units and 
it defines how many pages prior to (for stacks growing down) resp. after 
(for stacks growing up) the main stack are reserved for no other mapping. 
Default value is 256 pages.

What is the value to get the previous behaviour?

Many greetings,

	Stephan

-- 
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

[toc] | [next] | [standalone]

#5242

Hi Stephan,

On Mon, Jun 26, 2017 at 02:32:59PM +0200, Stephan Seitz wrote:
> Hi!
> 
> The kernel fix for CVE-2017-1000364 (mm: enlarge stack guard gap) breaks
> java application (or at least some), see https://stackoverflow.com/questions/44719488/segmentation-fault-when-starting-jvm-using-jpype
> 
> You can change the stack guard gap via kernel parameter:
> 
> stack_guard_gap=	[MM]
> override the default stack gap protection. The value is in page units and it
> defines how many pages prior to (for stacks growing down) resp. after (for
> stacks growing up) the main stack are reserved for no other mapping. Default
> value is 256 pages.
> 
> What is the value to get the previous behaviour?

We issued a regression update:

https://lists.debian.org/debian-security-announce/2017/msg00160.html

To answer your question still, if you set the kernel parameter to
stack_guard_gap=1 this wuould effectively revert the fix for
CVE-2017-1000364.

Hope this helps?

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#5243

[Multipart message — attachments visible in raw view] — view raw

Hi Salvatore!

On Di, Jun 27, 2017 at 10:13:25 +0200, Salvatore Bonaccorso wrote:
>We issued a regression update:
>https://lists.debian.org/debian-security-announce/2017/msg00160.html

I have seen it. Thank you very much. It works.

>To answer your question still, if you set the kernel parameter to
>stack_guard_gap=1 this wuould effectively revert the fix for
>CVE-2017-1000364.

Thank you, this helps as well.

Shade and sweet water!

	Stephan

-- 
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

[toc] | [prev] | [next] | [standalone]

#5248

Hi,

On Tue, Jun 27, 2017 at 10:13:25PM +0200, Salvatore Bonaccorso wrote:
> We issued a regression update:
> 
> https://lists.debian.org/debian-security-announce/2017/msg00160.html
> 
> To answer your question still, if you set the kernel parameter to
> stack_guard_gap=1 this wuould effectively revert the fix for
> CVE-2017-1000364.
> 
> Hope this helps?

Apparently not on i386...

https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=i386&ver=1%3A5.3.4-1&stamp=1498741441&raw=0:

[...]
[build CUT] dbaccess_RowSetClones
S=/<<PKGBUILDDIR>> && I=$S/instdir && W=$S/workdir &&    mkdir -p $W/CppunitTest/ && rm -fr $W/CppunitTest/dbaccess_RowSetClones.test.user && mkdir $W/CppunitTest/dbaccess_RowSetClones.test.user &&    rm -fr $W/CppunitTest/dbaccess_RowSetClones.test.core && mkdir $W/CppunitTest/dbaccess_RowSetClones.test.core && cd $W/CppunitTest/dbaccess_RowSetClones.test.core && (  LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs   MALLOC_CHECK_=2 MALLOC_PERTURB_=153      $W/LinkTarget/Executable/cppunittester $W/LinkTarget/CppunitTest/libtest_dbaccess_RowSetClones.so --headless "-env:BRAND_BASE_DIR=file://$S/instdir" "-env:BRAND_SHARE_SUBDIR=share" "-env:UserInstallation=file://$W/CppunitTest/dbaccess_RowSetClones.test.user"   "-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry xcsxcu:file://$W/unittest/registry"  "-env:UNO_TYPES=file://$I/program/types/offapi.rdb file://$I/program/types/oovbaapi.rdb file://$I/program/types.rdb"  "-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb file://$W/ComponentTarget/basic/util/sb.component file://$W/ComponentTarget/comphelper/util/comphelp.component file://$W/ComponentTarget/configmgr/source/configmgr.component file://$W/ComponentTarget/connectivity/source/drivers/hsqldb/hsqldb.component file://$W/ComponentTarget/connectivity/source/drivers/jdbc/jdbc.component file://$W/ComponentTarget/connectivity/source/manager/sdbc2.component file://$W/ComponentTarget/dbaccess/util/dba.component file://$W/ComponentTarget/dbaccess/util/dbu.component file://$W/ComponentTarget/dbaccess/util/sdbt.component file://$W/ComponentTarget/dbaccess/source/filter/xml/dbaxml.component file://$W/ComponentTarget/filter/source/config/cache/filterconfig1.component file://$W/ComponentTarget/forms/util/frm.component file://$W/ComponentTarget/framework/util/fwk.component file://$W/ComponentTarget/i18npool/util/i18npool.component file://$W/ComponentTarget/linguistic/source/lng.component file://$W/ComponentTarget/oox/util/oox.component file://$W/ComponentTarget/package/source/xstor/xstor.component file://$W/ComponentTarget/package/util/package2.component file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component file://$W/ComponentTarget/scripting/source/basprov/basprov.component file://$W/ComponentTarget/scripting/util/scriptframe.component file://$W/ComponentTarget/sfx2/util/sfx.component file://$W/ComponentTarget/sot/util/sot.component file://$W/ComponentTarget/svl/source/fsstor/fsstorage.component file://$W/ComponentTarget/svl/util/svl.component file://$W/ComponentTarget/toolkit/util/tk.component file://$W/ComponentTarget/ucb/source/core/ucb1.component file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component file://$W/ComponentTarget/ucb/source/ucp/tdoc/ucptdoc1.component file://$W/ComponentTarget/unotools/util/utl.component file://$W/ComponentTarget/unoxml/source/rdf/unordf.component file://$W/ComponentTarget/unoxml/source/service/unoxml.component file://$W/ComponentTarget/uui/util/uui.component file://$W/ComponentTarget/xmloff/util/xo.component"  -env:URE_INTERNAL_LIB_DIR=file://$I/program -env:LO_LIB_DIR=file://$I/program -env:LO_JAVA_DIR=file://$I/program/classes --protector $W/LinkTarget/Library/unoexceptionprotector.so unoexceptionprotector --protector $W/LinkTarget/Library/unobootstrapprotector.so unobootstrapprotector   --protector $W/LinkTarget/Library/libvclbootstrapprotector.so vclbootstrapprotector   "-env:CPPUNITTESTTARGET=$W/CppunitTest/dbaccess_RowSetClones.test"   > $W/CppunitTest/dbaccess_RowSetClones.test.log 2>&1 || ( RET=$?; $S/solenv/bin/gdb-core-bt.sh $W/LinkTarget/Executable/cppunittester $W/CppunitTest/dbaccess_RowSetClones.test.core $RET >> $W/CppunitTest/dbaccess_RowSetClones.test.log 2>&1; cat $W/CppunitTest/dbaccess_RowSetClones.test.log; $S/solenv/gbuild/platform/unittest-failed-default.sh Cppunit dbaccess_RowSetClones))
Segmentation fault (core dumped)

It looks like /<<PKGBUILDDIR>>/workdir/LinkTarget/Executable/cppunittester generated a core file at /<<PKGBUILDDIR>>/workdir/CppunitTest/dbaccess_RowSetClones.test.core/core
Backtraces:
[New LWP 9516]
[New LWP 9520]
[New LWP 9519]
[New LWP 9517]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `/<<PKGBUILDDIR>>/workdir/LinkTarget/Executable/cppun'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xead5a975 in _expand_stack_to(unsigned char*) () from /usr/lib/jvm/java-8-openjdk-i386/jre/lib/i386/server/libjvm.so
                  ^^^^^^^^^^^^^^^^

Tests the internal db, so hsqldb, so uses Java.

Confirmed by bwh on IRC..

Regards,

Rene

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web