Bug#816077: ruby2.3: FTBFS on m68k - Segmentation fault at 0x5f583332

2016-03-28 Thread Christian Hofstaedtler
* Geert Uytterhoeven  [160328 10:33]:
> > I really don't want to add another patch except for critical issues
> > (and that are likely to be applied to 2.3) at this point - so ... No.
> 
> "tail call overwriting the (non-existing) argument" sounds like a security
> issue that may be exploitable, even on non-m68k.

If you think this is a security issue, please talk to upstream
and/or security@ to get a CVE assigned, so this is fixed not just in
Debian.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



Bug#816077: ruby2.3: FTBFS on m68k - Segmentation fault at 0x5f583332

2016-03-28 Thread Andreas Schwab
Geert Uytterhoeven  writes:

> "tail call overwriting the (non-existing) argument" sounds like a security
> issue that may be exploitable, even on non-m68k.

It's only a problem if the argument is passed on the stack.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



Bug#816077: ruby2.3: FTBFS on m68k - Segmentation fault at 0x5f583332

2016-03-28 Thread John Paul Adrian Glaubitz
On 03/28/2016 01:18 AM, Christian Hofstaedtler wrote:
>> The PTS says "LowNMU" for ruby2.3 which clearly means "Do an NMU without
>> asking if you want to fix something" [1]. If that's not what you want,
>> don't use that tag.
> 
> You're mistaken. The "tag" is per-maintainer, and you need to look
> up the exact policy the maintainer has expressed on the wiki page
> you've linked to.

Then this needs to be fixed. Having "LowNMU" on the PTS page of a
package which is *not* LowNMU is highly misleading.

But as Geert said, this might even be a security issue.

Cheers,

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Bug#816077: ruby2.3: FTBFS on m68k - Segmentation fault at 0x5f583332

2016-03-28 Thread Geert Uytterhoeven
On Mon, Mar 28, 2016 at 1:08 AM, Christian Hofstaedtler  wrote:
> * John Paul Adrian Glaubitz  [160327 23:00]:
>> Here's an updated patch which contains the actual changes that upstream
>> committed to the git repository to close the upstream bug 12118 [1].
>>
>> Would be possible to cherry-pick this fix from upstream until the
>> changes have been backported to ruby2.3?
>
> We're waiting for a whole list of more important issues to be
> backported to the 2.3 branch (there haven't been any backports or
> point releases so far).
>
> I really don't want to add another patch except for critical issues
> (and that are likely to be applied to 2.3) at this point - so ... No.

"tail call overwriting the (non-existing) argument" sounds like a security
issue that may be exploitable, even on non-m68k.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds



Bug#816077: ruby2.3: FTBFS on m68k - Segmentation fault at 0x5f583332

2016-03-27 Thread John Paul Adrian Glaubitz
On 03/28/2016 01:08 AM, Christian Hofstaedtler wrote:
> We're waiting for a whole list of more important issues to be
> backported to the 2.3 branch (there haven't been any backports or
> point releases so far).

That's ok.

> I really don't want to add another patch except for critical issues
> (and that are likely to be applied to 2.3) at this point - so ... No.
> 
> Please pursuade upstream into backporting this.

I already did.

>> I'd be happy to perform
>> an NMU as well to fix the issue. I assume that should be okay since
>> ruby2,3 is LowNMU?
> 
> You're misreading what the PTS says and what the actual case is.

The PTS says "LowNMU" for ruby2.3 which clearly means "Do an NMU without
asking if you want to fix something" [1]. If that's not what you want,
don't use that tag.

Adrian

> [1] https://wiki.debian.org/LowThresholdNmu

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Bug#816077: ruby2.3: FTBFS on m68k - Segmentation fault at 0x5f583332

2016-03-27 Thread Christian Hofstaedtler
* John Paul Adrian Glaubitz  [160328 01:16]:
> >> I'd be happy to perform
> >> an NMU as well to fix the issue. I assume that should be okay since
> >> ruby2,3 is LowNMU?
> > 
> > You're misreading what the PTS says and what the actual case is.
> 
> The PTS says "LowNMU" for ruby2.3 which clearly means "Do an NMU without
> asking if you want to fix something" [1]. If that's not what you want,
> don't use that tag.

You're mistaken. The "tag" is per-maintainer, and you need to look
up the exact policy the maintainer has expressed on the wiki page
you've linked to.

> > [1] https://wiki.debian.org/LowThresholdNmu

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



Bug#816077: ruby2.3: FTBFS on m68k - Segmentation fault at 0x5f583332

2016-03-27 Thread Christian Hofstaedtler
* John Paul Adrian Glaubitz  [160327 23:00]:
> Here's an updated patch which contains the actual changes that upstream
> committed to the git repository to close the upstream bug 12118 [1].
> 
> Would be possible to cherry-pick this fix from upstream until the
> changes have been backported to ruby2.3?

We're waiting for a whole list of more important issues to be
backported to the 2.3 branch (there haven't been any backports or
point releases so far).

I really don't want to add another patch except for critical issues
(and that are likely to be applied to 2.3) at this point - so ... No.

Please pursuade upstream into backporting this.

> I'd be happy to perform
> an NMU as well to fix the issue. I assume that should be okay since
> ruby2,3 is LowNMU?

You're misreading what the PTS says and what the actual case is.

> Attaching the updated and cleaned up patch in any case.

Thanks.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



Bug#816077: ruby2.3: FTBFS on m68k - Segmentation fault at 0x5f583332

2016-03-27 Thread John Paul Adrian Glaubitz
Hi!

Here's an updated patch which contains the actual changes that upstream
committed to the git repository to close the upstream bug 12118 [1].

Would be possible to cherry-pick this fix from upstream until the
changes have been backported to ruby2.3? I'd be happy to perform
an NMU as well to fix the issue. I assume that should be okay since
ruby2,3 is LowNMU?

Attaching the updated and cleaned up patch in any case.

Adrian

> [1] https://bugs.ruby-lang.org/issues/12118

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Cherry-picked updates for upstream bug 12118
 Upstream has improved the stack allocator and fixed the function
 prototype for rb_locale_charmap_index in localeinit.c. Both changes
 are necessary to fix the build on m68k.
 Upstream bug: https://bugs.ruby-lang.org/issues/12118
 Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816077
 .

--- ruby2.3-2.3.0.orig/localeinit.c
+++ ruby2.3-2.3.0/localeinit.c
@@ -89,7 +89,7 @@ enc_find_index(const char *name)
 }
 
 int
-rb_locale_charmap_index(VALUE klass)
+rb_locale_charmap_index(void)
 {
 return (int)locale_charmap(enc_find_index);
 }
--- ruby2.3-2.3.0.orig/thread_pthread.c
+++ ruby2.3-2.3.0/thread_pthread.c
@@ -690,17 +690,31 @@ reserve_stack(volatile char *limit, size
const volatile char *end = buf + sizeof(buf);
limit += size;
if (limit > end) {
-   size = limit - end;
-   limit = alloca(size);
-   limit[stack_check_margin+size-1] = 0;
+   /* |<-bottom (=limit(a)) top->|
+* | .. |<-buf 256B |<-end  | stack check |
+* |  256B  |  =size=   | margin (4KB)|
+* |  =size= limit(b)->|  256B  | |
+* ||   alloca(sz) || |
+* | .. |<-buf  |<-limit(c)[sz-1]->0>   | |
+*/
+   size_t sz = limit - end;
+   limit = alloca(sz);
+   limit[sz-1] = 0;
}
 }
 else {
limit -= size;
if (buf > limit) {
-   limit = alloca(buf - limit);
-   limit[0] = 0; /* ensure alloca is called */
-   limit -= stack_check_margin;
+   /* |<-top (=limit(a)) bottom->|
+* | .. | 256B buf->|   | stack check |
+* |  256B  |  =size=   | margin (4KB)|
+* |  =size= limit(b)->|  256B  | |
+* ||   alloca(sz) || |
+* | .. |  buf->|   limit(c)-><0>   | |
+*/
+   size_t sz = buf - limit;
+   limit = alloca(sz);
+   limit[0] = 0;
}
 }
 }


Bug#816077: ruby2.3: FTBFS on m68k - Segmentation fault at 0x5f583332

2016-03-25 Thread John Paul Adrian Glaubitz
Control: tags -1 +patch
Control: forwarded -1 https://bugs.ruby-lang.org/issues/12118

Hi!

Andreas Schwab just provided an updated patch which actually fixes the
problem, I was now able to build ruby2.3 successfully on m68k. Attaching
the patch.

Upstream has also implemented some changes to address the issue [1] but
I haven't tested the upstream changes yet.

Adrian

> [1] https://bugs.ruby-lang.org/issues/12118

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Index: ruby-2.3.0/localeinit.c
===
--- ruby-2.3.0.orig/localeinit.c
+++ ruby-2.3.0/localeinit.c
@@ -89,7 +89,7 @@ enc_find_index(const char *name)
 }
 
 int
-rb_locale_charmap_index(VALUE klass)
+rb_locale_charmap_index(void)
 {
 return (int)locale_charmap(enc_find_index);
 }
Index: ruby-2.3.0/thread_pthread.c
===
--- ruby-2.3.0.orig/thread_pthread.c
+++ ruby-2.3.0/thread_pthread.c
@@ -691,16 +691,15 @@ reserve_stack(volatile char *limit, size
 	limit += size;
 	if (limit > end) {
 	size = limit - end;
-	limit = alloca(size);
+	limit = alloca(stack_check_margin+size);
 	limit[stack_check_margin+size-1] = 0;
 	}
 }
 else {
 	limit -= size;
 	if (buf > limit) {
-	limit = alloca(buf - limit);
+	limit = alloca(buf - limit + stack_check_margin);
 	limit[0] = 0; /* ensure alloca is called */
-	limit -= stack_check_margin;
 	}
 }
 }



Bug#816077: ruby2.3: FTBFS on m68k - Segmentation fault at 0x5f583332

2016-02-27 Thread John Paul Adrian Glaubitz
On 02/27/2016 09:52 AM, John Paul Adrian Glaubitz wrote:
> I rememeber we had a similar issue on ruby2.2, so it might be possbible that
> the patch suggested by Andreas Schwab back then [2] might help.

Ok, this patch doesn't help for ruby2.3. The problem still persists. So,
apparently, this is a different issue.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Bug#816077: ruby2.3: FTBFS on m68k - Segmentation fault at 0x5f583332

2016-02-27 Thread John Paul Adrian Glaubitz
Source: ruby2.3
Version: 2.3.0-2
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

ruby2.3 currently fails to build from source with a segmentation fault late
in the build process while running 'make install' [1]:

./miniruby -I./lib -I. -I.ext/common  ./tool/runruby.rb --extout=.ext  -- 
--disable-gems -r./m68k-linux-gnu-fake ./tool/rbinstall.rb 
--make="/usr/bin/make" --dest-dir="/<>/debian/tmp" --extout=".ext" 
--mflags="-w" --make-flags="w -- DESTDIR=/<>/debian/tmp" 
--data-mode=0644 --prog-mode=0755 --installed-list .installed.list 
--mantype="doc"
installing binary commands:   /usr/bin
/<>/lib/fileutils.rb:250: [BUG] Segmentation fault at 0x5f583332
ruby 2.3.0p0 (2015-12-25) [m68k-linux-gnu]

I rememeber we had a similar issue on ruby2.2, so it might be possbible that
the patch suggested by Andreas Schwab back then [2] might help.

Anyone wants to have a look?

Adrian

> [1] https://people.debian.org/~glaubitz/ruby2.3_2.3.0-2_m68k-20160226-1719
> [2] https://lists.debian.org/debian-68k/2015/11/msg00057.html