Processed: your mail
Processing commands for cont...@bugs.debian.org: > tags 709992 + patch Bug #709992 [src:eglibc] eglibc: FTBFS: Assembler messages: Error: bad register expression Ignoring request to alter tags of bug #709992 to the same tags previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 709992: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709992 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.137227028123402.transcr...@bugs.debian.org
Processed: tagging 709992
Processing commands for cont...@bugs.debian.org: > tags 709992 + patch Bug #709992 [src:eglibc] eglibc: FTBFS: Assembler messages: Error: bad register expression Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 709992: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709992 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.137227013122734.transcr...@bugs.debian.org
Bug#714219: libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
Package: libc6
Version: 2.17-6
Severity: important
Hi,
GNU libc6 in sid is breaking GNU CVS; some operations can
cause a segfault. I’ve tracked it down to:
tglase@tglase:~ $ cat x.c
#define _GNU_SOURCE
#include
#include
#include
#include
void tst(const char *, const char *);
void tst(const char *x, const char *y) {
const char *z;
int e;
z = crypt(x, y);
e = errno;
printf("tst(\"%s\", \"%s\")\n -> %p %s\n -> %s\n",
x, y, z, z?z:"(null)", z?"(ok)":strerror(e));
}
int main(void) {
tst("foo", "xy7k69x/M/s7g");
tst("bar", "xy7k69x/M/s7g");
tst(" ", "%qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d");
return (0);
}
tglase@tglase:~ $ gcc -O2 -o x x.c -lcrypt
tglase@tglase:~ $ ./x
tst("foo", "xy7k69x/M/s7g")
-> 0xf77b7140 xy7k69x/M/s7g
-> (ok)
tst("bar", "xy7k69x/M/s7g")
-> 0xf77b7140 xy5FOaP3Hea0k
-> (ok)
tst(" ", "%qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d")
-> (nil) (null)
-> Invalid argument
tglase@tglase:~ $ scp x ${wheezysystem}:
x
100% 5707 5.6KB/s 00:00
tglase@tglase:~ $ ssh ${wheezysystem} ./x
tst("foo", "xy7k69x/M/s7g")
-> 0xb7742140 xy7k69x/M/s7g
-> (ok)
tst("bar", "xy7k69x/M/s7g")
-> 0xb7742140 xy5FOaP3Hea0k
-> (ok)
tst(" ", "%qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d")
-> 0xb7742140 %q7LLO/mNILqg
-> (ok)
POSIX says crypt(3) only fails with ENOSYS if it’s not supported
at all, but then it’d fail consistently:
ERRORS
The crypt() function shall fail if:
[ENOSYS]
The functionality is not supported on this implementation.
POSIX then goes on to use crypt() just like GNU CVS does:
if (strcmp(p->pw_passwd, crypt(oldpasswd, p->pw_passwd)) == 0) {
Other implementations (like BSD) also strongly suggest that,
unless a different algorithm is selected ($1$, $2a$, etc.)
DES is used, which the above example clearly states is supported,
and overlong salts are just cut off / their trail end ignored.
23:51⎜ in musl, we return "*" on error
If this is an error at all… on wheezy it was none, and BSD agrees:
tg@blau:~ $ uname -a; ./x
MirBSD blau.mirbsd.org 10 Kv#10uB2-20130517 GENERIC#1405 i386
tst("foo", "xy7k69x/M/s7g")
-> 0x23af3720 xy7k69x/M/s7g
-> (ok)
tst("bar", "xy7k69x/M/s7g")
-> 0x23af3720 xy5FOaP3Hea0k
-> (ok)
tst(" ", "%qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d")
-> 0x23af3720 %q3ge9F/nF3ec
-> (ok)
Although the output on wheezy differs (it shouldn’t).
Please fix this to at least never return NULL with something
else than an ENOSYS condition (crypt(3) not implemented at all),
because this *will* break unrelated software.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Versions of packages libc6 depends on:
ii libgcc1 1:4.8.1-4
Versions of packages libc6 recommends:
ii libc6-i686 2.17-6
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.50
ii glibc-doc 2.17-6
ii locales-all [locales] 2.17-6
-- debconf information:
* glibc/upgrade: true
glibc/disable-screensaver:
glibc/restart-failed:
* glibc/restart-services: postfix openbsd-inetd cups cron
* libraries/restart-without-asking: true
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20130626220647.9086.25208.report...@tglase.lan.tarent.de
Bug#714219: libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
>From the 2.17 NEWS:
* The `crypt' function now fails if passed salt bytes that violate the
specification for those values. On Linux, the `crypt' function will
consult /proc/sys/crypto/fips_enabled to determine if "FIPS mode" is
enabled, and fail on encrypted strings using the MD5 or DES algorithm
when the mode is enabled.
> tst(" ", "%qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d");
This string contains invalid salt crypt character.
POSIX says:
~~~
Otherwise, it shall return a null pointer and set errno to indicate the error.
~~~
Therefore returning null and setting errno is entirely appropriate.
All conforming applications should check for NULL.
Conforming implementations may return additional errors to those
listed by POSIX
It is only a problem if you don't return the listed errno for the same error.
> if (strcmp(p->pw_passwd, crypt(oldpasswd, p->pw_passwd)) == 0) {
Examples are non-normative. They are simply informative and may assume things
like always using valid salt characters.
> If this is an error at all… on wheezy it was none, and BSD agrees:
It is not an error. You can't use invalid salt strings.
> Please fix this to at least never return NULL with something
> else than an ENOSYS condition (crypt(3) not implemented at all),
> because this *will* break unrelated software.
That will not get accepted upstream.
Please fix your application to conform with POSIX.
You must check the result and act appropriately when you see a NULL return
including cleaning the input to contain only valid salt characters.
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cae2ss1jpngrj9z2pezx3wewetahpyrzjcxlwmnidcete5qo...@mail.gmail.com
Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
Debian Bug Tracking System dixit: >If you wish to submit further information on this problem, please >send it to 714...@bugs.debian.org. Oh well, a '%' is not in the list of DES inputs, so differing is permitted, but returning NULL is so very not nice. Shortening the string shows “DES” can be done on it, so do it; just return "*" (or "x" if the input is "*" so it never matches) if you absolutely can’t return anything else useful. (We continued this discussion in IRC…) bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306262247030.3...@herc.mirbsd.org
Fwd: Bug report on eperl: eperl crashes with exit status 139 [origin: alexan...@cmu.edu]
Hi eglibc maintainers, the attached crash in eperl looks like a bug in getopt_long of libc6 to me: [ 18.024562] eperl[2718]: segfault at 1 ip b74b0d4f sp bf9457ec error 4 in libc-2.17.so[b7433000+1a9000] Backtrace: Program received signal SIGSEGV, Segmentation fault. __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32 32 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory. (gdb) bt #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32 #1 0x770e4872 in _getopt_internal_r (argc=, argv=, optstring=, longopts=, longind=, long_only=, d=0x773b6de0, posixly_correct=0) at getopt.c:544 #2 0x770e569b in _getopt_internal (argc=1, argv=0x7fffe228, optstring=0x0, longopts=0x1, longind=0x0, long_only=0, posixly_correct=0) at getopt.c:1131 #3 0x770e5783 in getopt_long (argc=1, argv=0x7fffe228, options=0x0, long_options=0x1, opt_index=0x0) at getopt1.c:66 #4 0x0040376c in main () Minimal case to reproduce it: "eperl --=" Once the bug report is filed, I'd reassign it to libc6 -- unless someone objects. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 --- Begin Message --- Hi, We found a crash in eperl contained in the eperl package. You are being contacted because your are listed as one of the maintainer of eperl. We are planning to submit the bug to the Debian bug tracking system in two weeks. We wanted to give you a heads-up, so that you some time to assess the seriousness of the bug before it is publicly disclosed. The bug report that will be submitted to the bug tracker is available at the following url: http://www.forallsecure.com/bug-reports/f526d6b489779b4d30b380f3ce77b09e3be31471/ This email is part of a mass bug reporting campain comprising 1,182 bugs. You might have received multiple emails from us concerning different programs. More information about the mass bug reporting is available on the debian-devel mailing list: http://lists.debian.org/debian-devel/2013/06/msg00720.html Regards, The Mayhem Team Cylab, Carnegie Mellon University --- End Message ---
Re: Fwd: Bug report on eperl: eperl crashes with exit status 139 [origin: alexan...@cmu.edu]
On Thu, Jun 27, 2013 at 01:07:13AM +0200, Axel Beckert wrote: > #3 0x770e5783 in getopt_long (argc=1, argv=0x7fffe228, > options=0x0, long_options=0x1, opt_index=0x0) > at getopt1.c:66 Why are the options and long_options arguments shown with nonsense contents? Bastian -- In the strict scientific sense we all feed on death -- even vegetarians. -- Spock, "Wolf in the Fold", stardate 3615.4 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130626231125.ga23...@mail.waldi.eu.org
Re: Processed: notfound 713035 in 2.17-5
found 2.17-1 thanks On Tue, Jun 25, 2013 at 11:06:17AM +, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > > > notfound 713035 2.17-5 > Bug #713035 [libc6] FTBFS on amd64/ia64 testsuite fails > No longer marked as found in versions eglibc/2.17-5. This is actually wrong. The problem is not new on the package side, but on the way the amd64 and ia64 build daemons are setup (using tmpfs to build packages). This mail therefore fixes the version in the BTS. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130626234107.gc13...@hall.aurel32.net
Re: Fwd: Bug report on eperl: eperl crashes with exit status 139 [origin: alexan...@cmu.edu]
On Thu, Jun 27, 2013 at 01:07:13AM +0200, Axel Beckert wrote:
> Hi eglibc maintainers,
>
> the attached crash in eperl looks like a bug in getopt_long of libc6
> to me:
>
> [ 18.024562] eperl[2718]: segfault at 1 ip b74b0d4f sp bf9457ec error 4 in
> libc-2.17.so[b7433000+1a9000]
>
> Backtrace:
>
> Program received signal SIGSEGV, Segmentation fault.
> __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32
> 32 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
> (gdb) bt
> #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32
> #1 0x770e4872 in _getopt_internal_r (argc=,
> argv=, optstring=,
> longopts=, longind=, long_only= out>, d=0x773b6de0, posixly_correct=0)
> at getopt.c:544
> #2 0x770e569b in _getopt_internal (argc=1, argv=0x7fffe228,
> optstring=0x0, longopts=0x1, longind=0x0,
> long_only=0, posixly_correct=0) at getopt.c:1131
> #3 0x770e5783 in getopt_long (argc=1, argv=0x7fffe228,
> options=0x0, long_options=0x1, opt_index=0x0)
> at getopt1.c:66
> #4 0x0040376c in main ()
>
> Minimal case to reproduce it: "eperl --="
>
> Once the bug report is filed, I'd reassign it to libc6 -- unless
> someone objects.
I object. The problem is clearly on the eperl side, which passes to
getopt_long an option structure not ended by { 0, 0, 0, 0 }.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130626234955.gd13...@hall.aurel32.net
Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
On Wed, Jun 26, 2013 at 10:48:55PM +, Thorsten Glaser wrote: > Debian Bug Tracking System dixit: > > >If you wish to submit further information on this problem, please > >send it to 714...@bugs.debian.org. > > Oh well, a '%' is not in the list of DES inputs, so differing > is permitted, but returning NULL is so very not nice. > > Shortening the string shows “DES” can be done on it, so do it; > just return "*" (or "x" if the input is "*" so it never matches) > if you absolutely can’t return anything else useful. > > (We continued this discussion in IRC…) As the function is POSIX compliant, it looks like to me a documentation issue. Should this bug be reassigned to manpages-dev to mention the fact that the function might return NULL in case of error? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130626233558.ga13...@hall.aurel32.net
Re: Fwd: Bug report on eperl: eperl crashes with exit status 139 [origin: alexan...@cmu.edu]
Hi Aurelien!
Aurelien Jarno wrote:
> I object. The problem is clearly on the eperl side, which passes to
> getopt_long an option structure not ended by { 0, 0, 0, 0 }.
Thanks for that hint!
Regards, Axel
--
,''`. | Axel Beckert , http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130626235637.gr30...@sym.noone.org
Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
Aurelien Jarno dixit: >As the function is POSIX compliant, it looks like to me a documentation >issue. Should this bug be reassigned to manpages-dev to mention the fact >that the function might return NULL in case of error? The NULL-in-case-of-error mentioned by POSIX is when the function is not implemented *at all*, i.e. all calls to it would fail independent of the input (and then, you’d have bigger problems). Even the example code given in POSIX uses crypt() without checking for NULL explicitly, assuming it’ll always get a string out that just won’t compare equally if it’s not a valid password. There’s bound to be lots of software that uses crypt() like this, especially as this behaviour has been in existence for *decades* literally, and will continue to be on other OSes. This probably *will* introduce security holes, especially when the password hash is user-controlled; libc should behave sanely here and just fall back to “DES”. Or just return "*" unless the argument is "*" in which case it can return "x". I find it especially poor form of GNU when the GNU libc breaks other GNU software… bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306262348430.3...@herc.mirbsd.org
Re: Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
On Wed, Jun 26, 2013 at 11:53:39PM +, Thorsten Glaser wrote: > Aurelien Jarno dixit: > > >As the function is POSIX compliant, it looks like to me a documentation > >issue. Should this bug be reassigned to manpages-dev to mention the fact > >that the function might return NULL in case of error? > > The NULL-in-case-of-error mentioned by POSIX is when the > function is not implemented *at all*, i.e. all calls to > it would fail independent of the input (and then, you’d > have bigger problems). This is *your* interpretation of POSIX. Quoting it, there is no ambiguity that crypt can return NULL for any failure (i.e. not successful completion): | Upon successful completion, crypt() shall return a pointer to the | encoded string. The first two bytes of the returned value shall be those | of the salt argument. Otherwise, it shall return a null pointer and set | errno to indicate the error. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130627001037.ge13...@hall.aurel32.net
Bug#712047: marked as done (libc6-dev: cannot build C programs)
Your message dated Thu, 27 Jun 2013 01:37:07 +0200 with message-id <20130626233707.gb13...@hall.aurel32.net> and subject line Re: Bug#712047: libc6-dev: cannot build C programs has caused the Debian Bug report #712047, regarding libc6-dev: cannot build C programs to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 712047: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712047 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6-dev Version: 2.13-38 Severity: important Hello, I tried building a C program with libc-dev installed. The program would not build because headers were missing: libc6-dev-i386: /usr/include/bits libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/predefs.h linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/errno.h gcc-multilib: /usr/include/asm For the asm/errno.h (referenced from common header) to be present gcc-multilib must be installed. Similarily for bits/predefs.h to be present libc6-dev-i386 must be installed. The libc6-dev package is incomplete and cannot stand on its own. Dependency on gcc-multilib is bogus. It requires specific version of gcc installed. Also, libc6-dev does not depend on these packages. Please make a libc package against which C programs do compile. Thanks Michal -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.8-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libc6-dev depends on: ii libc-dev-bin2.13-38 ii libc6 2.13-38 ii linux-libc-dev 3.2.41-2 Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.7.2-1 ii gcc-4.4 [c-compiler] 4.4.7-2 ii gcc-4.7 [c-compiler] 4.7.2-5 Versions of packages libc6-dev suggests: pn glibc-doc pn manpages-dev -- no debconf information -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (910, 'testing'), (900, 'stable'), (610, 'oldstable'), (410, 'unstable'), (200, 'experimental'), (150, 'precise-updates'), (150, 'precise-security'), (150, 'precise') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6-dev depends on: ii libc-dev-bin2.17-3 ii libc6 2.17-3 ii linux-libc-dev 3.8.13-1 Versions of packages libc6-dev recommends: ii bcc [c-compiler] 0.16.17-3.1 ii gcc [c-compiler] 4:4.7.2-1 ii gcc-4.6 [c-compiler] 4.6.3-15 ii gcc-4.7 [c-compiler] 4.7.2-5 Versions of packages libc6-dev suggests: pn glibc-doc ii manpages-dev 3.44-1 -- no debconf information --- End Message --- --- Begin Message --- On Thu, Jun 13, 2013 at 11:50:40AM +0200, Michal Suchanek wrote: > Excerpts from Aurelien Jarno's message of Wed Jun 12 18:17:13 +0200 2013: > > tag 712047 + moreinfo > > thanks > > > > On Wed, Jun 12, 2013 at 04:30:08PM +0200, Michal Suchanek wrote: > > > Package: libc6-dev > > > Version: 2.13-38 > > > Severity: important > > > > > > Hello, > > > > > > I tried building a C program with libc-dev installed. > > > > > > The program would not build because headers were missing: > > > > > > libc6-dev-i386: /usr/include/bits > > > > You don't need this one, your compiler should look into > > /usr/include/x86_64-linux-gnu/bits. > > > > > libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/predefs.h > > > > This is libc6-dev the package you are reporting the bug against, > > so it can't be missing. > > No, it's just wrong place. > > > > > > linux-libc-dev:amd64: /usr/include/x86_64-linux-gnu/asm/errno.h > > > > libc6-dev already depends on this one. > > > > > gcc-multilib: /usr/include/asm > > > > You don't need this one, your compiler should already lokk into > > /usr/include/x86_64-linux-gnu/asm. > > It does not. > > > > > > > For the asm/errno.h (referenced from common header) to be present > > > gcc-multilib must be installed. > > > > > > Similarily for bits/predefs.h to be present libc6-dev-i386 must be > > > installed. > > > > > > The libc6-dev package is incomplete and cannot stand on its own. > > > > > > Dependency on gcc-multilib is bogus. It requires specific version of gcc > > > installed. > > > > > > Also, libc6-dev does not depend on these packages. > > > > > > Please make a libc package against
Processed: Re: Bug#713836: regcomp(3) writes past end of regex_t
Processing commands for cont...@bugs.debian.org: > tag 713836 + unreproducible Bug #713836 [libc6] regcomp(3) writes past end of regex_t; breaks kernel compile Added tag(s) unreproducible. > tag 713836 + moreinfo Bug #713836 [libc6] regcomp(3) writes past end of regex_t; breaks kernel compile Added tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 713836: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713836 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.137229270030540.transcr...@bugs.debian.org
Re: Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
Aurelien Jarno dixit: >ambiguity that crypt can return NULL for any failure (i.e. not >successful completion): Indeed, but, one, it doesn’t list any other error code (nor do the glibc manpages) and two, there _is_ something called common law: it’s been like this for decades. >This is *your* interpretation of POSIX. Quoting it, there is no Do you, by inaction, want to sign responsible for all security holes introduced into previously-working code in the archive that now, without even a recompilation, breaks? Or will you add some small patch fixing this behaviour and feed that patch also upstream? I do not disagree that user programs “probably” “should” check for NULL, but let’s face reality. And libc *also* has some part in the job: it should not make userspace’s live too hard. bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (260 (281) bugs: 0 RC, 182 (196) I&N, 78 (85) M&W, 0 (0) F&P) ‣ src:dash (87 (103) bugs: 3 RC, 41 (46) I&N, 43 (54) M&W, 0 F&P) ‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P, 1 gift) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit? -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306270024230.3...@herc.mirbsd.org
Re: Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
On Thu, Jun 27, 2013 at 12:28:22AM +, Thorsten Glaser wrote: > Aurelien Jarno dixit: > > >ambiguity that crypt can return NULL for any failure (i.e. not > >successful completion): > > Indeed, but, one, it doesn’t list any other error code (nor do > the glibc manpages) and two, there _is_ something called common > law: it’s been like this for decades. > > >This is *your* interpretation of POSIX. Quoting it, there is no > > Do you, by inaction, want to sign responsible for all security > holes introduced into previously-working code in the archive > that now, without even a recompilation, breaks? > > Or will you add some small patch fixing this behaviour and > feed that patch also upstream? > Please provide a patch, and I will add it in the next upload. If you don't, you will sign responsible for all security holes introduced into previously-working code in the archive. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130627004702.gi13...@hall.aurel32.net
Bug#713836: regcomp(3) writes past end of regex_t
tag 713836 + unreproducible
tag 713836 + moreinfo
thanks
On Sun, Jun 23, 2013 at 02:59:20AM -0400, sacrificial-spam-addr...@horizon.com
wrote:
> Package: libc6
> Version: 2.17-6
> Architecture: i386
> Severity: important
>
> This problem cropped up while compiling the kernel; it breaks
> arch/x86/tools/relocs.c. I've tracked it down and reduced
> it to a small test case.
>
> With the given arguments, regcomp() corrupts the byte past the end of
> its supplied regex_t buffer. This obviously can cause any manner of
> undesired program behavior.
>
> Note that this is 32-bit i386, not 64-bit.
>
> Here's a simple test program:
>
> #include
> #include
> #include
>
> regex_t array[2];
>
> static bool
> is_zero(void const *p, size_t len)
> {
> size_t i;
> unsigned char const *pp = p;
> bool rv = true;
>
> for (i = 0; i < len; i++) {
> if (pp[i]) {
> printf("J'accuse! buf[%zu] = %#x\n",
> i, pp[i]);
> rv = false;
> }
> }
> return rv;
> }
>
> int
> main(void)
> {
> if (is_zero(array+1, sizeof array[1]))
> printf("array[1] confirmed all-zero\n");
> regcomp(array+0, "^pa_", REG_EXTENDED|REG_NOSUB);
> if (is_zero(array+1, sizeof array[1]))
> printf("array[1] confirmed all-zero\n");
> else
> printf("Bug! array[1] has been overwritten!\n");
> return 0;
> }
>
> And here's what running it produces:
> $ ./a.out
> array[1] confirmed all-zero
> J'accuse! buf[0] = 0x18
> Bug! array[1] has been overwritten!
> $ ldd ./a.out
> linux-gate.so.1 (0xf7784000)
> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75ea000)
> /lib/ld-linux.so.2 (0xf7785000)
>
> (The fact that the libc6-i686 libraries, which I have installed, are
> not being used is due libc6-i686 postinst not handling multiarch; I'll
> report that separately.)
I am personally not able to to reproduce the issue with your test
program on an up to date i386 sid system. Could you please provide us
the command you are using to compile the test code and the locale you
are using?
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130627002456.gf13...@hall.aurel32.net
Bug#713837: libc6-i686 postinst fails to parse dpkg-query output
On Sun, Jun 23, 2013 at 07:18:39PM +0200, Tomas Janousek wrote: > Hi, > > On Sun, Jun 23, 2013 at 03:13:43AM -0400, > sacrificial-spam-addr...@horizon.com wrote: > > Although this doesn't break anything else, it renders the package useless. > > It does break stuff. The nvidia driver for example -- it loads > /usr/lib/i386-linux-gnu/libnvidia-tls.so.319.23 instead of > /usr/lib/i386-linux-gnu/tls/libnvidia-tls.so.319.23, and the non-tls library > writes to %gs and segfaults when starting X, making the system very much > unusable. > Why do we still provide a non-tls version of this library? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130627002600.gg13...@hall.aurel32.net
Re: Bug#714219: Acknowledgement (libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software)
Aurelien Jarno dixit: >Please provide a patch, and I will add it in the next upload. If you >don't, you will sign responsible for all security holes introduced into >previously-working code in the archive. It's freaking late at night, and I just spent hours fighting with gnulib and *then* hours I'd rather be doing something else discovering, analysing and discussing it, so gimme a rest, I've got to work for money romoeeow. You responded first that's why I wrote that. If you dont have a patch tomorrow evening i'll try to oblige. //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306270100220.3...@herc.mirbsd.org
Bug#713836: regcomp(3) writes past end of regex_t
> I am personally not able to to reproduce the issue with your test > program on an up to date i386 sid system. Could you please provide us > the command you are using to compile the test code and the locale you > are using? Very interesting! I'm also using an up-to-date sid system. No locale is set. I had been holding off on upgrading other machines to 2.17-6 because of this, but I just went and upgraded one and it also does not show the problem. WTF? The one major difference is that it's running a 32-bit kernel as opposed to a 64-bit one. Anyway, here's some hopefully useful information (blank lines added for readability) Script started on Thu Jun 27 01:13:16 2013 [500]$ gcc -v bug.c Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.8/lto-wrapper Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-4' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i586 --with-multili b-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.8.1 (Debian 4.8.1-4) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i586' /usr/lib/gcc/i486-linux-gnu/4.8/cc1 -quiet -v -imultilib . -imultiarch i386-linux-gnu bug.c -quiet -dumpbase bug.c -mtune=generic -march=i586 -auxbase bug -version -o /tmp/ccnfNMA2.s GNU C (Debian 4.8.1-4) version 4.8.1 (i486-linux-gnu) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/include/i386-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.8/../../../../i486-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i486-linux-gnu/4.8/include /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.8/include-fixed /usr/include/i386-linux-gnu /usr/include End of search list. GNU C (Debian 4.8.1-4) version 4.8.1 (i486-linux-gnu) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.1-p2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: b99bb83419f5bdeabc03ef14532498a2 COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i586' as -v --32 -o /tmp/ccOPAAts.o /tmp/ccnfNMA2.s GNU assembler version 2.23.52 (i486-linux-gnu) using BFD version (GNU Binutils for Debian) 2.23.52.20130620 COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.8/:/usr/lib/gcc/i486-linux-gnu/4.8/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.8/:/usr/lib/gcc/i486-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.8/:/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.8/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.8/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i586' /usr/lib/gcc/i486-linux-gnu/4.8/collect2 --sysroot=/ --build-id --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crt1.o /usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crti.o /usr/lib/gcc/i486-linux-gnu/4.8/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.8 -L/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu -L/usr/lib/gcc/i486-linux-gnu/4.8/../../../../lib -L/lib/i386-linux-gnu -L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.8/../../.. /tmp/ccOPAAts.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.8/crtend.o /usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o [501]$ ./a.out array[1] confirmed all-zero J'accuse! buf[0] = 0x18 Bug! array[1] has been overwritten! [502]$ gcc -O bug.c [503]$ ./a.out array[1] confirmed all-zero J'accuse! buf[0] = 0x18 Bug! array[1] has been overwritten! [504]$ gcc -O2 bug.c [505]$ ./a.out array[1]
Bug#713836: regcomp(3) writes past end of regex_t
Okay, I did a bit of comparison. The machine the binary was *compiled* on seemed to matter, not the one it was *run* on. A bit of extra printing revealed the obvious culprit: [539]$ ./a.out sizeof regex_t = 28 array[1] confirmed all-zero J'accuse! buf[0] = 0x18 Bug! array[1] has been overwritten! [524]$ ./a.out sizeof regex_t = 32 array[1] confirmed all-zero array[1] confirmed all-zero It's obviously a header file issue. I will go investigate. The /usr/include/regex.h files are identical between the machines, it must be something else... Aha! Where did /usr/local/include/sys/types.h come from? It's been there since 2007 and never caused a problem until now... Anyway, the difference seems to boil down to the following gcc -E difference: (- = buggy, + = works) unsigned char *__buffer; unsigned long int __allocated; - unsigned long int __attribute__((__used__)); + unsigned long int __used; reg_syntax_t __syntax; Sorry to jump to conclusions and blame you. Thanks for trying to reproduce and putting me on the right track! -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130627015717.5965.qm...@science.horizon.com
Bug#713836: marked as done (regcomp(3) writes past end of regex_t; breaks kernel compile)
Your message dated 27 Jun 2013 02:31:23 -0400
with message-id <20130627063123.4937.qm...@science.horizon.com>
and subject line Bug#713836 was a system misconfiguration
has caused the Debian Bug report #713836,
regarding regcomp(3) writes past end of regex_t; breaks kernel compile
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
713836: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713836
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.17-6
Architecture: i386
Severity: important
This problem cropped up while compiling the kernel; it breaks
arch/x86/tools/relocs.c. I've tracked it down and reduced
it to a small test case.
With the given arguments, regcomp() corrupts the byte past the end of
its supplied regex_t buffer. This obviously can cause any manner of
undesired program behavior.
Note that this is 32-bit i386, not 64-bit.
Here's a simple test program:
#include
#include
#include
regex_t array[2];
static bool
is_zero(void const *p, size_t len)
{
size_t i;
unsigned char const *pp = p;
bool rv = true;
for (i = 0; i < len; i++) {
if (pp[i]) {
printf("J'accuse! buf[%zu] = %#x\n",
i, pp[i]);
rv = false;
}
}
return rv;
}
int
main(void)
{
if (is_zero(array+1, sizeof array[1]))
printf("array[1] confirmed all-zero\n");
regcomp(array+0, "^pa_", REG_EXTENDED|REG_NOSUB);
if (is_zero(array+1, sizeof array[1]))
printf("array[1] confirmed all-zero\n");
else
printf("Bug! array[1] has been overwritten!\n");
return 0;
}
And here's what running it produces:
$ ./a.out
array[1] confirmed all-zero
J'accuse! buf[0] = 0x18
Bug! array[1] has been overwritten!
$ ldd ./a.out
linux-gate.so.1 (0xf7784000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75ea000)
/lib/ld-linux.so.2 (0xf7785000)
(The fact that the libc6-i686 libraries, which I have installed, are
not being used is due libc6-i686 postinst not handling multiarch; I'll
report that separately.)
--- End Message ---
--- Begin Message ---
Turns out it was a stale header in /usr/local/include that was causing
the compiler to think the structure was 4 bytes smaller than the C
library did. Buffer overruns were inevitable.
I think the reason it happened to show up now was that the only affected
source was a Linux kernel helper script that was very stable and so dodn't
get recompiled for a long time even though the C library had changed.
But then I was hunting a kernel bug and did a "make clean" as a
precaution, and kaboom.--- End Message ---
