Bug 1045340

Could you please provide strace -f output for the failing start? Thanks.

I could reproduce the issue on KVM, freshly deployed openSUSE Leap 42.2 image.
Just installed novell-groupwise-gwclient.rpm from IBS, and update to 4.4.72 kernel.

The strace log is attached below.

Created attachment 729702 [details]
strace from groupwise crash

Created attachment 729708 [details]
strace log at good working case

Created attachment 729714 [details]
strace -f /opt/novell/groupwise/client/bin/groupwise-bin

(In reply to Takashi Iwai from comment #2)
> Just installed novell-groupwise-gwclient.rpm from IBS, and update to 4.4.72
> kernel.

How exactly can I get the rpm?

(In reply to Andreas Stieger from comment #7)
> (In reply to Vlastimil Babka from comment #6)
> > How exactly can I get the rpm?
> 
> I am using:
> 
> https://gwclient.innerweb.novell.com/
> https://gwclient.innerweb.novell.com/client/gw802linuxclient.tar.gz

Thanks. I've run it under gdb and when it segfaulted, checked the /proc/pid/smaps:

ffedd000-fffae000 rwxp 00000000 00:00 0    (this is without the gap)
Size:               1860 kB                (the size however includes gap)
...
VmFlags: rd wr ex mr mw me gd ac           (gd == grows down - a stack)
fffae000-fffb1000 ---p 00000000 00:00 0    (not r/w/x)
Size:                 12 kB
...
VmFlags: mr mw me ac sd                    (doesn't have gd)
1000b1000-ffffe000 rwxp 00000000 00:00 0   (invalid reported start addr as it adds the full gap size to real vma start)         [stack]
Size:                308 kB                (real size without gap: fffb1000-ffffe000)
Rss:                  24 kB                (we have used only this much stack yet)
Pss:                  24 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        24 kB
Referenced:           24 kB
Anonymous:            24 kB
AnonHugePages:         0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Locked:                0 kB
VmFlags: rd wr ex mr mw me gd ac           (again grows down)

Looks like the same issue as I've seen with jsvc reproducer from debian bugzilla, that we discussed via mail. The original stack ffedd000-ffffe000 was split by mprotecting the area 
ffedd000-fffae000 inside the stack. The remaining "upper part" fffb1000-ffffe000 is now smaller than stack gap, and preceding vma is not a stack, so faulting a new page in the upper part (where we only have faulted in 24 kB so far) will find this out and fail to enlarge the gap, thus segfault.

(In reply to Vlastimil Babka from comment #8)
> (In reply to Andreas Stieger from comment #7)
> > (In reply to Vlastimil Babka from comment #6)
> > > How exactly can I get the rpm?
> > 
> > I am using:
> > 
> > https://gwclient.innerweb.novell.com/
> > https://gwclient.innerweb.novell.com/client/gw802linuxclient.tar.gz
> 
> Thanks. I've run it under gdb and when it segfaulted, checked the
> /proc/pid/smaps:

And also managed to catch the mmap+mprotect syscalls responsible for the vma split. No idea why these addresses are not visible in the strace log, though...

Catchpoint 1 (call to syscall mmap2), 0xf7fd9f89 in __kernel_vsyscall ()
(gdb) info registers
eax            0xffffffda       -38
ecx            0x3000   12288
edx            0x3      3
ebx            0xfffae000       -335872
esp            0xffffbd5c       0xffffbd5c
ebp            0x0      0x0
esi            0x32     50
edi            0xffffffff       -1
eip            0xf7fd9f89       0xf7fd9f89 <__kernel_vsyscall+9>
eflags         0x246    [ PF ZF IF ]
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x0      0
gs             0x63     99
(gdb) c
Continuing.

Catchpoint 1 (returned from syscall mmap2), 0xf7fd9f89 in __kernel_vsyscall ()
(gdb) c
Continuing.

Catchpoint 2 (call to syscall mprotect), 0xf7fd9f89 in __kernel_vsyscall ()
(gdb) info reg
eax            0xffffffda       -38
ecx            0x3000   12288
edx            0x0      0
ebx            0xfffae000       -335872
esp            0xffffbd78       0xffffbd78
ebp            0xffffbda8       0xffffbda8
esi            0xfffae000       -335872
edi            0x8054800        134563840
eip            0xf7fd9f89       0xf7fd9f89 <__kernel_vsyscall+9>
eflags         0x246    [ PF ZF IF ]
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x0      0
gs             0x63     99

(In reply to Vlastimil Babka from comment #9)
> Catchpoint 1 (call to syscall mmap2), 0xf7fd9f89 in __kernel_vsyscall ()

(gdb) bt
#0  0xf7fd9f89 in __kernel_vsyscall ()
#1  0xf7454508 in mmap () from /lib/libc.so.6
#2  0xf7a51cdb in os::commit_memory(char*, unsigned int, bool) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
#3  0xf7afd1be in JavaThread::create_stack_guard_pages() () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
#4  0xf7afedd3 in Threads::create_vm(JavaVMInitArgs*, bool*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
#5  0xf7960566 in JNI_CreateJavaVM () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
#6  0x08048dc3 in LaunchJavaVm (argc=0, argv=0xffffd528, szPathToClientDir=0xffffd068 "/opt/novell/groupwise/client") at grpwisex.cpp:380
#7  0x080497a3 in main (argc=1, argv=0xffffd524) at grpwisex.cpp:473

> Catchpoint 2 (call to syscall mprotect), 0xf7fd9f89 in __kernel_vsyscall ()
(gdb) bt
#0  0xf7fd9f89 in __kernel_vsyscall ()
#1  0xf74545f9 in mprotect () from /lib/libc.so.6
#2  0xf7a525b9 in os::guard_memory(char*, unsigned int) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
#3  0xf7afd1e2 in JavaThread::create_stack_guard_pages() () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
#4  0xf7afedd3 in Threads::create_vm(JavaVMInitArgs*, bool*) () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
#5  0xf7960566 in JNI_CreateJavaVM () from /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
#6  0x08048dc3 in LaunchJavaVm (argc=0, argv=0xffffd528, szPathToClientDir=0xffffd068 "/opt/novell/groupwise/client") at grpwisex.cpp:380
#7  0x080497a3 in main (argc=1, argv=0xffffd524) at grpwisex.cpp:473

At least we see it's done by java itself and not glibc.

(In reply to Vlastimil Babka from comment #10)
> #3  0xf7afd1e2 in JavaThread::create_stack_guard_pages() () from
> /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so

Looks to me like this is intended to create guard pages from userspace for non-initial threads, which AFAIK have fixed-size stacks in pthread implementation, so probably also in java. Pthreads seem to also have guard pages controlled by pthread_attr_setguardsize(). Neither should care or have issues with the kernel's guard gap implementation or gap size, as long as the extra thread stacks are not VM_GROWSDOWN.

Seems there is a bug when java VM is invoked via JNI_CreateJavaVM () from another binary (and not the java launcher), where these guard pages for extra threads are applied to the initial thread and its VM_GROWSDOWN stack, where it does have issues with the larger in-kernel gap as I analyzed above.

Same here for running tomcat with latest OpenSUSE 42.2 kernel.

The child of the jsvc.exec process is crashing.

...

[pid 9724] lseek(5, 50127203, SEEK_SET) = 50127203
[pid 9724] read(5, "\312\376\272\276\0\0\0001\0\373\10\0'\1\0\3()I\1\0\3()V\1\0\4(I)Z"..., 6146) = 6146
[pid 9724] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7ffdf10cfb00} ---
[pid 9724] rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], ~[KILL STOP RTMIN RT_1], 8) = 0
[pid 9724] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7ffdf10cfff0} ---
[pid 9731] <... futex resumed> ) = ? <unavailable>
[pid 9727] +++ killed by SIGSEGV +++
[pid 9731] +++ killed by SIGSEGV +++
[pid 9732] +++ killed by SIGSEGV +++
[pid 9730] +++ killed by SIGSEGV +++
[pid 9729] +++ killed by SIGSEGV +++
[pid 9728] +++ killed by SIGSEGV +++
[pid 9726] +++ killed by SIGSEGV +++
[pid 9725] +++ killed by SIGSEGV +++
[pid 9733] +++ killed by SIGSEGV +++
[pid 9724] +++ killed by SIGSEGV +++
<... wait4 resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], 0, NULL) = 9724
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=9724, si_uid=1013, si_status=SIGSEGV, si_utime=2, si_stime=2} ---
write(2, "Service killed by signal 11\n", 28) = 28
...

Same happens also for eclipse and libreoffice with enabled java.

Is there any chance for a "fast" fix? Is there already a discussion on lkml?

At debian someone pointed to the latest unstable kernel here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865311#52

which should have a later version of the gap patch which does not have this issue? The patch in the debian patch points to this commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1be7107fbe18eed3e319a6c3e83c78254b693acb

Is this the version OpenSuSE uses?

Thank you Vlastimil! Very helpful. So it doesn't look like an accounting bug which I was suspecting. I am really surprised the mapping in the middle doesn't have VM_GROWSDOWN. mprotect should preserve VM_GROWS* flag.

And indeed mprotect does the following
        prot &= ~(PROT_GROWSDOWN|PROT_GROWSUP);
[...]
        vm_flags = calc_vm_prot_bits(prot);
[...]
                newflags = vm_flags; 
                newflags |= (vma->vm_flags & ~(VM_READ | VM_WRITE | VM_EXEC));

so it should preserve everything but RWX which are taken from the given prot parameter. Maybe I am missing something though. I will be staring into the code some more.

Here is the backported version of the upstream patch for kernel 4.4.

It applies cleanly to the opensuse 42.2 git master:
https://patchwork.kernel.org/patch/9796395/

I just had to remove:
mm-enlarge-stack-guard-gap.patch
mm-do-not-collapse-stack-gap-into-THP.patch

(In reply to Stefan Priebe from comment #15)
> Here is the backported version of the upstream patch for kernel 4.4.
> 
> It applies cleanly to the opensuse 42.2 git master:
> https://patchwork.kernel.org/patch/9796395/
> 
> I just had to remove:
> mm-enlarge-stack-guard-gap.patch
> mm-do-not-collapse-stack-gap-into-THP.patch

Yes we will go with the upstream version of the patch in the end. But I would like to understand what is going on here because older kernels will be more trickier to get this upstream backport.

Attention: the upstream 4.4 commit by greg accidently removes the export of the vma_is_stack_for_task function. I already notified him.

(In reply to Vlastimil Babka from comment #10)
> (In reply to Vlastimil Babka from comment #9)
> > Catchpoint 1 (call to syscall mmap2), 0xf7fd9f89 in __kernel_vsyscall ()
> 
> (gdb) bt
> #0  0xf7fd9f89 in __kernel_vsyscall ()
> #1  0xf7454508 in mmap () from /lib/libc.so.6
> #2  0xf7a51cdb in os::commit_memory(char*, unsigned int, bool) () from
> /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so

OK, this is what I found in jdk source
// NOTE: Linux kernel does not really reserve the pages for us.
//       All it does is to check if there are enough free pages
//       left at the time of mmap(). This could be a potential
//       problem.
bool os::commit_memory(char* addr, size_t size, bool exec) {
  int prot = exec ? PROT_READ|PROT_WRITE|PROT_EXEC : PROT_READ|PROT_WRITE;
  uintptr_t res = (uintptr_t) ::mmap(addr, size, prot,
                                   MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0);
  return res != (uintptr_t) MAP_FAILED;

}

which explains it I am afraid. We simply smash a new mapping in the middle of the stack. And so the stack expansion cannot possibly work. :/

(In reply to Michal Hocko from comment #18)
> (In reply to Vlastimil Babka from comment #10)
> > (In reply to Vlastimil Babka from comment #9)
> > > Catchpoint 1 (call to syscall mmap2), 0xf7fd9f89 in __kernel_vsyscall ()
> > 
> > (gdb) bt
> > #0  0xf7fd9f89 in __kernel_vsyscall ()
> > #1  0xf7454508 in mmap () from /lib/libc.so.6
> > #2  0xf7a51cdb in os::commit_memory(char*, unsigned int, bool) () from
> > /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
> 
> OK, this is what I found in jdk source
> // NOTE: Linux kernel does not really reserve the pages for us.
> //       All it does is to check if there are enough free pages
> //       left at the time of mmap(). This could be a potential
> //       problem.

Um, did they hear about MAP_POPULATE?

> bool os::commit_memory(char* addr, size_t size, bool exec) {
>   int prot = exec ? PROT_READ|PROT_WRITE|PROT_EXEC : PROT_READ|PROT_WRITE;
>   uintptr_t res = (uintptr_t) ::mmap(addr, size, prot,
>                                    MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1,
> 0);
>   return res != (uintptr_t) MAP_FAILED;
> 
> }
> 
> which explains it I am afraid. We simply smash a new mapping in the middle
> of the stack. And so the stack expansion cannot possibly work. :/

Yeah, I guess they think they are placing the guards below the stack, that's why there's mmap first and then mprotect (which could be done by single mmap with the right protection flags, but nevermind).

(In reply to Vlastimil Babka from comment #19)
> (In reply to Michal Hocko from comment #18)
> > (In reply to Vlastimil Babka from comment #10)
> > > (In reply to Vlastimil Babka from comment #9)
> > > > Catchpoint 1 (call to syscall mmap2), 0xf7fd9f89 in __kernel_vsyscall ()
> > > 
> > > (gdb) bt
> > > #0  0xf7fd9f89 in __kernel_vsyscall ()
> > > #1  0xf7454508 in mmap () from /lib/libc.so.6
> > > #2  0xf7a51cdb in os::commit_memory(char*, unsigned int, bool) () from
> > > /opt/novell/groupwise/client/java/lib/i386/client/libjvm.so
> > 
> > OK, this is what I found in jdk source
> > // NOTE: Linux kernel does not really reserve the pages for us.
> > //       All it does is to check if there are enough free pages
> > //       left at the time of mmap(). This could be a potential
> > //       problem.
> 
> Um, did they hear about MAP_POPULATE?

I am pretty sure they do not want this if they plan to use really large stacks.

> 
> > bool os::commit_memory(char* addr, size_t size, bool exec) {
> >   int prot = exec ? PROT_READ|PROT_WRITE|PROT_EXEC : PROT_READ|PROT_WRITE;
> >   uintptr_t res = (uintptr_t) ::mmap(addr, size, prot,
> >                                    MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1,
> > 0);
> >   return res != (uintptr_t) MAP_FAILED;
> > 
> > }
> > 
> > which explains it I am afraid. We simply smash a new mapping in the middle
> > of the stack. And so the stack expansion cannot possibly work. :/
> 
> Yeah, I guess they think they are placing the guards below the stack, that's
> why there's mmap first and then mprotect (which could be done by single mmap
> with the right protection flags, but nevermind).

well, they could simply mprotect directly and mmap only if it failed.

Created attachment 729855 [details]
sk.c

From: Solar Designer <solar@openwall.com>

Dear Alexander,
probably it is already known,
otherwise please share it in oss-security@
I've noticed the problem on Red Hat kernels first, and reported to Red Hat already,
but now I've found the same problem on Ubuntu kernels.
It does not affect mainline patch "mm: larger stack guard gap, between vmas"
but seems distributors have used some other incorrect patch (shared in linux-distros@ ??? )

Description of problem:
mmap(MAP_GROUWSDOWN) works incorrectly on Red Hat and Ubuntu kernels with stackguard fix.

We have application that creates stack by using MAP_GROUWSDOWN , provide this area into clone(), 
where it fails on access to mapped area.

Steps to Reproduce:
execute attached reproducer.
It maps 2 pages with MAP_GROUWSDOWN, an access to 2nd page mapped page triggers SIGBUS or SIGSEGV

Actual results:
- access to end of mapped area generated SIGBUS or SIGSEGV
- /proc/<pid>/maps shows incorrect start address for allocated area
please see details below

Expected results:
on previous Ubuntu/RHEL kernels this testcase works well without crashes
http://man7.org/linux/man-pages/man2/mmap.2.html

       MAP_GROWSDOWN
              This flag is used for stacks.  It indicates to the kernel
              virtual memory system that the mapping should extend downward
              in memory.  The return address is one page lower than the
              memory area that is actually created in the process's virtual
              address space.  Touching an address in the "guard" page below
              the mapping will cause the mapping to grow by a page.  This
              growth can be repeated until the mapping grows to within a
              page of the high end of the next lower mapping, at which point
              touching the "guard" page will result in a SIGSEGV signal.

On new Ubuntu kernel 4.4.0-81-generic (with stackguard fix)

20              unsigned char *stack = mmap(NULL, STACK_SIZE, PROT_READ | PROT_WRITE,
(gdb) n

(changes in /proc/<pid>/maps)
 7ffff7dd3000-7ffff7dd7000 rw-p 00000000 00:00 0 
 7ffff7dd7000-7ffff7dfd000 r-xp 00000000 fc:00 524776                     /lib/x86_64-linux-gnu/ld-2.23.so
 7ffff7feb000-7ffff7fee000 rw-p 00000000 00:00 0 
+7ffff80f4000-7ffff7ff6000 rw-p 00000000 00:00 0  <<<< incorrect start address is shown here 
 7ffff7ff6000-7ffff7ff8000 rw-p 00000000 00:00 0 
 7ffff7ff8000-7ffff7ffa000 r--p 00000000 00:00 0                          [vvar]
 7ffff7ffa000-7ffff7ffc000 r-xp 00000000 00:00 0                          [vdso]

23              printf("stack = %p\n", stack);
(gdb) n
stack = 0x7ffff7ff4000
24              end = stack + STACK_SIZE - 8;
(gdb) n
25              printf("end = %p\n", end);
(gdb) n
end = 0x7ffff7ff5ff8
26              printf("write to *end\n");
(gdb) n
write to *end
27              *end = 0;
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x000000000040062f in main () at sk.c:27


on Ubuntu 4.4.0-79-generic  -- works as expected

mmap return address of guard page,
access to end of mapped area works works correctly,
touch on guard page grows stack down,
then touch of previous page grows stack down again.

20              unsigned char *stack = mmap(NULL, STACK_SIZE, PROT_READ | PROT_WRITE,
(gdb) n
23              printf("stack = %p\n", stack);
(gdb) n
stack = 0x7ffff7ff4000

 7ffff7dd3000-7ffff7dd7000 rw-p 00000000 00:00 0 
 7ffff7dd7000-7ffff7dfd000 r-xp 00000000 08:01 27001906                   /lib/x86_64-linux-gnu/ld-2.23.so
 7ffff7fc8000-7ffff7fcb000 rw-p 00000000 00:00 0 
+7ffff7ff5000-7ffff7ff6000 rw-p 00000000 00:00 0 
 7ffff7ff6000-7ffff7ff8000 rw-p 00000000 00:00 0 
 7ffff7ff8000-7ffff7ffa000 r--p 00000000 00:00 0                          [vvar]
 7ffff7ffa000-7ffff7ffc000 r-xp 00000000 00:00 0                          [vdso]

24              end = stack + STACK_SIZE - 8;
(gdb) n
25              printf("end = %p\n", end);
(gdb) n
end = 0x7ffff7ff5ff8
26              printf("write to *end\n");
(gdb) n
write to *end
27              *end = 0;
(gdb) n
28              printf("write to *stack\n");
(gdb) n
write to *stack
29              *(stack) = 0;
(gdb) n

-7ffff7ff5000-7ffff7ff6000 rw-p 00000000 00:00 0 
+7ffff7ff4000-7ffff7ff6000 rw-p 00000000 00:00 0   <<<< Stack grow down

30              printf("write to *(stack-1)\n");
(gdb) n
write to *(stack-1)
31              *(stack-1) = 0;
(gdb) n
32      }

-7ffff7ff4000-7ffff7ff6000 rw-p 00000000 00:00 0 
+7ffff7ff3000-7ffff7ff6000 rw-p 00000000 00:00 0 <<<< Stack grows down again

----- End forwarded message -----

(In reply to Marcus Meissner from comment #22)
> Created attachment 729855 [details]
> sk.c
> 
> From: Solar Designer <solar@openwall.com>
> 
> Dear Alexander,
> probably it is already known,
> otherwise please share it in oss-security@
> I've noticed the problem on Red Hat kernels first, and reported to Red Hat
> already,
> but now I've found the same problem on Ubuntu kernels.
> It does not affect mainline patch "mm: larger stack guard gap, between vmas"
> but seems distributors have used some other incorrect patch (shared in
> linux-distros@ ??? )
> 
> Description of problem:
> mmap(MAP_GROUWSDOWN) works incorrectly on Red Hat and Ubuntu kernels with
> stackguard fix.
> 
> We have application that creates stack by using MAP_GROUWSDOWN , provide
> this area into clone(), 
> where it fails on access to mapped area.

This is a different problem unrelated to this bug. In fact I would argue that we have never supported/implemented MAP_GROUWSDOWN correctly. There is only one stack that can work reliably because we place it above any mmaps or grow mmaps from lower addresses. A larger gap just makes it more obvious.

Feel free to open a separate bug for this but I would tend to close it as WONTFIX.

FYI, I submitted to openSUSE Leap 42.2 kernel update now.  SR#505760.

*** Bug 1045406 has been marked as a duplicate of this bug. ***

This is an autogenerated message for OBS integration:
This bug (1045340) was mentioned in
https://build.opensuse.org/request/show/505760 42.2 / kernel-source

Fixed for groupwise on openSUSE Leap 42.2 in kernel-default-4.4.73-18.15.1.x86_64 submitted into maintenance earlier.

http://download.opensuse.org/repositories/openSUSE:/Maintenance:/6922/openSUSE_Leap_42.2_Update/
http://download.opensuse.org/update/leap/42.2-test/

*** Bug 1045660 has been marked as a duplicate of this bug. ***

This is an autogenerated message for OBS integration:
This bug (1045340) was mentioned in
https://build.opensuse.org/request/show/505992 42.2 / kernel-source

An update workflow for this issue was started.
This issue was rated as important.
Please submit fixed packages until 2017-07-04.
When done, reassign the bug to security-team@suse.de.
https://swamp.suse.de/webswamp/wf/63702

CATIA license server is affected too:

# uname -a
Linux lisa 4.4.72-18.12-default #1 SMP Mon Jun 19 14:11:41 UTC 2017 (9c03296) x86_64 x86_64 x86_64 GNU/Linux
# /usr/DassaultSystemes/DSLicenseServer/linux_a64/code/bin/DSLicSrv -startServer
Segmentation fault (core dumped)
# gdb /usr/DassaultSystemes/DSLicenseServer/linux_a64/code/bin/DSLicSrv
[...]
(gdb) run -startServer
Starting program: /usr/DassaultSystemes/DSLicenseServer/linux_a64/code/bin/DSLicSrv -startServer
[...]
Missing separate debuginfo for /usr/DassaultSystemes/DSLicenseServer/linux_a64/code/bin/../../startup/DSLSJRE/lib/amd64
/server/libjvm.so
[...]
Program received signal SIGSEGV, Segmentation fault.
0x00007f807a96f2b4 in ?? ()
Missing separate debuginfos, use: zypper install libgcc_s1-debuginfo-6.2.1+r239768-5.5.2.x86_64 libstdc++6-debuginfo-6.
2.1+r239768-5.5.2.x86_64
(gdb) bt
#0  0x00007f807a96f2b4 in ?? ()
#1  0x0000000000000246 in ?? ()
#2  0x00007f807a96f160 in ?? ()
#3  0x00007f808b36e370 in VM_Operation::_names ()
   from /usr/DassaultSystemes/DSLicenseServer/linux_a64/code/bin/../../startup/DSLSJRE/lib/amd64/server/libjvm.so
#4  0x00007ffd120ca140 in ?? ()
#5  0x00007f808aea52cd in VM_Version::get_processor_features() ()
   from /usr/DassaultSystemes/DSLicenseServer/linux_a64/code/bin/../../startup/DSLSJRE/lib/amd64/server/libjvm.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

42.2 kernel just released

SUSE-SU-2017:1696-1: An update that contains security fixes can now be installed.

Category: security (important)
Bug References: 1045340,1045406
CVE References: 
Sources used:
SUSE Linux Enterprise Software Development Kit 11-SP4 (src):    kernel-docs-3.0.101-107.3
SUSE Linux Enterprise Server 11-SP4 (src):    kernel-bigmem-3.0.101-107.1, kernel-default-3.0.101-107.1, kernel-ec2-3.0.101-107.1, kernel-pae-3.0.101-107.1, kernel-ppc64-3.0.101-107.1, kernel-source-3.0.101-107.1, kernel-syms-3.0.101-107.1, kernel-trace-3.0.101-107.1, kernel-xen-3.0.101-107.1
SUSE Linux Enterprise Server 11-EXTRA (src):    kernel-default-3.0.101-107.1, kernel-pae-3.0.101-107.1, kernel-ppc64-3.0.101-107.1, kernel-trace-3.0.101-107.1, kernel-xen-3.0.101-107.1
SUSE Linux Enterprise Debuginfo 11-SP4 (src):    kernel-bigmem-3.0.101-107.1, kernel-default-3.0.101-107.1, kernel-ec2-3.0.101-107.1, kernel-pae-3.0.101-107.1, kernel-ppc64-3.0.101-107.1, kernel-trace-3.0.101-107.1, kernel-xen-3.0.101-107.1

SUSE-SU-2017:1704-1: An update that contains security fixes can now be installed.

Category: security (important)
Bug References: 1045340
CVE References: 
Sources used:
SUSE OpenStack Cloud 6 (src):    kernel-default-3.12.74-60.64.48.1, kernel-source-3.12.74-60.64.48.1, kernel-syms-3.12.74-60.64.48.1, kernel-xen-3.12.74-60.64.48.1, kgraft-patch-SLE12-SP1_Update_17-1-2.1
SUSE Linux Enterprise Server for SAP 12-SP1 (src):    kernel-default-3.12.74-60.64.48.1, kernel-source-3.12.74-60.64.48.1, kernel-syms-3.12.74-60.64.48.1, kernel-xen-3.12.74-60.64.48.1, kgraft-patch-SLE12-SP1_Update_17-1-2.1
SUSE Linux Enterprise Server 12-SP1-LTSS (src):    kernel-default-3.12.74-60.64.48.1, kernel-source-3.12.74-60.64.48.1, kernel-syms-3.12.74-60.64.48.1, kernel-xen-3.12.74-60.64.48.1, kgraft-patch-SLE12-SP1_Update_17-1-2.1
SUSE Linux Enterprise Module for Public Cloud 12 (src):    kernel-ec2-3.12.74-60.64.48.1

SUSE-SU-2017:1706-1: An update that contains security fixes can now be installed.

Category: security (important)
Bug References: 1045340,1045406
CVE References: 
Sources used:
SUSE Linux Enterprise Server 11-SP3-LTSS (src):    kernel-bigsmp-3.0.101-0.47.105.1, kernel-default-3.0.101-0.47.105.1, kernel-ec2-3.0.101-0.47.105.1, kernel-pae-3.0.101-0.47.105.1, kernel-source-3.0.101-0.47.105.1, kernel-syms-3.0.101-0.47.105.1, kernel-trace-3.0.101-0.47.105.1, kernel-xen-3.0.101-0.47.105.1
SUSE Linux Enterprise Server 11-EXTRA (src):    kernel-bigsmp-3.0.101-0.47.105.1, kernel-default-3.0.101-0.47.105.1, kernel-pae-3.0.101-0.47.105.1, kernel-ppc64-3.0.101-0.47.105.1, kernel-trace-3.0.101-0.47.105.1, kernel-xen-3.0.101-0.47.105.1
SUSE Linux Enterprise Point of Sale 11-SP3 (src):    kernel-default-3.0.101-0.47.105.1, kernel-ec2-3.0.101-0.47.105.1, kernel-pae-3.0.101-0.47.105.1, kernel-source-3.0.101-0.47.105.1, kernel-syms-3.0.101-0.47.105.1, kernel-trace-3.0.101-0.47.105.1, kernel-xen-3.0.101-0.47.105.1
SUSE Linux Enterprise Debuginfo 11-SP3 (src):    kernel-bigsmp-3.0.101-0.47.105.1, kernel-default-3.0.101-0.47.105.1, kernel-ec2-3.0.101-0.47.105.1, kernel-pae-3.0.101-0.47.105.1, kernel-trace-3.0.101-0.47.105.1, kernel-xen-3.0.101-0.47.105.1

SUSE-SU-2017:1707-1: An update that contains security fixes can now be installed.

Category: security (important)
Bug References: 1045340
CVE References: 
Sources used:
SUSE Linux Enterprise Workstation Extension 12-SP2 (src):    kernel-default-4.4.59-92.24.2
SUSE Linux Enterprise Software Development Kit 12-SP2 (src):    kernel-docs-4.4.59-92.24.5, kernel-obs-build-4.4.59-92.24.2
SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src):    kernel-default-4.4.59-92.24.2, kernel-source-4.4.59-92.24.2, kernel-syms-4.4.59-92.24.2
SUSE Linux Enterprise Server 12-SP2 (src):    kernel-default-4.4.59-92.24.2, kernel-source-4.4.59-92.24.2, kernel-syms-4.4.59-92.24.2
SUSE Linux Enterprise Live Patching 12 (src):    kgraft-patch-SLE12-SP2_Update_9-1-2.3
SUSE Linux Enterprise High Availability 12-SP2 (src):    kernel-default-4.4.59-92.24.2
SUSE Linux Enterprise Desktop 12-SP2 (src):    kernel-default-4.4.59-92.24.2, kernel-source-4.4.59-92.24.2, kernel-syms-4.4.59-92.24.2
OpenStack Cloud Magnum Orchestration 7 (src):    kernel-default-4.4.59-92.24.2

SUSE-SU-2017:1735-1: An update that contains security fixes can now be installed.

Category: security (important)
Bug References: 1045340
CVE References: 
Sources used:
SUSE Linux Enterprise Server for SAP 12 (src):    kernel-default-3.12.61-52.80.1, kernel-source-3.12.61-52.80.1, kernel-syms-3.12.61-52.80.1, kernel-xen-3.12.61-52.80.1, kgraft-patch-SLE12_Update_23-1-2.1
SUSE Linux Enterprise Server 12-LTSS (src):    kernel-default-3.12.61-52.80.1, kernel-source-3.12.61-52.80.1, kernel-syms-3.12.61-52.80.1, kernel-xen-3.12.61-52.80.1, kgraft-patch-SLE12_Update_23-1-2.1
SUSE Linux Enterprise Module for Public Cloud 12 (src):    kernel-ec2-3.12.61-52.80.1

SUSE-SU-2017:1903-1: An update that solves one vulnerability and has three fixes is now available.

Category: security (important)
Bug References: 1039348,1039496,1045340,1045406
CVE References: CVE-2017-1000364
Sources used:
SUSE Linux Enterprise Live Patching 12 (src):    kgraft-patch-SLE12-SP2_Update_8-2-2.1

SUSE-SU-2017:1912-1: An update that solves one vulnerability and has three fixes is now available.

Category: security (important)
Bug References: 1039348,1039496,1045340,1045406
CVE References: CVE-2017-1000364
Sources used:
SUSE Linux Enterprise Server for SAP 12 (src):    kgraft-patch-SLE12_Update_22-2-2.1
SUSE Linux Enterprise Server 12-LTSS (src):    kgraft-patch-SLE12_Update_22-2-2.1

SUSE-SU-2017:1915-1: An update that solves one vulnerability and has three fixes is now available.

Category: security (important)
Bug References: 1039348,1039496,1045340,1045406
CVE References: CVE-2017-1000364
Sources used:
SUSE Linux Enterprise Server for SAP 12-SP1 (src):    kgraft-patch-SLE12-SP1_Update_16-2-2.1
SUSE Linux Enterprise Server 12-SP1-LTSS (src):    kgraft-patch-SLE12-SP1_Update_16-2-2.1

SUSE-SU-2017:1990-1: An update that solves 43 vulnerabilities and has 282 fixes is now available.

Category: security (important)
Bug References: 1000092,1003077,1003581,1004003,1007729,1007959,1007962,1008842,1009674,1009718,1010032,1010612,1010690,1011044,1011176,1011913,1012060,1012382,1012422,1012452,1012829,1012910,1012985,1013001,1013561,1013792,1013887,1013994,1014120,1014136,1015342,1015367,1015452,1015609,1016403,1017164,1017170,1017410,1017461,1017641,1018100,1018263,1018358,1018385,1018419,1018446,1018813,1018885,1018913,1019061,1019148,1019163,1019168,1019260,1019351,1019594,1019614,1019618,1019630,1019631,1019784,1019851,1020048,1020214,1020412,1020488,1020602,1020685,1020817,1020945,1020975,1021082,1021248,1021251,1021258,1021260,1021294,1021424,1021455,1021474,1021762,1022181,1022266,1022304,1022340,1022429,1022476,1022547,1022559,1022595,1022785,1022971,1023101,1023175,1023287,1023762,1023866,1023884,1023888,1024015,1024081,1024234,1024508,1024938,1025039,1025235,1025461,1025683,1026024,1026405,1026462,1026505,1026509,1026570,1026692,1026722,1027054,1027066,1027101,1027153,1027179,1027189,1027190,1027195,1027273,1027512,1027565,1027616,1027974,1028017,1028027,1028041,1028158,1028217,1028310,1028325,1028340,1028372,1028415,1028819,1028883,1028895,1029220,1029514,1029607,1029634,1029986,1030057,1030070,1030118,1030213,1030573,1031003,1031040,1031052,1031142,1031147,1031200,1031206,1031208,1031440,1031470,1031500,1031512,1031555,1031579,1031662,1031717,1031796,1031831,1032006,1032141,1032339,1032345,1032400,1032581,1032673,1032681,1032803,1033117,1033281,1033287,1033336,1033340,1033885,1034048,1034419,1034635,1034670,1034671,1034762,1034902,1034995,1035024,1035866,1035887,1035920,1035922,1036214,1036638,1036752,1036763,1037177,1037186,1037384,1037483,1037669,1037840,1037871,1037969,1038033,1038043,1038085,1038142,1038143,1038297,1038458,1038544,1038842,1038843,1038846,1038847,1038848,1038879,1038981,1038982,1039348,1039354,1039700,1039864,1039882,1039883,1039885,1039900,1040069,1040125,1040182,1040279,1040351,1040364,1040395,1040425,1040463,1040567,1040609,1040855,1040929,1040941,1041087,1041160,1041168,1041242,1041431,1041810,1042200,1042286,1042356,1042421,1042517,1042535,1042536,1042863,1042886,1043014,1043231,1043236,1043347,1043371,1043467,1043488,1043598,1043912,1043935,1043990,1044015,1044082,1044120,1044125,1044532,1044767,1044772,1044854,1044880,1044912,1045154,1045235,1045286,1045307,1045340,1045467,1045568,1046105,1046434,1046589,799133,863764,870618,922871,951844,966170,966172,966191,966321,966339,968697,969479,969755,970083,971975,982783,985561,986362,986365,987192,987576,988065,989056,989311,990058,990682,991273,993832,995542,995968,998106
CVE References: CVE-2016-10200,CVE-2016-2117,CVE-2016-4997,CVE-2016-4998,CVE-2016-7117,CVE-2016-9191,CVE-2017-1000364,CVE-2017-1000365,CVE-2017-1000380,CVE-2017-2583,CVE-2017-2584,CVE-2017-2596,CVE-2017-2636,CVE-2017-2671,CVE-2017-5551,CVE-2017-5576,CVE-2017-5577,CVE-2017-5897,CVE-2017-5970,CVE-2017-5986,CVE-2017-6074,CVE-2017-6214,CVE-2017-6345,CVE-2017-6346,CVE-2017-6347,CVE-2017-6353,CVE-2017-7184,CVE-2017-7187,CVE-2017-7261,CVE-2017-7294,CVE-2017-7308,CVE-2017-7346,CVE-2017-7374,CVE-2017-7487,CVE-2017-7616,CVE-2017-7618,CVE-2017-8890,CVE-2017-9074,CVE-2017-9075,CVE-2017-9076,CVE-2017-9077,CVE-2017-9150,CVE-2017-9242
Sources used:
SUSE Linux Enterprise Real Time Extension 12-SP2 (src):    kernel-rt-4.4.74-7.10.1, kernel-rt_debug-4.4.74-7.10.1, kernel-source-rt-4.4.74-7.10.1, kernel-syms-rt-4.4.74-7.10.1

Created attachment 735041 [details]
Reproducer.

I think that I am still seeing a bug (on ia32 but not ia64); I suspect that it is causing the libreoffice unit tests to fail on IBS. I'm testing with 4.11.8-2 on Tumbleweed, but I see the same with 4.4.76-1 on Leap 42.3. I'm attaching a reproducer that attempts to simulate the crash I'm getting running the libreoffice unit tests locally. Before I upgraded the kernel on that machine, it had v4.7.3, and the reproducer did not crash.

Created attachment 735042 [details]
Backtrace.

Crashes when trying to write to a pointer returned by alloca.

Created attachment 735044 [details]
strace log

(In reply to Michael Gorse from comment #47)
> Created attachment 735042 [details]
> Backtrace.
> 
> Crashes when trying to write to a pointer returned by alloca.

Could you please paste /proc/pid/maps of the crashing process? Anyway we know that Java plays tricks with its own stack guard area. That should be fixed with the latest maint. update. There was another report about LO crashing on 32b
http://lkml.kernel.org/r/1499126133.2707.20.camel%40decadent.org.uk
with more explanation here http://lkml.kernel.org/r/1499209315.2707.29.camel@decadent.org.uk

Your test program does -Xss1150k which increases the default stack size which should be 1MB on x86_64 (as per man page). Does the same happen with the default stack setup? What if you increase RLIMIT_STACK?

Created attachment 735134 [details]
maps

Thanks. Yes, looks similar to the crash described in that post.


If I do not set -Xss, then I do not get a crash on startup (I'd set it in an attempt to avoid the crash, but in my case it causes one at startup).

Ulimit -s is set to 8192 for me. I tried setting it to 65536, but it doesn't make a difference.

Do you know if tw should have the java update with the stack fixes? I can reproduce the same crash with 1.8 or 9.

(In reply to Michael Gorse from comment #50)
> Created attachment 735134 [details]
> maps
> 
> Thanks. Yes, looks similar to the crash described in that post.


bfedc000-bfedd000 rwxp 00000000 00:00 0 
bffdf000-c0000000 rw-p 00000000 00:00 0          [stack]

yes, the stupid RWX (exec shield) mapping right under the stack.
 
> If I do not set -Xss, then I do not get a crash on startup (I'd set it in an
> attempt to avoid the crash, but in my case it causes one at startup).
> 
> Ulimit -s is set to 8192 for me. I tried setting it to 65536, but it doesn't
> make a difference.

This is interesting because I thought that the exec shield mapping is placed based on the RLIMIT somehow.
 
> Do you know if tw should have the java update with the stack fixes? I can
> reproduce the same crash with 1.8 or 9.

I am not even sure there is any bug report for java...

I'm still reading over that thread, but I wonder if it would be safe to disable that function call in openjdk--it appears to have been added as a work-around for some other bug.

(In reply to Michael Gorse from comment #52)
> I'm still reading over that thread, but I wonder if it would be safe to
> disable that function call in openjdk--it appears to have been added as a
> work-around for some other bug.

yes for a feature which is long gone AFAIR. Please open a bug for java.

Fyi, I have an OpenJDK 1.7 build with the Access Shield workaround patched out in my SUSE:SLE-12:Update branch on ibs, and now the libreoffice unit tests pass again.
Filed https://bugzilla.opensuse.org/show_bug.cgi?id=1052318 for java.

SUSE-SU-2017:2342-1: An update that solves 44 vulnerabilities and has 135 fixes is now available.

Category: security (important)
Bug References: 1003077,1005651,1008374,1008850,1008893,1012422,1013018,1013070,1013800,1013862,1016489,1017143,1018074,1018263,1018446,1019168,1020229,1021256,1021913,1022971,1023014,1023051,1023163,1023888,1024508,1024788,1024938,1025235,1025702,1026024,1026260,1026722,1026914,1027066,1027101,1027178,1027565,1028372,1028415,1028880,1029140,1029212,1029770,1029850,1030213,1030552,1030573,1030593,1030814,1031003,1031052,1031440,1031579,1032141,1032340,1032471,1033287,1033336,1033771,1033794,1033804,1033816,1034026,1034670,1035576,1035777,1035920,1036056,1036288,1036629,1037182,1037183,1037191,1037193,1037227,1037232,1037233,1037356,1037358,1037359,1037441,1038544,1038879,1038981,1038982,1039258,1039348,1039354,1039456,1039594,1039882,1039883,1039885,1040069,1040351,1041160,1041431,1041762,1041975,1042045,1042200,1042615,1042633,1042687,1042832,1043014,1043234,1043935,1044015,1044125,1044216,1044230,1044854,1044882,1044913,1044985,1045154,1045340,1045356,1045406,1045416,1045525,1045538,1045547,1045615,1046107,1046122,1046192,1046715,1047027,1047053,1047343,1047354,1047487,1047523,1047653,1048185,1048221,1048232,1048275,1049483,1049603,1049688,1049882,1050154,1050431,1051478,1051515,1051770,784815,792863,799133,870618,909486,909618,911105,919382,928138,931620,938352,943786,948562,962257,970956,971975,972891,979021,982783,983212,985561,986362,986365,986924,988065,989056,990682,991651,995542,999245
CVE References: CVE-2014-9922,CVE-2015-3288,CVE-2015-8970,CVE-2016-10200,CVE-2016-2188,CVE-2016-4997,CVE-2016-4998,CVE-2016-5243,CVE-2016-7117,CVE-2017-1000363,CVE-2017-1000364,CVE-2017-1000365,CVE-2017-1000380,CVE-2017-11176,CVE-2017-11473,CVE-2017-2636,CVE-2017-2647,CVE-2017-2671,CVE-2017-5669,CVE-2017-5970,CVE-2017-5986,CVE-2017-6074,CVE-2017-6214,CVE-2017-6348,CVE-2017-6353,CVE-2017-6951,CVE-2017-7184,CVE-2017-7187,CVE-2017-7261,CVE-2017-7294,CVE-2017-7308,CVE-2017-7482,CVE-2017-7487,CVE-2017-7533,CVE-2017-7542,CVE-2017-7616,CVE-2017-8890,CVE-2017-8924,CVE-2017-8925,CVE-2017-9074,CVE-2017-9075,CVE-2017-9076,CVE-2017-9077,CVE-2017-9242
Sources used:
SUSE Linux Enterprise Real Time Extension 11-SP4 (src):    kernel-rt-3.0.101.rt130-69.5.1, kernel-rt_trace-3.0.101.rt130-69.5.1, kernel-source-rt-3.0.101.rt130-69.5.1, kernel-syms-rt-3.0.101.rt130-69.5.1
SUSE Linux Enterprise Debuginfo 11-SP4 (src):    kernel-rt-3.0.101.rt130-69.5.1, kernel-rt_debug-3.0.101.rt130-69.5.1, kernel-rt_trace-3.0.101.rt130-69.5.1

This is automated batch bugzilla cleanup.

The openSUSE 42.2 changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE, or you can still observe it under openSUSE Leap 15.0, please
feel free to reopen this bug against that version (see the "Version"
component in the bug fields), or alternatively open
a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime