Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM
Package: libc6-armhf-cross
Version: 2.28-2cross2
Severity: normal
Dear Maintainer,
currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
The expected errno value would be either EINVAL or not touching errno
at all.
This behavior is relatively new and causes some CI cross builds to fail.
The failing test is a gnulib test (test-strerror.c).
The behavior is not seen on an i368 cross build, while on all our other cross
builds,
which are arm-linux-gnueabihf, mips-linux-gnu, aarch64-linux-gnu.
Here is a small reproducer:
include
#include
#include
int main(void)
{
errno=0;
char *msg=strerror(-3);
printf("errno=%d, msg=%s\n",errno,msg);
return 0;
}
Test it with:
$ arm-linux-gnueabihf-gcc -Wextra x.c -o x
$ ./x
errno=12, msg=Unknown error -3
You need the binfmt/qemu stuff set up to execute the cross-compiled binary.
Regards, Tim
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-3-amd64 (SMP w/12 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), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#883407: libc6: getpwnam_r() leaks memory
Am Dienstag, den 05.12.2017, 19:17 +0100 schrieb Aurelien Jarno: > On 2017-12-03 17:34, Tim Rühsen wrote: > > Package: libc6 > > Version: 2.25-3 > > Severity: normal > > > > Dear Maintainer, > > > > valgrinding a C code shows the following: > > > > ==27943== 4,096 bytes in 1 blocks are definitely lost in loss > > record 3 of 3 > > ==27943==by 0x6C27715: getpwnam_r@@GLIBC_2.2.5 > > (getXXbyYY_r.c:314) > > ==27943==by 0x4E8569F: rpl_glob (glob.c:781) > > > > That rpl_glob() is gnulib's glob replacement. The code there looks > > good. > > And valgrind doesn't/didn't show this leak with previous (2.24 and > > lower) > > versions of glibc. > > > > I can't currently provide you with a short reproducer (out of time > > here). > > It's not something I can reproduce here, but getpwnam_r can behave > very > differently depending on the nss configuration your system. A small > reproducer and the content of /etc/nsswitch.conf would definitely > help. > I'll try to make up a reproducer the next days. Here is more info that I have to far. ### nsswitch.conf ### passwd: compat systemd group: compat systemd shadow: compat hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 networks: files protocols: db files services: db files ethers: db files rpc:db files netgroup: nis > That said libc6 version 2.25-3 included security fixes and memory > leak > fixes for the glob function. Can you confirm the version you used, > and > if it's really 2.25-3 try with version 2.25-2 which is still in > testing. > The glob issues have been found by me when fuzzing GNU Wget2. Reported via gnulib mailing list :-) Just updated my stretch VM to testing... I can reproduce the issue with 2.25-2 (testing) and with 2.25-3 (unstable). Regards, Tim signature.asc Description: This is a digitally signed message part
Bug#818178: libc6: getaddrinfo/freeadrinfo memory leak
Package: libc6
Severity: important
Dear Maintainer,
getaddrinfo/freeaddrinfo seems to have a memory leak.
Testcode:
#include
#include
#include
#include
#include
int main(void)
{
struct addrinfo *addrinfo, hints;
memset(, 0 ,sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_NUMERICSERV | AI_ADDRCONFIG;
int rc;
if ((rc = getaddrinfo("localhost", "80", , )) == 0) {
freeaddrinfo(addrinfo);
}
printf("rc=%d\n", rc);
return 0;
}
Valgrind throws out:
==10088== HEAP SUMMARY:
==10088== in use at exit: 28 bytes in 1 blocks
==10088== total heap usage: 45 allocs, 44 frees, 7,337 bytes allocated
==10088==
==10088== 28 bytes in 1 blocks are still reachable in loss record 1 of 1
==10088==at 0x4C29C0F: malloc (vg_replace_malloc.c:299)
==10088==by 0x4F3BA64: __res_vinit (in /lib/x86_64-linux-gnu/libc-2.22.so)
==10088==by 0x4F3D17C: __res_maybe_init (in
/lib/x86_64-linux-gnu/libc-2.22.so)
==10088==by 0x4F09A26: gaih_inet (in /lib/x86_64-linux-gnu/libc-2.22.so)
==10088==by 0x4F0BD0D: getaddrinfo (in /lib/x86_64-linux-gnu/libc-2.22.so)
==10088==by 0x400625: main (in /usr/oms/src/wget2/examples/x)
==10088==
==10088== LEAK SUMMARY:
==10088==definitely lost: 0 bytes in 0 blocks
==10088==indirectly lost: 0 bytes in 0 blocks
==10088== possibly lost: 0 bytes in 0 blocks
==10088==still reachable: 28 bytes in 1 blocks
==10088== suppressed: 0 bytes in 0 blocks
Currently a test suite here fails due to this leak.
When setting 'addrinfo' to NULL after freeaddrinfo(), valgrind reports the leak
as
'definitely lost' and returns with non-zero, thus the breakage of the test
suite.
Regards, Tim
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.0-1-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/dash
Init: systemd (via /run/systemd/system)
Bug#787807: libc6: mq_open unexpectedly fails with errno 24
On Mon, 15 Jun 2015 11:55:47 +0200 Aurelien Jarno aurel...@aurel32.net wrote: Nothing has changed in the libc6 package for sometimes. When does the breakage started? I see you are using a 4.0 kernel, could it be due to that? I made some tests on Debian VMs, that I have flying around. Debian SID with 4.0 (amd64): problem as described above Debian SID with 3.16 (amd64): same problem Debian Wheezy with 3.2.0 (amd64): same problem Debian Wheezy with 3.2.0 (i386): Works as expected (up to maxmsg=1000, with maxmsg=1001 I get errno=22 (Invalid argument) - that's fine for me, but is not what the man page says for this case. BTW the man page for mq_open is broken - double entries below ERRORS). Looks like amd64 architecture has the problem since a while. Tim signature.asc Description: This is a digitally signed message part.
Bug#787807: libc6: mq_open unexpectedly fails with errno 24
On Monday 15 June 2015 15:21:52 Aurelien Jarno wrote: I made some tests on Debian VMs, that I have flying around. Debian SID with 4.0 (amd64): problem as described above Debian SID with 3.16 (amd64): same problem Debian Wheezy with 3.2.0 (amd64): same problem Debian Wheezy with 3.2.0 (i386): Works as expected (up to maxmsg=1000, with maxmsg=1001 I get errno=22 (Invalid argument) - that's fine for me, but is not what the man page says for this case. Ok, forget about the man pages. I was just puzzled by multiple entries per error number. Looks like amd64 architecture has the problem since a while. I don't really know what is the problem, but a strace shows that the glibc just returns the errno from the kernel. What does ulimit -q returns on your system? It seems to be 819200 by default, which is why the kernel refuses to create the message queue. Yes, it is 819200 on i386 (Wheezy) and on amd64 (SID) here. Here increasing the value allows the msg queue to be created successfully. The way to compute the limit is described in the getrlimit(2) manpage. Note that the value includes size of structures, which are likely to be different on i386 and amd64, and has changed starting with kernel 3.5. It's therefore likely that by using an amd64 machine and a recent kernel, you crossed the 819200 limit. Woooh, thanks for that hint ! Wouldn't have thought about this for a while... BTW, using /etc/security/limits.conf to increase that value (tried hard, soft, - for * and for the user) does not increase the users ulimit value (nor permits him to increase it via ulimit). But that is another story... did not test a reboot yet. Many thanks for your help. I guess you can close this bug. Best Regards Tim signature.asc Description: This is a digitally signed message part.
Bug#787807: libc6: mq_open unexpectedly fails with errno 24
Package: libc6
Severity: normal
Dear Maintainer,
I have an application that uses Posix message queues since a while.
Today I realized that mq_open fails with errno 24 where it worked before.
(errno 24: Too many open files)
Here is a short C file to reproduce the problem.
Before you start it, you have to increase msg_max system default:
sysctl -w fs.mqueue.msg_max=1000
Now (as normal user) execute the following code:
#include stdio.h
#include mqueue.h
#include errno.h
void main(void) {
struct mq_attr attr={.mq_maxmsg=900,.mq_msgsize=1020};
int rc=mq_open(/xxx,O_CREAT | O_RDONLY, 0600, attr);
printf(rc=%d errno=%d\n,rc,errno);
}
It returns errno 24. Using a value of 800 for .mq_maxmsg returns success.
Compile with gcc x.c -o x -lrt.
The system settings should allow the above values without problem:
$ ls /proc/sys/fs/mqueue/|more
msg_default
msg_max
msgsize_default
msgsize_max
queues_max
$ cat /proc/sys/fs/mqueue/*
10
1000
8192
8192
256
Regards, Tim
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.0.0-1-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/dash
Init: systemd (via /run/systemd/system)
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20150605094454.13518.60476.report...@blitz-lx.oms.de
Bug#692433: getaddrinfo: Syscall param socketcall.connect(serv_addr.sin6_addr) points to uninitialised byte(s)
Package: libc6
Version: 2.13-36
Severity: normal
Dear Maintainer,
when calling getaddrinfo(), valgrind detects:
==7051== Syscall param socketcall.connect(serv_addr.sin6_addr) points to
uninitialised byte(s)
==7051==at 0x362E6DB780: __connect_nocancel (syscall-template.S:82)
==7051==by 0x362E6B9307: getaddrinfo (getaddrinfo.c:2279)
==7051==by 0x4006A3: main (x.c:17)
==7051== Address 0x7fe10 is on thread 1's stack
==7051== Uninitialised value was created by a stack allocation
==7051==at 0x362E6B8FD0: getaddrinfo (getaddrinfo.c:2092)
Here is the short C source to reproduce the problem (gcc -g x.c -o x):
#include stdio.h
#include string.h
#include sys/types.h
#include sys/socket.h
#include netdb.h
void main(void)
{
struct addrinfo *addrinfo = NULL;
struct addrinfo hints;
memset(hints,0,sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_NUMERICSERV;
if (getaddrinfo(www.example.com, 80, hints, addrinfo) == 0)
freeaddrinfo(addrinfo);
}
This problem is pretty new, maybe introduced by fixing bug #690021.
Regards, Tim
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6:amd64 depends on:
ii libc-bin 2.13-36
ii libgcc1 1:4.7.2-4
libc6:amd64 recommends no packages.
Versions of packages libc6:amd64 suggests:
ii debconf [debconf-2.0] 1.5.46
ii glibc-doc 2.13-36
ii locales2.13-36
ii locales-all [locales] 2.13-36
-- debconf information excluded
--
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/20121106090905.6897.36200.report...@blitz-lx.oms.de
Bug#553206: libc6: sscanf segfaults with %d on large decimal input string
Package: libc6
Version: 2.10.1-2
Severity: normal
sscanf(p,%d,i) caused a SIGSEGV raised if p points to a very long input
string with just
decimal characters in it.
that makes %d unusable for scanning untrusted input. (in my case a sip
registrar).
here is a code example that shows it (use 2*1024*1024 and it works)
# compile with e.g. gcc x.c -o x
#include stdio.h
#include string.h
#include stdlib.h
int main()
{
int n;
char *p;
#define NBUF (3*1024*1024)
p=malloc(NBUF);
if (p) {
memset(p,'1',NBUF);
p[NBUF-1]=0;
printf(here we go...\n);
sscanf(p,%d,n);
printf(n=%d\n,n);
free(p);
}
return 0;
}
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages libc6 depends on:
ii libc-bin 2.10.1-2 GNU C Library: Binaries
ii libgcc1 1:4.4.2-1 GCC support library
Versions of packages libc6 recommends:
ii libc6-i6862.10.1-2 GNU C Library: Shared libraries [i
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy
ii glibc-doc 2.10.1-2 GNU C Library: Documentation
ii locales 2.10.1-2 GNU C Library: National Language (
ii locales-all [locales] 2.10.1-2 GNU C Library: Precompiled locale
-- debconf information:
* glibc/upgrade: true
glibc/disable-screensaver:
glibc/restart-failed:
* glibc/restart-services: spamassassin samba rsync postfix openbsd-inetd cups
cron atd
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#292523: libc6: sprintf %0lld fails if argument is 0
Package: libc6 Version: 2.3.2.ds1-20 Severity: important sprintf(buf,'%0d' '%0ld' '%0lld',0,0L,0LL); fills into buf: '0' '0' '' This is not conforming to the man page. And it breaks test runs for mozilla. This is the reason for 'important'. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
