Bug#568913: depends on nonexistent glibc-2.11-1

[Florian Weimer]

 Package: locales

 Now there are TWO experimental packages.
 # apt-cache policy locales
 locales:
   Installed: 2.10.2-5
   Candidate: 2.11-0exp4
   Version table:
  2.11-0exp4 0
 990 http://ftp.tw.debian.org experimental/main Packages
  2.11-0exp2 0
 990 http://ftp.tw.debian.org experimental/main Packages
  *** 2.10.2-5 0
 500 http://ftp.tw.debian.org unstable/main Packages
 100 /var/lib/dpkg/status

 However both depend on nonexistent glibc-2.11-1.

Experimental hasn't got full autobuilder support.  You see such bogus
Architecture: all packages if the source package hasn't been built for
your architecture.  (Presumably, things could be improved on the dak
side. to skip such packages when compiling the Packages file.)

Note that this should not cause problems in practice because APT will
not install from experimental automatically (hence the three starts
before version 2.10.2-5).



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#600667: eglibc: cve-2010-3847 dynamic linker expands $ORIGIN in setuid library search path

[Florian Weimer]

* Aurelien Jarno:

 I have just committed the fix, I am planning to do an upload soon to
 unstable. Do you think we should also fix it in stable? via a security
 release?

FYI, I have uploaded eglibc 2.11.2-6+squeeze1 to testing-security.



-- 
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/87vd4usmme@mid.deneb.enyo.de

Re: glibc_2.7-18lenny6_source.changes REJECTED

[Florian Weimer]

* Debian FTP Masters:

 Reject Reasons:
 source only uploads are not supported.

 Notes:
 Mapping stable-security to proposed-updates.

Ahem.  Should I upload a newer version to stable-proposed-updates, or
is this a spurious error message?


-- 
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/87sjzyruss@mid.deneb.enyo.de

squeeze upload for eglibc due to DSA-2122-2

[Florian Weimer]

I would like to make an upload of eglibc to address DSA-2122-2 (the
first round of patches for the $ORIGIN/LD_AUDIT issue does not cover
all corner cases, unfortunately).  The changes match those in
2.7-18lenny7, which are based almost verbatim on the upstream patches
(except for whitespace changes and one manual conflict resultion, see
the attachments; cvs-origin-suid.diff and
any/local-audit-pathless.diff).

Should I push this through testing-security, testing-proposed-updates
or unstable?  Have you got any preferences about version numbers?
commit 22cd1c9bcf57c5829d65b6da825f7a459d40c9eb
Author: Andreas Schwab sch...@redhat.com
Date:   Sun Oct 24 20:40:14 2010 -0400

Don't expand DST twice in dl_open

diff --git a/elf/dl-open.c b/elf/dl-open.c
index 754a263..c394b3f 100644
--- a/elf/dl-open.c
+++ b/elf/dl-open.c
@@ -221,36 +221,6 @@ dl_open_worker (void *a)
 
   assert (_dl_debug_initialize (0, args-nsid)-r_state == RT_CONSISTENT);
 
-  /* Maybe we have to expand a DST.  */
-  if (__builtin_expect (dst != NULL, 0))
-{
-  size_t len = strlen (file);
-  size_t required;
-  char *new_file;
-
-  /* Determine how much space we need.  We have to allocate the
-	 memory locally.  */
-  required = DL_DST_REQUIRED (call_map, file, len, _dl_dst_count (dst, 0));
-
-  /* Get space for the new file name.  */
-  new_file = (char *) alloca (required + 1);
-
-  /* Generate the new file name.  */
-  _dl_dst_substitute (call_map, file, new_file, 0);
-
-  /* If the substitution failed don't try to load.  */
-  if (*new_file == '\0')
-	_dl_signal_error (0, dlopen, NULL,
-			  N_(empty dynamic string token substitution));
-
-  /* Now we have a new file name.  */
-  file = new_file;
-
-  /* It does not matter whether call_map is set even if we
-	 computed it only because of the DST.  Since the path contains
-	 a slash the value is not used.  See dl-load.c.  */
-}
-
   /* Load the named object.  */
   struct link_map *new;
   args-map = new = _dl_map_object (call_map, file, 0, lt_loaded, 0,
commit 96611391ad8823ba58405325d78cefeae5cdf699
Author: Andreas Schwab sch...@redhat.com
Date:   Thu Dec 9 15:00:59 2010 +0100

Ignore origin of privileged program

diff --git a/elf/dl-object.c b/elf/dl-object.c
index 5d15ce1..a34e902 100644
--- a/elf/dl-object.c
+++ b/elf/dl-object.c
@@ -220,6 +220,9 @@ _dl_new_object (char *realname, const char *libname, int type,
 out:
   new-l_origin = origin;
 }
+  else if (INTUSE(__libc_enable_secure)  type == lt_executable)
+/* The origin of a privileged program cannot be trusted.  */
+new-l_origin = (char *) -1;
 
   return new;
 }
commit 8e9f92e9d5d7737afdacf79b76d98c4c42980508
Author: Andreas Schwab sch...@redhat.com
Date:   Sun Oct 24 21:43:15 2010 -0400

Require suid bit on audit objects in privileged programs

diff --git a/elf/dl-deps.c b/elf/dl-deps.c
index a58de5c..a51fb6e 100644
--- a/elf/dl-deps.c
+++ b/elf/dl-deps.c
@@ -62,7 +62,7 @@ openaux (void *a)
 {
   struct openaux_args *args = (struct openaux_args *) a;
 
-  args-aux = _dl_map_object (args-map, args-name, 0,
+  args-aux = _dl_map_object (args-map, args-name,
 			  (args-map-l_type == lt_executable
 			   ? lt_library : args-map-l_type),
 			  args-trace_mode, args-open_mode,
diff --git a/elf/dl-load.c b/elf/dl-load.c
index a7162eb..aa8738f 100644
--- a/elf/dl-load.c
+++ b/elf/dl-load.c
@@ -1812,7 +1812,7 @@ open_verify (const char *name, struct filebuf *fbp, struct link_map *loader,
if MAY_FREE_DIRS is true.  */
 
 static int
-open_path (const char *name, size_t namelen, int preloaded,
+open_path (const char *name, size_t namelen, int secure,
 	   struct r_search_path_struct *sps, char **realname,
 	   struct filebuf *fbp, struct link_map *loader, int whatcode,
 	   bool *found_other_class)
@@ -1894,7 +1894,7 @@ open_path (const char *name, size_t namelen, int preloaded,
 	  /* Remember whether we found any existing directory.  */
 	  here_any |= this_dir-status[cnt] != nonexisting;
 
-	  if (fd != -1  __builtin_expect (preloaded, 0)
+	  if (fd != -1  __builtin_expect (secure, 0)
 	   INTUSE(__libc_enable_secure))
 	{
 	  /* This is an extra security effort to make sure nobody can
@@ -1963,7 +1963,7 @@ open_path (const char *name, size_t namelen, int preloaded,
 
 struct link_map *
 internal_function
-_dl_map_object (struct link_map *loader, const char *name, int preloaded,
+_dl_map_object (struct link_map *loader, const char *name,
 		int type, int trace_mode, int mode, Lmid_t nsid)
 {
   int fd;
@@ -2067,7 +2067,8 @@ _dl_map_object (struct link_map *loader, const char *name, int preloaded,
 	  for (l = loader; l; l = l-l_loader)
 	if (cache_rpath (l, l-l_rpath_dirs, DT_RPATH, RPATH))
 	  {
-		fd = open_path (name, namelen, preloaded, l-l_rpath_dirs,
+		fd = open_path (name, namelen, mode  __RTLD_SECURE,
+l-l_rpath_dirs,
 realname, fb, loader, LA_SER_RUNPATH,
 found_other_class);
 		if 

Bug#609756: vsnprintf segfaults on second attempt with alloca

[Florian Weimer]

* Andrew Buckeridge:

 int vfprint(int fdout, const char *fmt, va_list ap)
 {
   int i=NONSTDBUF;
   i=vfnprint(fdout, i, fmt, ap);
   if(i-1)
   i=vfnprint(fdout, 1-i, fmt, ap);
   return i;
 }

va_copy seems to be missing here.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99



--
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/82k4ias9vi@mid.bfk.de

Bug#609756: vsnprintf segfaults on second attempt with alloca

[Florian Weimer]

* Andrew Buckeridge:

 C99 only va_copy does help. This is a new one for me.
 Does vfnprint destroy the callers ap?

Yes, it does.  Not on all platforms, but on amd64, for example.
Passing va_list as an argument does not make a sufficiently deep copy,
so that va_arg in the callee affects subsequent va_arg invocations in
the caller.

 Does this break C89 and C90?

Some systems have got __va_copy.  There's probably an autoconf test
for this.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99



--
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/8262tum25o@mid.bfk.de

Re: glibc's getaddrinfo() sort order

[Florian Weimer]

* Anthony Towns:

 I don't agree with making a decision to go against an IETF standard

RFC 3484 is not an IETF standard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: glibc's getaddrinfo() sort order

[Florian Weimer]

* Clint Adams:

 On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
 glibc is the only implementation I know of that does this.

 I have heard, though not confirmed first-hand, that modern
 versions of FreeBSD, Windows, and Solaris do as well.

FreeBSD 6.2-RELEASE doesn't do it.  And neither does Fedora (with GNU
libc 2.6.90-15, IPv6 not enabled).  (Windows is an entirely different
matter because the resolver model is completely different.)

You can run the following test program repeatedly to check if every A
record gets its chance.

import socket
print ', '.join(map(lambda x: x[4][0], 
  socket.getaddrinfo('pool.ntp.org', 123, 0, socket.SOCK_DGRAM)))


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#444597: mktime returns 0x7fffffff for the year 2057

[Florian Weimer]

reopen 444597
thanks

* Tanaka Akira:

 Do you mean 0x7fff is -1 ?

 I don't think so.

 -1 is 0x, not 0x7fff.

Oops, you a right.  This is a real bug, then.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: getaddrinfo() behaviour

[Florian Weimer]

* Anthony Towns:

 Updating the proposed standard has not been tried.

Just to give you an idea of the time scale involved: moving RFC 3484
to HISTORIC (which is the most likely result, at least for the Rule 9
part) will take at least a year.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#445682: Lack of cross-process mutexes on hppa

[Florian Weimer]

Package: libc6
Version: 2.6.1-5

On hppa, GNU libc does not support mutexes which can span multiple
address spaces.  The following test program prints

pthread_condattr_setpshared(condattr, PTHREAD_PROCESS_SHARED)
pthread_mutexattr_setpshared(mutexattr, PTHREAD_PROCESS_SHARED)

indicating that this functionality is not supported.  It works on amd64
and other architectures.

#include pthread.h
main() {
pthread_cond_t cond;
pthread_mutex_t mutex;
pthread_condattr_t condattr;
pthread_mutexattr_t mutexattr;
#define X(cond) if (cond) puts( #cond);
X(pthread_condattr_init(condattr));
X(pthread_condattr_setpshared(condattr, PTHREAD_PROCESS_SHARED));
X(pthread_mutexattr_init(mutexattr));
X(pthread_mutexattr_setpshared(mutexattr, PTHREAD_PROCESS_SHARED));
X(pthread_cond_init(cond, condattr));
X(pthread_mutex_init(mutex, mutexattr));
X(pthread_mutex_lock(mutex));
X(pthread_mutex_unlock(mutex));
X(pthread_mutex_destroy(mutex));
X(pthread_cond_destroy(cond));
X(pthread_condattr_destroy(condattr));
X(pthread_mutexattr_destroy(mutexattr));
}



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0

[Florian Weimer]

* Colin Watson:

 [*] 1.0.0.0 isn't even a valid IP address, is it?

 Depends on the situation. You wouldn't want to give a host that
 address,

Why not?  Subnet zero is no longer reserved.  The whole /8 is currently
not assigned, but that's a different matter.

 but it might be quite reasonable to have an A record resolve to that IP
 address for the purpose of naming the network. The resolver isn't in a
 position to distinguish those cases, IMO.

Fully agreed.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#482902: please provide libc6-hppa64 and libc6-hppa64-dev packages

[Florian Weimer]

* Thibaut VARENE:

 I'm not sure I understand this correctly though: what's needed right
 now is a debian-packaged etch-supported kernel (ie, 2.6.18 if my memory
 serves me right?) that works on hppa? Is it any different that the
 kernel package shipped with etch? (I suspect it is since the latter is
 not being used) If so, how so?

We see issues with the stable-security buildd (peri); it's often not
available when we need it.  IIRC, those are caused by kernel stability
issues, but my memory is a bit foggy.

For lenny, there are a couple of Berkeley DB issues that could need some
attention.  I'd also prefer if all architectures could provide the full
threading API, with cross-process mutexes and stuff like that (which
presumably would enable us to use that to fix the Berkeley DB bugs).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

[Florian Weimer]

* brian m. carlson:

 The glibc stub resolver is vulnerable to CVE-2008-1447, according to DSA
 1605.  Since the vast majority of network-using programs use glibc as a
 resolver, this vulnerability affects virtually any network-using
 program, hence the severity.  libc6 should not be released without a fix
 for this problem.

 The vulnerability has been exposed:

 http://demosthen.es/post/43048623/reliable-dns-forgery-in-2008

I fail to see how this attack has a chance to work against non-caching
stub resolvers like the GNU libc resolver.

However, we're working on a solution.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

[Florian Weimer]

* Aurelien Jarno:

 IMHO, the UDP randomization commit has to be backported to the etch
 kernel. The advantage of this solution, is that it potentially fixes
 other bugs/vulnerabilities in other protocols/programs using UDP.

Currently, there is no suitable patch to backport.  I hope that improved
port randomization will be available shortly.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

[Florian Weimer]

* Aurelien Jarno:

 Currently, there is no suitable patch to backport.  I hope that improved
 port randomization will be available shortly.

 You mean a patch for the kernel?

Yes, one for the kernel, and one for the transaction ID generation in
the libc resolver, too.

(Oh, and shortly == next week or so.)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

[Florian Weimer]

reopen 491809
thanks

* Pierre Habouzit:

   Kaminsky agrees confirm the issue, so I can say for sure that the
 glibc isn't vulnerable to the attack he describes, as it needs a
 resolver that caches additionnal RRs, which the glibc doesn't do.

   As of attacks that would use non randomized source port use, this is
 addressed by recent kernels hence is fixed enough.

I've trouble parsing what you wrote.

Based on information provided at the DNS summit, I do think we should
harden the glibc stub resolver.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#382175: Sun RPC libraries and other stories

[Florian Weimer]

* Simon Phipps:

 On Nov 5, 2008, at 23:23, Michael Banck wrote:

 - portmap.c

 /*
 @(#)portmap.c   2.3 88/08/11 4.0 RPCSRC
 static char sccsid[] = @(#)portmap.c 1.32 87/08/06 Copyr 1984 Sun
 Micro;
 */

 This is portmap-6.0, from http://neil.brown.name/portmap/

 Is this in any way related to any Sun code, or is the string simply
 used by the author for external reference in some way?

It seems that the code was released by the Portable NFS group at Sun
in 1987:

  http://ftp.andrew.cmu.edu/pub//AUIS/src/contrib/mit/fxlib/rpc3.9/

(portmap.c is in etc.  Ah, those were the times!)

The distribution above was apparently intended for use on 4BSD.  This
might explain why it does not match a code base derived from SunOS 5.

An announcement of the release was re-posted to Usenet in a digest
with message ID [EMAIL PROTECTED].



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#382175: Sun RPC libraries and other stories

[Florian Weimer]

* Simon Phipps:

 On Nov 18, 2008, at 03:52, Ben Hutchings wrote:

 Many of the functions in portmap.c seem to correspond to
 rpcbind (usr/src/cmd/rpcbind) in OpenSolaris:

 Is it just the function prototypes that are derived, or is there
 derived source defining them too?

From our portmap.c:

| /*
|  * Stuff for the rmtcall service
|  */
| #define ARGSIZE 9000
|
| struct encap_parms {
| u_int arglen;
| char *args;
| };
|
| static bool_t
| xdr_encap_parms(XDR *xdrs, struct encap_parms *epp)
| {
|
| return (xdr_bytes(xdrs, (epp-args), (epp-arglen), ARGSIZE));
| }
|
| struct rmtcallargs {
| u_long  rmt_prog;
| u_long  rmt_vers;
| u_long  rmt_port;
| u_long  rmt_proc;
| struct encap_parms rmt_args;
| };
|
| static bool_t
| xdr_rmtcall_args(XDR *xdrs, struct rmtcallargs *cap)
| {
|
| /* does not get a port number */
| if (xdr_u_long(xdrs, (cap-rmt_prog)) 
| xdr_u_long(xdrs, (cap-rmt_vers)) 
| xdr_u_long(xdrs, (cap-rmt_proc))) {
| return (xdr_encap_parms(xdrs, (cap-rmt_args)));
| }
| return (FALSE);
| }
|
| static bool_t
| xdr_rmtcall_result(XDR *xdrs, struct rmtcallargs *cap)
| {
| if (xdr_u_long(xdrs, (cap-rmt_port)))
| return (xdr_encap_parms(xdrs, (cap-rmt_args)));
| return (FALSE);
| }
| 
| /*
|  * only worries about the struct encap_parms part of struct rmtcallargs.
|  * The arglen must already be set!!
|  */
| static bool_t
| xdr_opaque_parms(XDR *xdrs, struct rmtcallargs *cap)
| {
| 
| return (xdr_opaque(xdrs, cap-rmt_args.args, cap-rmt_args.arglen));
| }

From 
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/rpcbind/rpcb_svc_com.c:

| /*
|  * Stuff for the rmtcall service
|  */
| struct encap_parms {
|   ulong_t arglen;
|   char *args;
| };
|
| static bool_t
| xdr_encap_parms(xdrs, epp)
|   XDR *xdrs;
|   struct encap_parms *epp;
| {
|   return (xdr_bytes(xdrs, (epp-args), (uint_t *)(epp-arglen), ~0));
| }
|
|
| struct r_rmtcall_args {
|   ulong_t rmt_prog;
|   ulong_t rmt_vers;
|   ulong_t rmt_proc;
|   int rmt_localvers;  /* whether to send port # or uaddr */
|   char*rmt_uaddr;
|   struct encap_parms rmt_args;
| };
|
| /*
|  * XDR remote call arguments.  It ignores the address part.
|  * written for XDR_DECODE direction only
|  */
| static bool_t
| xdr_rmtcall_args(xdrs, cap)
|   register XDR *xdrs;
|   register struct r_rmtcall_args *cap;
| {
|   /* does not get the address or the arguments */
|   if (xdr_u_long(xdrs, (cap-rmt_prog)) 
|   xdr_u_long(xdrs, (cap-rmt_vers)) 
|   xdr_u_long(xdrs, (cap-rmt_proc))) {
|   return (xdr_encap_parms(xdrs, (cap-rmt_args)));
|   }
|   return (FALSE);
| }
|
| /*
|  * XDR remote call results along with the address.  Ignore
|  * program number, version  number and proc number.
|  * Written for XDR_ENCODE direction only.
|  */
| static bool_t
| xdr_rmtcall_result(xdrs, cap)
|   register XDR *xdrs;
|   register struct r_rmtcall_args *cap;
| {
|   bool_t result;
|
| #ifdef PORTMAP
|   if (cap-rmt_localvers == PMAPVERS) {
|   int h1, h2, h3, h4, p1, p2;
|   ulong_t port;
|
|   /* interpret the universal address for TCP/IP */
|   if (sscanf(cap-rmt_uaddr, %d.%d.%d.%d.%d.%d,
|   h1, h2, h3, h4, p1, p2) != 6)
|   return (FALSE);
|   port = ((p1  0xff)  8) + (p2  0xff);
|   result = xdr_u_long(xdrs, port);
|   } else
| #endif
|   if ((cap-rmt_localvers == RPCBVERS) ||
|   (cap-rmt_localvers == RPCBVERS4)) {
|   result = xdr_wrapstring(xdrs, (cap-rmt_uaddr));
|   } else {
|   return (FALSE);
|   }
|   if (result == TRUE)
|   return (xdr_encap_parms(xdrs, (cap-rmt_args)));
|   return (FALSE);
| }
| 
| /*
|  * only worries about the struct encap_parms part of struct r_rmtcall_args.
|  * The arglen must already be set!!
|  */
| static bool_t
| xdr_opaque_parms(xdrs, cap)
|   XDR *xdrs;
|   struct r_rmtcall_args *cap;
| {
|   return (xdr_opaque(xdrs, cap-rmt_args.args, cap-rmt_args.arglen));
| }

So there's certainly some overlap, and it's not just prototypes.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#519774: libc6: causes many programs not to be able to resolve dns addresses

[Florian Weimer]

* Mark Kamichoff:

 Hi - 

 The problem is that the DNS server of your ISP does not conform to the
 RFC and only answer to the  query with a void answer. It never
 answer to the A query, so the glibc resolver can only conclude the
 whole query has no answer.

 Just a thought, many DNS ALGs on firewalls (eg, Juniper NetScreen) will
 close the UDP/53 session after one packet (response, presumably) is
 received, and drop any subsequent response packets.

This will break other clients, too.  For instance, a BIND forwarder
without source port randomization, who happens to have multiple
queries in flight.

Has it been verified that the second DNS packet actually leaves the
box?  I think there was word of a kernel bug leading to dropped UDP
packets which might cause this.



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#414795: libpthread/NPTL: static linking seems to break raise(3), abort(3)

[Florian Weimer]

* Alex Pennace:

 A program that is statically linked to NPTL will fail at runtime when
 calling raise(3) (and, by extension, abort(3)): 

Statically linked executables simply do not support NPTL.  If
possible, a link-time warning should be generated, perhaps even an
error.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#414795: libpthread/NPTL: static linking seems to break raise(3), abort(3)

[Florian Weimer]

* Alex Pennace:

 Is it the case that NPTL's design critera explicitly excluded static
 linking, or is that facility a work in progress?

libc as a whole doesn't really support static linking anymore.  For
instance, gethostbyaddr and friends only work with the exact libc
version you linked statically against (because at run time, code must
be loaded dynamically).

 What does POSIX have to say about supporting static linking?

Nothing, it's beyond its scope.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#414795: libpthread/NPTL: static linking seems to break raise(3), abort(3)

[Florian Weimer]

* Daniel Jacobowitz:

 Statically linked executables simply do not support NPTL.  If
 possible, a link-time warning should be generated, perhaps even an
 error.

 Actually, I don't know that this is correct.

Several mailing list postings strongly suggest that this is upstream's
position.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#416442: libc6: Wrong groups applied to user

[Florian Weimer]

* Fabio Pugliese Ornellas:

 However, the bigger group name has 26 char only (as you can see on
 previous mesage)... still under 32. Should work, right?

You're hitting the total number of groups limit.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed

[Florian Weimer]

* Sven Luther:

 As said, i see this on both an x86 box and my powerbook, but the complete code
 is more involved, having a pselect, as well as a SIGALRM handler, which both
 trigger the localtime_r, as well as a postgresql access and files access.

localtime_r is not async-signal-safe, so this could be a bug in your
program.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed

[Florian Weimer]

* Sven Luther:

 On Thu, Apr 05, 2007 at 08:46:08AM +0200, Florian Weimer wrote:
 * Sven Luther:
 
  As said, i see this on both an x86 box and my powerbook, but the complete 
  code
  is more involved, having a pselect, as well as a SIGALRM handler, which 
  both
  trigger the localtime_r, as well as a postgresql access and files access.
 
 localtime_r is not async-signal-safe, so this could be a bug in your
 program.

 Ok, i will give a try of using just localtime.

localtime is not async-signal-safe, either.  A full list of such
functions is contained in the POSIX standard and probably the GNU libc
documentation as well.

 I thought it may be something such, but maybe the error message
 could be made something more explicit ?

You are asking for a general detection mechanism for race conditions,
which is not really feasible for production code.

 I guess the assertion is to check if more than one version of
 localtime_r is working then ?

If you invoke a function which is not async-signal-safe from a signal
handler, all bets are off.  That sanity check doesn't check for the
race condition, it merely catches the inconsistency caused by it (from
time to time).

(All this assumes that your bug is caused by improper use of a signal
handler.  Keep in mind that this is not necessarily the case.  But you
should fix that aspect of your code nevertheless.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#417815: libc6: localtime dies with : tzfile.c:544: __tzfile_compute: Assertion `num_types == 1' failed

[Florian Weimer]

* Sven Luther:

 Yes, i use localtime / getoftime / time from the signal handler, yes, i guess
 that is causing the problem i m seeing. Need to find another way to find the
 time from a handler.

 maybe using the timer_create thingy, but it is also undocumented.

timer_gettime is async-signal-safe according to POSIX.  Perhaps
gettimeofday is as well, as a GNU extension.

Another option is to spawn a separate thread which handles all the
signals.  Then you aren't restricted to the small set of
async-signal-safe functions (and you can use third-party libraries as
well).  Most non-C programming environments use this approach.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#419012: /lib/ld-2.5.so: Conditional jump or move depends on uninitialised value(s)

[Florian Weimer]

severity 419012 normal
tags 419012 - security
reassign 419012 valgrind
thanks

* Tobias Schlemmer:

 valgrind reports jumps depending on uninitialized valuse in
 /lib/ld-2.5.so. I found this bug using some gfortran 4.2, but I get it
 also using the standard gcc package (version 4:4.1.1-15). 

This just means that valgrind needs a new exception file for libc 2.5.
Are you sure that you are running the latest version?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#420301: libc6: IPv6 transport fails for resolver

[Florian Weimer]

* Tim:

 Is there anything I can do to debug this directly on my system?  I don't
 see anything in my system logs, which I didn't really expect to.

strace output might help to diagnose this.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#679828: libc6: No easy way of enabling DNSSEC validation aka RES_USE_DNSSEC

[Florian Weimer]

* Matthew Grant:

 From my investigations this can only be enabled by recompiling each bit
 of software to set the RES_USE_DNSSEC flag in _res.options, as well as
 RES_USE_EDNS0. (Please see racoon bug #679483).  The enablement method
 is from openssh 6.0p1, openbsd-compat/getrrsetbyname.c 

This does not actually activate DNSSEC, it just tells the recursive
resolver that the application is able to process DNSSEC records.  The
application would still have to validate them.

Applications should never need to set the RES_USE_DNSSEC flag because
it does not make sense to treat DNSSEC-signed data differently from
unsigned data.

 Please create a resolv.conf flag so that RES_USE_DNSSEC is available
 to the systems administrator, and maybe a debconf screen to select it.

This alone wouldn't make any difference to the spoofing problem.

libc is not the correct place to put DNSSEC validation because many
processes are shortlived and would have to fetch all key material and
signatures from DNS, beginning at the root.  This would turn a single
name resolution into six or more DNS queries, which is excessive.

At this stage, you should run a BIND or Unbound process restricted to
localhost which performs the validation.  This validation will happen
even for applications which do not set the RES_USE_DNSSEC flag.



-- 
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/87sjdau1uj@mid.deneb.enyo.de

Bug#162576: marked as done (libc6-dev: errno is a function call in non-threaded program)

[Florian Weimer]

Herbert Xu [EMAIL PROTECTED] writes:

 Florian Weimer [EMAIL PROTECTED] wrote:
 
 The slowdown is a price to be paid, otherwise we would need a
 different set of almost all shared libraries for linking with
 multi-threading programs.  I think we already had this situation, and
 it wasn't nice at all.

 No you don't, all you need to do is to make the errno macro
 conditional.

And if we do that, libraries which use the non-macro version will come
into existence sooner or later, and we lose.

-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#166543: libc6-dev: using GCC pow(x,y); does not compile.

[Florian Weimer]

Jouko Kivilahti [EMAIL PROTECTED] writes:

 Using pow(x,y); at source does not compile

But it does!

 $ gcc a.c
 /tmp/cc2ik7lo.o(.text+0x1f): In function `main':
 : undefined reference to `pow'
 collect2: ld returned 1 exit status

This is a linker error message.  You have to link against libm, by
invoking gcc with the -lm parameter.

-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#166543: libc6-dev: using GCC pow(x,y); does not compile.

[Florian Weimer]

Jouko Kivilahti [EMAIL PROTECTED] writes:

 Using pow(x,y); at source does not compile

But it does!

 $ gcc a.c
 /tmp/cc2ik7lo.o(.text+0x1f): In function `main':
 : undefined reference to `pow'
 collect2: ld returned 1 exit status

This is a linker error message.  You have to link against libm, by
invoking gcc with the -lm parameter.

-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898

Bug#181493: Is the Sun RPC License DFSG-free?

[Florian Weimer]

Andrew Suffield [EMAIL PROTECTED] writes:

 On Fri, Aug 22, 2003 at 06:39:47AM +, Brian M. Carlson wrote:
   Sun RPC is a product of Sun Microsystems, Inc. and is
   provided for unrestricted use provided that this legend is
   included on all tape media and as a part of the software
 ^^

 That seems worse than the advertising clause.

I'm not sure if they actually want you to print the notice on the
cartridge.  But the license doesn't permit non-developers (mirror
admins, for example) to distribute the code.

Has anybody asked Sun for a clarification of the license, or tried to
obtain the code under a different license?  Or maybe the FSF has
obtained a suitable license and just forgot to update the copyright
notice?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#296490: libc6: getgrnam segfault (using __nscd_getgrnam_r)

[Florian Weimer]

* Tom Parker:

 Calling getgrnam() with a NULL argument, with group in
 /etc/nsswitch.conf set to 'compat' can cause a segfault in
 __nscd_getgrnam_r due to a lack of a check for a NULL string before
 doing strlen().

Is there any standard that defines the behavior of getgrnam(NULL)?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap

[Florian Weimer]

* Vesselin Peev:

 #include netdb.h
 int main()
 {
   gethostbyname(www.google.com);
   return 0;
 }

 number of leaked objects: 49

This is not a problem, unless this number grows with each
gethostbyname invocation.  The underlying programming pattern which
causes this is quite common and perfectly harmless (if you get the
threading issues right, of coruse).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap

[Florian Weimer]

* Vesselin Peev:

 This is not a problem, unless this number grows with each
 gethostbyname invocation.  The underlying programming pattern which
 causes this is quite common and perfectly harmless (if you get the
 threading issues right, of coruse).

 Just tested it in a loop, the leaks stay constant.

Fine, thanks.

 If you are saying the underlying programming pattern is quite common
 and harmless, that does not also mean that the leaks are
 non-existent and mudflap is confused, right?

Yes.  AFAIK, mudflap does not perform pointer tracing (unlike
valgrind).  Therefore, it cannot detect if heap objects which are
allocated when the program terminates are still reachable, which is
the case here.

 Could you please elucidate what is this programming pattern that
 causes the leaks, if it is possible to do with a programming
 snippet?

A variable at global scope which points to an object allocated on the
heap, for example:

  static char *name = NULL;

  void
  set_name (char *n)
  {
free (name);
name = strdup (n);
  }

There's no need to free name at program termination because the kernel
will do it for you anyway.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap

[Florian Weimer]

* Vesselin Peev:

 I'm thinking of submitting a wish about better handling,

You could reuse this bug report (downgrade it to wishlist, reassign if
necessary).

 if possible with the mudflap architecture, of internal data
 allocated by libc. Proper handling should of course include no
 unaccessed registered object warnings. Barring that, I'd request a
 mudflap option to suppress those warnings. What would you advise me?

Mudflap needs some GNU libc interface to do this. __libc_freeres looks
very internal.  It's not documented, either.  I believe it can go away
in the next release.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#326832: libc6: valgrind reports use of uninitialized values

[Florian Weimer]

reassign 326832 valgrind
thanks

* Justin Pryzby:

 valgrind reports 13 instances of Conditional jump or move depends on
 uninitialised value(s) using the new libc6 in testing, for a trivial
 program which just calls exit(0).  This is valgrind-2.4.0-3.

This means that the valgrind suppression files are out of date.
Unless you've actual evidence that these are bugs, this should be
fixed in valgrind.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#335476: nscd: Caches old IP-address

[Florian Weimer]

* Dave Love:

 Yes, please turn off the default persistent caching of hosts (at
 least).  I think this should also be done upstream.  It can lead to
 lockout of logins in an obscure fashion -- at least it did on Fedora
 systems running what appears to be the same version of nscd with the
 same defaults, so presumably Debian would be subject to the same
 lossage.

The current code tries to honor TTLs.  It might be sufficient to set a
zero (or very low) TTL for entries coming from /etc/hosts.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#335476: nscd: Caches old IP-address

[Florian Weimer]

* Dave Love:

 Florian Weimer [EMAIL PROTECTED] writes:

 The current code tries to honor TTLs.  It might be sufficient to set a
 zero (or very low) TTL for entries coming from /etc/hosts.

 Does `current' mean in the latest Debian package?

Yes.

 I can't see anything relevant in the changelog, and the Fedora
 version definitely didn't time out.

Which GNU libc version is in Fedora?  2.3.5?

There is quite a bit of code to handle TTLs for records fetched from
DNS in version 2.3.5.  Don't they expire for you, either?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Security-related patches for wheezy (and squeeze LTS)

[Florian Weimer]

I would like to send a few security-related backports frpm upstream
your way.  On the security side, we won't do a DSA for any of those
(probably; I still haven't got a complete handle on what's missing).
But it's certainly wheezy-updates material.

Should I just send the patches, or do you want diffs against the
repository?

Can we maintain the LTS versions in your Subversion repository, too?


-- 
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/874mwsze75@mid.deneb.enyo.de

Bug#717544: CVE-2013-2207: Remove pt_chown

[Florian Weimer]

* Samuel Thibault:

 Hello,

 Florian Weimer, le Thu 06 Aug 2015 07:15:01 +0200, a écrit :
 retitle 717544 CVE-2013-2207: Remove pt_chown
 thanks
 
 Can we please make another attempt at removing pt_chown, either
 completely or by removing the SUID bit?

 On linux ports only, please, kfreebsd and hurd still need it.  Removing
 pt_chown breaks 'screen' for instance.

Noted.

I really want to make this change, though, and push it to
stable/oldstable eventually.  What needs to happen for that?

Bug#717544: CVE-2013-2207: Remove pt_chown

[Florian Weimer]

retitle 717544 CVE-2013-2207: Remove pt_chown
thanks

Can we please make another attempt at removing pt_chown, either
completely or by removing the SUID bit?  The current devpts file
system is set up in such a way that this is not necessary.  Fedora and
Red Hat Enterprise Linux 7 already ship without pt_chown, apparently
without ill effects.  The Debian software I have checked sets up
/dev/pts with the gid=5 option, which means that pt_chown should be
unnecessary as well.

We also need to get this change into stable, maybe even oldstable.


-- 
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/87lhdpf162@mid.deneb.enyo.de

Bug#802256: Backport tls_dtor_list hardening

[Florian Weimer]

Package: libc6
Version: 2.19-18+deb8u1

Please backport this upstream hardening patch to jessie (wheezy does
not have this feature yet):

  https://sourceware.org/bugzilla/show_bug.cgi?id=19018
  
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f586e1328681b400078c995a0bb6ad301ef73549

Also recommended for testing purposes:

  
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=99e1dc0a688d6c25d3f422bc9f3fa29adb483339

Thanks,
Florian

Bug#815974: Segmentation fault in libresolv triggered by php5-fpm

[Florian Weimer]

* Aurelien Jarno:

> On 2016-02-26 13:31, Carlos O'Donell wrote:
>> On Fri, Feb 26, 2016 at 7:46 AM, Fabian Niepelt  
>> wrote:
>> > This is the correct output, the older one contains a test I thought was
>> > in an endless loop but succeeded after a few minutes.
>> 
>> The glibc maintainers for debian need to review those failures. They
>> indicate serious deviation from expected behaviour. At the very least
>> the bug 18665* tests should not fail. However, the tests are sensitive
>> to response order.
>> 
>> -address: STREAM/TCP 10.0.3.6 80
>> -address: STREAM/TCP 2001:db8::4:6 80
>> +error: Name or service not known
>> 
>> This is a weird failure.
>
> The failures in this testsuite do not pass due to the patch we have that
> dynamically reloads /etc/resolv.conf when it changes. Just after the
> fake servers have been initialized, our libc reloads the configuration
> from /etc/resolv.conf, and thus the tests fail. Once removing the
> corresponding patch the tests pass, at least on my system.

Correct, the version Carlos posted does not have the compensation I
added for that, sorry.  I added this after the call to res_init in
resolv_redirect:

  /* Debian's local-dynamic-resolvconf.diff breaks name server
 overrides by application code.  The following triggers lazy
 initialization of the /etc/resolv.conf mtime value because
 res_mkquery calls __res_maybe_init internally.  Subsequent calls
 to this function will not try reload /etc/resolv.conf as a
 result.  */
  {
unsigned char query[512];
if (res_mkquery (QUERY, "query.example", C_IN, T_A,
 NULL, 0, NULL,
 query, sizeof (query)) < 0)
  {
printf ("error: res_mkquery: %m\n");
abort ();
  }
  }


> IMHO making sure that programs are restarted after applying the security
> update should be enough, but I am not fully sure about my analysis, so a
> confirmation would be nice to have.

This report 
is about an incomplete chroot update.  See comment 4 in particular
(although I wrote it without access to the actual installation).

Bug#783210: [PATCH] nscd_stat.c: make the build reproducible

[Florian Weimer]

On 03/09/2016 05:30 PM, Mike Frysinger wrote:


would it be so terrible to properly marshall this data ?


Ximin Luo and I discussed this and I wonder if it is possible to read 
out the libc.so.6 build ID if it is present.  It should indirectly call 
all the layout dependencies and be reasonably easy to access because it 
is in an allocated section (and we might want to print it from an 
libc.so.6 invocation, too).


We still need the time-based approach if the build ID is not available, 
but I expect most distributions will have something like it.


The Debian bug is:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783210

(Also Cc:ed)

Florian

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

[Florian Weimer]

* Fernando Santagata:

> One month ago everything worked fine on my Debian sid computer.
> After an update/dist-upgrade cycle in which libc6 was updated I
> started noticing some malfunctions.

Did you upgrade the kernel at the same time?

Re: segfault in errx

[Florian Weimer]

* Florian Weimer:

>> I can reproduce something like this with 2.24-3 on amd64.  valgrind
>> isn't very helpful.
>
> And it needs a UTF-8 locale (C.UTF-8 will do).  Another multi-byte
> locale may work as well.

Bisecting this with the attached script leads to:

commit 18d26750dd8fd328a78cf639fd0ec2494680a2a4
Author: Paul Pluzhnikov <ppluzhni...@google.com>
Date:   Sun Mar 8 09:46:53 2015 -0700

Cleanup: in preparation for fixing BZ #16734, fix memory leaks exposed by
switching fopen()ed streams from mmap to malloc.

This commit has shown up in other context as well:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=20598>

#!/bin/bash

set -x

unset LANG LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY \
  LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT \
  LC_IDENTIFICATION LC_ALL

fatal () {
exit 255
}

skip () {
exit 255
}

run () {
GCONV_PATH=./iconvdata LOCPATH=. ./elf/ld-linux-x86-64.so.2 --library-path 
.:./math:./elf:./dlfcn:./nss:./nis:./rt:./resolv:./crypt:./mathvec:./nptl "$@"
}

cd ../build || fatal
rm -rf ../build/* || fatal
../git/configure --prefix=/usr --disable-werror || skip
make -j12 || skip
run locale/localedef -f ../git/localedata/charmaps/UTF-8 -i 
../git/localedata/locales/en_US "$PWD/en_US.UTF-8" || skip
LC_ALL=en_US.UTF-8 run /usr/bin/ul /tmp/ul.segf
case $? in
1)
exit 0
;;
139)
exit 1
;;
*)
fatal
;;
esac

Bug#824429: libc6: In certain locale combinations mbsrtowcs cannot recover from EILSEQ

[Florian Weimer]

tags 824429 upstream
forwarded 824429 https://sourceware.org/bugzilla/show_bug.cgi?id=20617
thanks

* Christoph Biedl:

> It might be questionable whether this is a bug in glibc at all. But at
> least it's surprising behaviour.
>
> The reproducer below calls mbstowcs two times, first time with
> an illegal UTF-8 sequence, second time a correct one.
>
> Now if the caller's environment is set to something UTF-8-ish like
> "en_US.UTF-8" or "de_DE.UTF-8", also the second and any further
> mbsrtowcs invocation fail with EILSEQ. Note setting LC_CTYPE to an
> empty string is also required to make this happen.

POSIX and C11 explicitly say that the conversion state is undefined
after EILSEQ.  There does not appear to be a way to reset the internal
(global) conversion state used by mbsrtowcs, so a NULL argument for
the conversion state pointer is rarely useful.  We should probably add
a warning in glibc for that case.

Filed upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=20617

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

[Florian Weimer]

* Aurelien Jarno:

> On 2016-09-27 13:44, Florian Weimer wrote:
>> * Aurelien Jarno:
>> 
>> > Hmm, rsync doesn't use libpthread, so that clearly rules out a
>> > libpthread issue. That said, all the example you gave fail to allocate
>> > the memory correctly, either through malloc (glibc) or mmap (kernel)
>> > which returns -ENOMEM. This points to either a kernel issue, or a
>> > limitation of the memory using for example ulimit.
>> 
>> The mm subsystem in the 4.7 upstream kernel has a very visible issue
>> which causes allocation failures:
>> 
>>   <http://marc.info/?l=linux-mm=147422898523307>
>>
>> There are other threads as well.  (I personally see this with the
>> xfs_inode cache.)
>> 
>> Usually it manifests in premature OOM killer invocations, but maybe
>> something the reporter's system configuration changes that (perhaps it
>> runs with vm.overcommit_memory=2?).
>  
> Indeed, that is correct. The problem has been fixed in version 4.7.5,
> while the reporter seems to run version 4.7.4. Upgrading to the latest
> kernel version would be a good start.

I don't think this has been fully fixed in 4.7.5.  I'm running that
version now, and with lots of xfs_inode objects, I observe basically
zero read-ahead, which results in stuttering media playback with
ogg123.  vm.drop_caches=3 makes the stuttgering go away.

I need to see if I can still reproduce the OOMs.  This was a bit
tricky before.

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

[Florian Weimer]

* Fernando Santagata:

>> Usually it manifests in premature OOM killer invocations, but maybe
>> something the reporter's system configuration changes that (perhaps it
>> runs with vm.overcommit_memory=2?).
>
> That's it. I found this in /var/log/kern.log at the time I run a program
> that crashed:
>
> Sep 27 10:37:31 gretux kernel: [ 77.250470] mmap: moar (2564): VmData
> 135217152 exceed data ulimit 134217728. Update limits or use boot
> option ignore_rlimit_data.

No, I think the above is unrelated.  It relates to a userspace ABI
break related to the RLIMIT_DATA implementation.

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

[Florian Weimer]

* Aurelien Jarno:

> Hmm, rsync doesn't use libpthread, so that clearly rules out a
> libpthread issue. That said, all the example you gave fail to allocate
> the memory correctly, either through malloc (glibc) or mmap (kernel)
> which returns -ENOMEM. This points to either a kernel issue, or a
> limitation of the memory using for example ulimit.

The mm subsystem in the 4.7 upstream kernel has a very visible issue
which causes allocation failures:

  

There are other threads as well.  (I personally see this with the
xfs_inode cache.)

Usually it manifests in premature OOM killer invocations, but maybe
something the reporter's system configuration changes that (perhaps it
runs with vm.overcommit_memory=2?).

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Florian Weimer]

* Richard Laager:

> Getting back to ZFS and /etc/hostid... I would think that a
> randomly-generated /etc/hostid is probably sufficient. Whether that's
> done in the libc, spl, or zfs package makes no difference to me.

As I tried to explain, the risks of collisions without central
coordination looks rather high.  glibc's current approach, using the
IP address associated with the host name, provides a certain level of
coordination, avoiding duplicates.

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Florian Weimer]

* Michael Stone:

> Other platforms have deprecated gethostid, that's the best way forward
> for linux, IMO.

I agree.  It's the most likely outcome if this issue was reported to
glibc upstream.

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Florian Weimer]

* Petter Reinholdtsen:

> [Florian Weimer]
>> That's not very different from /etc/machine-id, isn't it?
>
> Ah, thank you very much for bringing this systemd setting to my
> attention.  I was not aware of it.
>
> I agree that it seem very similar in purpose and implementation.  Will
> it be available on non-linux Debian architectures too?

It might be possible to port over this part, yes.

>>> We need to figure out how to transform the UUID to a 32 bit integer,
>>> of course.
>>
>> And I think this is the crux of the problem.  Whatever we do, with
>> today's cluster sizes it's just not reliably unique.
>
> Well, for the set of machines we have available at work (ca. 3000) it
> would be sufficiently unique.

I simulated 100,000 random assigns of 32-bit host IDs to 3,000 hosts,
and got collisions in 104 cases.

For 5,000 hosts, I got 286, and for 10,000, 1,112 (again in 100,000
runs).  I was lazy, it shouldn't be too hard to calculate expected
values accurately.

So a 32-bit value without central coordination is pretty much a time
bomb.

> For most sites it would make the return value from gethostid()
> unique.

The IP address of a host could be better than that.  I doubt it is
possible to imrpove upon the glibc implementation.

>> DMI data seems risky because it depends on firmware, and there are so
>> many firmware bugs out there.
>
> I did not quite understand what you mean here.  Do you mean the DMI
> value in your experience isn't unique?

I wouldn't count on them being unique.  Most such ID fields are
definitely not, and there are groups out there who strongly oppose
device IDs.

Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Florian Weimer]

* Petter Reinholdtsen:

> Something like this should work, I guess:
> 
> if [ ! -f /etc/hostid ]; then
>if [ -e /sys/class/dmi/id/product_uuid ]; then
>sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid)
>else
>   dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null
>fi
> fi

That's not very different from /etc/machine-id, isn't it?

> We need to figure out how to transform the UUID to a 32 bit integer,
> of course.

And I think this is the crux of the problem.  Whatever we do, with
today's cluster sizes it's just not reliably unique.

You could use /etc/machine-id instead.  Some effort goes into that to
make it actually unique.

DMI data seems risky because it depends on firmware, and there are so
many firmware bugs out there.  It would also not address the matter of
changing host IDs as the result of host migrations.

Re: segfault in errx

[Florian Weimer]

* Michael Meskes:

> I recently learned that ul (from bsdmainutils) segfaults when run
> against the attached file. Some debugging shows that the segfault
> happens when cleaning up in errx():
>
> michael@feivel:~$ ul ul.segf 
> ul: unknown escape sequence in input: 33, 135
> Speicherzugriffsfehler

What's the glibc version and architecture?

I can reproduce something like this with 2.24-3 on amd64.  valgrind
isn't very helpful.

ul: unknown escape sequence in input: 33, 135
==16450== Conditional jump or move depends on uninitialised value(s)
==16450==at 0x52A9A63: utf8_internal_loop (loop.c:298)
==16450==by 0x52A9A63: __gconv_transform_utf8_internal (skeleton.c:609)
==16450==by 0x52F26CD: do_length (iofwide.c:463)
==16450== 
==16450== Jump to the invalid address stated on the next line
==16450==at 0x0: ???
==16450==by 0x4224167: ???
==16450==by 0x4024537: ???
==16450==by 0x5833A3F: ???
==16450==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16450== 
==16450== 
==16450== Process terminating with default action of signal 11 (SIGSEGV)
==16450==  Bad permissions for mapped region at address 0x0
==16450==at 0x0: ???
==16450==by 0x4224167: ???
==16450==by 0x4024537: ???
==16450==by 0x5833A3F: ???
==16450== Jump to the invalid address stated on the next line
==16450==at 0x0: ???
==16450==by 0x42239D7: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==16450==by 0x4025477: ???
==16450==by 0x5833A3F: ???
==16450==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16450== 
==16450== 
==16450== Process terminating with default action of signal 11 (SIGSEGV)
==16450==  Bad permissions for mapped region at address 0x0
==16450==at 0x0: ???
==16450==by 0x42239D7: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==16450==by 0x4025477: ???
==16450==by 0x5833A3F: ???

I'll have to try this on a distribution with better debugging
information.

Re: segfault in errx

[Florian Weimer]

* Florian Weimer:

> * Michael Meskes:
>
>> I recently learned that ul (from bsdmainutils) segfaults when run
>> against the attached file. Some debugging shows that the segfault
>> happens when cleaning up in errx():
>>
>> michael@feivel:~$ ul ul.segf 
>> ul: unknown escape sequence in input: 33, 135
>> Speicherzugriffsfehler
>
> What's the glibc version and architecture?
>
> I can reproduce something like this with 2.24-3 on amd64.  valgrind
> isn't very helpful.

And it needs a UTF-8 locale (C.UTF-8 will do).  Another multi-byte
locale may work as well.

> I'll have to try this on a distribution with better debugging
> information.

Not much luck on Fedora, either.

Based on what ul does, I suspect it's this upstream bug:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=20568>

Or perhaps this one:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=20632>

Bug#839280: libc6: asprintf(, "%F", 1.0) puts 0.00000 in c on raspberry pi zero v1.3.

[Florian Weimer]

* Noah Williams:

>* What led up to the situation? I was building a robot, and needed a 
> raspberry pi zero to send a floating point number formatted as a string to an 
> arduino.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? I've tried passing bigger numbers than 1.0 (like 100.0) , 
> but it didn't seem to do anything different, "%F %F" does however seem to get 
> the second argument right.
>* What was the outcome of this action? It printed out something like: 
> -0.1 1.0 
>* What outcome did you expect instead? 1.0 0.0

Please post complete, minimal source code, along with a description
how you compiled your program (and for what architecture).  Thanks.

Bug#858529: libc6: fgets repeats content after fork on stretch only

[Florian Weimer]

tags 858529 upstream
forwarded 858529 https://sourceware.org/bugzilla/show_bug.cgi?id=20598
thanks

* Neil Spring:

>   if(fork() == 0) { exit(1); }

exit flushes the stdio buffers in the child.  Upstream concluded that
this leads to undefined behavior:

| Yes, this is about the exit actually.  But reading "2.5.1
| Interaction of File Descriptors and Standard I/O Streams", I think
| this is really undefined, because the required action is not
| performed before the call to fork, and the correct fix is to use
| _exit in the forked child.

Bug#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid

[Florian Weimer]

* John Paul Adrian Glaubitz:

> I would suggest filing a bug report to glibc upstream or posting on
> their mailing list to ask for feedback.

Upstream has since removed the PID cache:

  
  

Bug#879093: Segfault in libc6 while using xrdp-sesman on Stretch

[Florian Weimer]

* Gilles MOREL:

> I repported this bug for the package libc6 because the kernel line let
> me think the problem comes from libc6.

It's much more likely that xrdp-sesman calls a glibc function on an
invalid pointer.

> If you want me to provide more log or debugging, please tell me, I
> don't really understand the problem.

You will have to provide a backtrace at least, with debugging symbols
installed.  If you can reproduce the issue on buster, getting
debugging symbols may be easier (I don't know what the current state
of automatic debugging information packaging is on Debian).  Note that
you'll have to install packages with the debugging information for
xrdp-sesman and all its dependencies, not just libc6.

Bug#897373: libc6: feof(file) always false when forking after read

[Florian Weimer]

* David Beniamine:

> int do_fork() {
> pid_t pid;
>
> switch (pid = fork()) {
> case -1:
> fprintf(stderr, "Fork failed\n");
> return -1;
> case 0:
> exit(-1);

Does the issue go away when you call _exit instead of exit?

Bug#897373: libc6: feof(file) always false when forking after read

[Florian Weimer]

* David Beniamine:

> On Thu, May 10, 2018 at 07:06:03PM +0200, Florian Weimer wrote:
>> * David Beniamine:
>> 
>> > int do_fork() {
>> > pid_t pid;
>> >
>> > switch (pid = fork()) {
>> > case -1:
>> > fprintf(stderr, "Fork failed\n");
>> > return -1;
>> > case 0:
>> > exit(-1);
>> 
>> Does the issue go away when you call _exit instead of exit?
>> 
> It goes away with _exit, indeed.

According to POSIX, exit is required to flush all streams, and fflush
is required to reset the position of the underlying file descriptor
(more precisely, the open file description) to the current read
position.  That affects the descriptor in the parent, too.  I'm not
sure if this is actually a glibc bug.

Bug#620887: Please add a shm_mkstemp() function

[Florian Weimer]

On 05/16/2018 10:25 PM, Jakub Wilk wrote:

* Goswin von Brederlow , 2011-04-04, 23:33:

int shm_mkstemp(char *template);


FWIW, this function is available on OpenBSD:
https://man.openbsd.org/shm_mkstemp.3


We have memfd_create nowadays.  It's not exactly identical because it 
creates an unnamed file, but perhaps it is close enough?  If not, we'd 
need actual use cases to justify to add it to glibc.


Thanks,
Florian

Bug#900025: /usr/lib/x86_64-linux-gnu/libm.so: invalid ELF header

[Florian Weimer]

* Aurelien Jarno:

> Now I don't find this common/utils.c file in the simple-scan sources.

This looks like a known hplip bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1347231

More recent sources try to load libm.so.6 as well.  Note that shared
objects which use libm (or any libc) functions and are not themselves
linked against the relevant shared objects have no ABI guarantees
whatsoever and can break with a glibc update.  (Exceptions are objects
which were linked against glibc 2.0, before symbol versioning was
introduced.)

Bug#861116: Fixed in glibc 2.28

[Florian Weimer]

The issue should be fixed with this upstream commit:

commit c402355dfa7807b8e0adb27c009135a7e2b9f1b0
Author: Florian Weimer 
Date:   Tue Jun 26 10:24:52 2018 +0200

libio: Disable vtable validation in case of interposition [BZ #23313]

<https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=c402355dfa7807b8e0adb27c009135a7e2b9f1b0>

Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

[Florian Weimer]

* Luke Kenneth Casson Leighton:

>  that is not a surprise to hear: the massive thrashing caused by the
> linker phase not being possible to be RAM-resident will be absolutely
> hammering the drives beyond reasonable wear-and-tear limits.  which is
> why i'm recommending people try "-Wl,--no-keep-memory".

Note that ld will sometimes stuff everything into a single RWX segment
as a result, which is not desirable.

Unfortunately, without significant investment into historic linker
technologies (with external sorting and that kind of stuff), I don't
think it is viable to build 32-bit software natively in the near
future.  Maybe next year only a few packages will need exceptions, but
the number will grow with each month.  Building on 64-bit kernels will
delay the inevitable because more address space is available to user
space, but that's probably 12 to 18 month extended life-time for
native building.

Bug#880846: libc-bin: libnss_compat is deprecated and nsswitch should stop using it on new installation

[Florian Weimer]

* Laurent Bigonville:

> According to the release note of 2.26, the nss_compat module is
> deprecated[0].

> [0]https://sourceware.org/ml/libc-announce/2017/msg1.html

I think we made changes so that it is no longer deprecated, by
removing the hard NIS dependency.  It shouldn't be used by default
nevertheless.

Bug#895981: please cleanup /var/cache/nscd on restart

[Florian Weimer]

* Harald Dunkel:

> I am using both systemd and sysvinit-core, but I am not sure which one
> was active when I ran into this problem.
>
> Consider a split DNS setup for a remote network. I had started an IPsec
> connection to the remote side. /etc/resolv.conf was changed to include
> the new internal DNServer on the remote side, but a host lookup gave me
> still the old external address. Stopping nscd did not help, AFAIR.

That's arguably a bug in nscd.  It should flush the cache each time it
detects a change in /etc/resolv.conf (or /etc/gai.conf, for that
matter).

Bug#895981: please cleanup /var/cache/nscd on restart

[Florian Weimer]

* Carlos O'Donell:

> Then each registered file, like /etc/resolv.conf, is watched via
> inotify for any changes, and if a change is detected and
> finfo->call_res_init was true (and it's true only for resolv.conf)
> then we call res_init().

But res_init does not flush the nscd cache, doesn't it?

Bug#887169: libc6: recent upgrade to 2.26-3 broke Steam games (Civ5)

[Florian Weimer]

On 01/15/2018 12:22 AM, Aurelien Jarno wrote:

I don't think it is actually the consensus, only Arch Linux has chosen
this solution, and building the whole glibc with this option will have
an impact of the performances for all binaries, not only the broken
Steam ones. I therefore don't think it's the right way to fix the bug.


For Fedora, I disabled multiarch support for the i386 builds because 
it's not entirely unlikely that there will be similar issues.


If we could assume SSE2 support and built the distribution with 
-march=x86-64, we would likely have to go the -mstackrealign route.  But 
this is just an educated guess.


Thanks,
Florian

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

[Florian Weimer]

* Paul Gevers:

> Hi Florian,
>
> On 29-07-18 13:26, Florian Weimer wrote:
>> I'm not sure why it is necessary to build glibc three times (unless
>> it's impossible to get multi-arch packages into the buildroot).
>
> I am not sure if I understand what you mean, but currently having
> multiple arches available in the autopkgtest testbed isn't supported. I
> have seen packages try (gnupg2), but this goes easily wrong considering
> the unstable-to-testing migration setup. If there is a real need for
> this, it should come from autopkgtest.

Sorry, I never worked on the Debian toolchain, so my phrasing was
poor.

In concrete terms, what I meant was: Why build libc6-i386 on amd64
when there is a libc6:i386 package as well?

In Fedora, there's a restriction that buildds cannot install foreign
architecture packages.  Some packages need a 32-bit glibc on a 64-bit
builder, too.  (Typical gcc flags, for example, or fake amd64 packages
such as amd64).  That made me wonder if Debian has a similar
restriction for its buildds.

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

[Florian Weimer]

* Paul Gevers:

> On Sun, 01 Apr 2018 21:56:33 +0200 Florian Weimer  wrote:
>> > I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours
>> > built on amd64, the glibc takes around 20 minutes to build and the
>> > testsuite around 2h to run.
>> 
>> This is still rather slow.  I see native builds on relatively current
>> hardware taking 2 minutes, plus 12 to 15 minutes to build and run the
>> test suite (all with parallel make, although parallel make for tests
>> is disabled automatically for some subdirectories).  200 minutes on
>> current (amd64) hardware sounds quite excessive.
>
> I just did a retry on our infrastructure and it ran in 57 minutes. But
> it ran on one of the two big workers (8 cores and 30 GB memory). We want
> to make all workers equal and we are going down to 2 cores and 7.2 GB.
>
> Could it be that the memory is the actual problem and/or also an issue?

I looked at the build process, and the amd64 package actually builds
glibc three times (for amd64, i386 and x32).  So 57 minutes is
actually very close to the numbers I gave.

I'm not sure why it is necessary to build glibc three times (unless
it's impossible to get multi-arch packages into the buildroot).  If
you disable kernel support for the i386 and x32 subarchitectures, at
those test suites will not run, which will speed up the build
somewhat.

Bug#902851: libc-bin: ldd stopped working with 32-bit binaries on amd64 machine

[Florian Weimer]

* Alexandra N. Kossovsky:

> Please close this bug.  I definitely saw the issue yesterday, but it has 
> somehow gone today.  I'll return to you if I see it again and understand 
> what triggers it.

The related Fedora bug

  https://bugzilla.redhat.com/show_bug.cgi?id=1596312

appears to have been a kernel regression (unconditional exit status
zero from 32-bit processes, or something like that).

Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

[Florian Weimer]

* Aurelien Jarno:

> I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours
> built on amd64, the glibc takes around 20 minutes to build and the
> testsuite around 2h to run.

This is still rather slow.  I see native builds on relatively current
hardware taking 2 minutes, plus 12 to 15 minutes to build and run the
test suite (all with parallel make, although parallel make for tests
is disabled automatically for some subdirectories).  200 minutes on
current (amd64) hardware sounds quite excessive.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Florian Weimer]

* Niels Thykier:

> armel/armhf:
> 
>
>  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]

Fedora is facing an issue running armhf under virtualization on arm64:

  
  

Unless the discussion has moved somewhere where I can't follow it, no
one seems to have solid idea what is going on.  It's also not clear
that this configuration has substantial vendor or community support.
This makes me concerned that virtualization is a viable path forward
here.

(The discussion on the GCC list started off with a misdirection, sorry
about that.  The brief assumption that this was a hardware quirk is
likely quite wrong.)

>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>in GCC
>(Raised by the GCC maintainer; carried over from stretch)

I'm surprised to read this.  ppc64el features prominently in the
toolchain work I do (though I personally do not work on the GCC side).
>From my point of view, it's absolutely not in the same category as the
MIPS-based architectures.

Bug#761300: libc6: Printf("%c",'x') does not follow stdio

[Florian Weimer]

* Sven Joachim:

> This result is rather surprising.  After all, "putchar('x')" is supposed
> to do the same as "putc('x', stdout)", but here it does not.

Can you reproduce this with something newer than 2.13-38+rpi2+deb7u3?
Or on something else besides armhf?

Bug#912665: (geen onderwerp)

[Florian Weimer]

* Frederik Himpe:

> FYI, this is where it crashes:
>
> #0  0x7fc0172239c6 in _IO_fgets (buf=0x7ffc9b2b1640 "
> /dev/aivmhost3-vg/ceph-node1-storage:ceph-ff35163d-b03f-4dbf-a6ce-155730069dc0:4194304:-1:8:8:-1:4096:511:0:511:ZNexTV-ylVb-ltMP-T8Zu-ZklU-cN1I-dETf5o\n",
> n=1024, fp=0x1a90030)
> at iofgets.c:47

This is the first dereference of the file stream pointer in fgets, so
this suggests a use-after-free application bug (or use-after-fclose in
this case).  It should be visible in valgrind as well.

Thanks,
Florian

Bug#906917: sem_timedwait could always block and returns ETIMEOUT but decrements the value on i686 architecture

[Florian Weimer]

* Андрей Доценко:

> The problem occurs only when using semaphores in a library that is not
> linked against pthread.

Yes, that's expected.  Sorry I didn't see this earlier—we have an
upstream bug about this:

  

In general, underlinking produces broken binaries.

Thanks,
Florian

Bug#920047: glibc: CVE-2016-10739: getaddrinfo should reject IP addresses with trailing characters

[Florian Weimer]

* Salvatore Bonaccorso:

> CVE-2016-10739[0]:
> | In the GNU C Library (aka glibc or libc6) through 2.28, the getaddrinfo
> | function would successfully parse a string that contained an IPv4
> | address followed by whitespace and arbitrary characters, which could
> | lead applications to incorrectly assume that it had parsed a valid
> | string, without the possibility of embedded HTTP headers or other
> | potentially dangerous substrings.
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2016-10739
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10739
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=20018
>
> Please adjust the affected versions in the BTS as needed.

Would it help if I put a backport on the 2.24 upstream branch?

Bug#761300: libc6: putchar does not follow stdio

[Florian Weimer]

* Sven Joachim:

> Am 14.10.2018 um 13:38 schrieb Florian Weimer:
>
>> * Sven Joachim:
>>
>>> This result is rather surprising.  After all, "putchar('x')" is supposed
>>> to do the same as "putc('x', stdout)", but here it does not.
>>
>> Can you reproduce this with something newer than 2.13-38+rpi2+deb7u3?
>> Or on something else besides armhf?
>
> Surely, I tested 2.27-6 on amd64.

Eh, right.  We have this in glibc:

int
putchar (int c)
{
  int result;
  _IO_acquire_lock (_IO_stdout);
  result = _IO_putc_unlocked (c, _IO_stdout);
  _IO_release_lock (_IO_stdout);
  return result;
}

_IO_stdout is the variable to which stdout points to default, so this
code was simply not adjusted when the assignment-to-stdout extension
was implemented.  This should use stdout instead.  The puts function
has the same problem.

It looks to me we can get away with fixing this bug.

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

[Florian Weimer]

* Laurent Bigonville:

> Le 19/03/19 à 19:43, Florian Weimer a écrit :
>> * Laurent Bigonville:
>>
>>> Package: libc6-dev
>>> Version: 2.28-8
>>> Severity: serious
>>>
>>> Hi,
>>>
>>> The crypt.3 manpage, state that _XOPEN_SOURCE should be define for
>>> crypt() to be available.
>>>
>>> But it looks that it's currently the opposite, if _XOPEN_SOURCE is
>>> defined, the function cannot be found.

>> Can you compile the software using _DEFAULT_SOURCE (well, the default)
>> or _GNU_SOURCE instead?
>
> Yes, the software can be compile when _XOPEN_SOURCE is not defined or 
> when _GNU_SOURCE is defined instead

Sorry, what I was trying to ask is whether this would be an acceptable
change for you.

Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

[Florian Weimer]

* Lucas Nussbaum:

> On 26/03/19 at 23:10 +0100, Aurelien Jarno wrote:
>> On 2019-03-22 17:30, Florian Weimer wrote:
>> > > About the archive rebuild: The rebuild was done on EC2 VM instances from
>> > > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
>> > > failed build was retried once to eliminate random failures.
>> > 
>> > I believe the actual test failure is tst-pkey.
>> > 
>> > Presumably, this rebuild was performed on some Xeon SP CPU.  Do you
>> > know which model?  Do you have any information about the kernel and
>> > hypervisor used?
>> > 
>> > 32-bit protection key support has had issues from time to time.
>> 
>> Do you have some more details about the issue? Is it a glibc or a kernel
>> problem?
>> 
>> If we can't fix the issue easily on the libc side, I guess the way to
>> fix that is to XFAIL that test on 32-bit x86. 
>
> If that's useful, I can easily provide access to an AWS VM to debug this
> issue.

Oh, that would be quite helpful indeed.

Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)

[Florian Weimer]

* Christoph Berg:

> with the update to glibc 2.28, collation aka sort ordering is
> changing:
>
> $ echo $LANG
> de_DE.utf8
> $ (echo 'a-a'; echo 'a a'; echo 'a+a'; echo 'aa') | sort
>
> stretch:
>   aa
>   a a
>   a-a
>   a+a
>
> buster:
>   a a
>   a+a
>   a-a
>   aa
>
> A vast number of locales is affected, including en_US, possibly all of
> them.
>
> For PostgreSQL, this means that the ordering of indexes on disk is
> becoming corrupt, and all "text" (varchar, char, ...) indexes need to
> be rebuilt. (And worse, if that is not done immediately, the tables
> might become corrupt because some tuples aren't index-visible anymore
> due to the incorrect btree ordering.)

That's fairly normal in a glibc update.  glibc upstream prefers it
this way.  I've discussed it several times with other glibc
maintainers.

My understanding is that ICU provides versioned collation tables,
which would allow you to avoid this issue.

  

> I've been thinking about this for some time, and the best I could come
> up so far is "raise a debconf note that people need to invoke REINDEX
> DATABASE". The open question about this plan is, how should this note
> be triggered.

That might not work for unique indices because locale data changes
could cause strings to sort the same that were distinct before the
update.

Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

[Florian Weimer]

retitle 924891 glibc: misc/tst-pkey fails due to cleared PKRU register after 
signal in amd64 32-bit compat mode 
thanks

* Lucas Nussbaum:

> On 27/03/19 at 08:48 +0100, Florian Weimer wrote:
>> > If that's useful, I can easily provide access to an AWS VM to debug this
>> > issue.
>> 
>> Oh, that would be quite helpful indeed.
>
> Can you send your SSH key? (I thought there was a way to get the SSH key
> for a DD, but I cannot find it anymore)
>
> Then you will be able to ssh to root@18.184.55.40.
> There's sbuild and schroot setup on the VM.
>
> When you are done, please 'poweroff' the machine, which will terminate
> it.

The issue reproduces outside the chroot, with the stretch userland.

What happens is that once we get out of the SIGUSR1 signal handler,
the PKRU register has value zero.  This happens around this code in
the test:

  /* Check that in a signal handler, there is no access.  */
  xsignal (SIGUSR1, _handler);
  xraise (SIGUSR1);
  xsignal (SIGUSR1, SIG_DFL);
  TEST_COMPARE (sigusr1_handler_ran, 1);

I checked the following (via a breakpoint in pkey_get; I don't think
GDB can read the PKRU register directly): Inside the SIGUSR1 signal
handler, PKRU has value 0x5554, as expected for this kernel, but
after the return, we get zero.  This is the first time a signal is
delivered on the main thread, so it's consistent with fairly broken
signal handling as far as the PKRU register is concerned.  I guess
clearing PKRU in this way might even constitute a minor security bug
(because the zero value means no restrictions).

This commit looks highly relevant:

commit a4455082dc6f0b5d51a23523f77600e8ede47c79
Author: Dave Hansen 
Date:   Wed Jun 8 10:25:33 2016 -0700

x86/signals: Add missing signal_compat code for x86 features

The 32-bit siginfo is a different binary format than the 64-bit
one.  So, when running 32-bit binaries on 64-bit kernels, we have
to convert the kernel's 64-bit version to a 32-bit version that
userspace can grok.

If the siginfo_t layout is incorrect (with regards to what the
hardware writes), I expect that we might end up copying back the wrong
PKRU value.

I'm not sure what to do here.  This really looks like a kernel bug.
Maybe we should just verify that this is fixed in the buster kernel
and move on?

Lucas, can you run your rebuild tests on newer kernels?

Bug#923802: Acknowledgement (pthread: dead-lock while pthread_cond_destroy())

[Florian Weimer]

* Joël Krähemann:

> This happens as you call pthread_cond_destroy() twice on the very same
> cond variable.

Surely that's an application bug.  Why do you think this is a glibc
issue?

Thanks,
Florian

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

[Florian Weimer]

* Laurent Bigonville:

> Package: libc6-dev
> Version: 2.28-8
> Severity: serious
>
> Hi,
>
> The crypt.3 manpage, state that _XOPEN_SOURCE should be define for
> crypt() to be available.
>
> But it looks that it's currently the opposite, if _XOPEN_SOURCE is
> defined, the function cannot be found.

Can you compile the software using _DEFAULT_SOURCE (well, the default)
or _GNU_SOURCE instead?

We do not want to provide the CRYPT extension anymore because it
implies not just support for the crypt function, but also for the DES
encryption functions, which definitely do not want.  In _XOPEN_SOURCE
mode, it's either all of these functions or none of them (and we chose
the latter because of DES), otherwise glibc wouldn't conform to the
interface specification.

We definitely should update the manual page, though.

Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

[Florian Weimer]

> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.

I believe the actual test failure is tst-pkey.

Presumably, this rebuild was performed on some Xeon SP CPU.  Do you
know which model?  Do you have any information about the kernel and
hypervisor used?

32-bit protection key support has had issues from time to time.

Thanks.

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

[Florian Weimer]

* Roman Savochenko:

>> Is there a way to reproduce your results easily?  Upstream, we're
>> looking for workloads which are difficult to handle for glibc's malloc
>> and its default settings, so that we hopefully can improve things
>> eventually.
>
> This way of the ready builds of the application and LiveDisks is
> simplest one for me, than writing a test application with simulation
> such sort complex load, so you can already install the application,
> start and observer.

I meant: Is there a reproduction recipe someone could use, without being
familiar with the application?

Thanks,
Florian

Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster

[Florian Weimer]

* Pavel Matěja:

> The strange means they appear only on 2 servers out of 6.
> Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon 
> E3-1220 v6 produced crashes.
> It did not matter if the host Debian was Stretch or Buster.

Do you see crashes on stretch as well?  What does the backtrace look
like there?

> SSLv3 and TLS code path looked quite distinct to cause the same problem.
> Based on info that SEGFAULTs are related to memory allocation in new 
> libc and CPU performance I found
> http://51.15.138.76/patch/17499/
> where Wilco Dijkstra discuss some problems with tcache which "leads to 
> various crashes in benchtests"

I was under the impression that this problem only occurs if one of the
tunables has an out-of-bounds value.  Do you set any tunables?

Bug#924712: crypt() not available _XOPEN_SOURCE is defined

[Florian Weimer]

* Francesco Poli:

> Hello everyone,
> I am sorry to ask, but... I cannot understand what's the status of
> [this bug report].
>
> [this bug report]: 
>
> A serious bug for libc6-dev without any apparent activity since last
> March?  Sure there must have been some hidden progress that I cannot
> see.

We provided a solution acceptable to the reporter.  I do not think
further action is needed on the glibc side.  The manual page needs to
be updated to reflect the change, but that's not part of glibc.

Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster

[Florian Weimer]

* Pavel Matěja:

> Sorry for late answer.
>
> On 17. 08. 19 22:18, Florian Weimer wrote:
>> * Pavel Matěja:
>>
>>> The strange means they appear only on 2 servers out of 6.
>>> Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon
>>> E3-1220 v6 produced crashes.
>>> It did not matter if the host Debian was Stretch or Buster.
>> Do you see crashes on stretch as well?  What does the backtrace look
>> like there?

> I newer saw the SEGFAULT when we had Stretch based chroot.
>
> I had just one SEGFAULT on Stretch host but I didn't collect coredumps
> back then.
> Unfortunately the server is already running Buster.
> Since the bug is caused by new libc in chroot I should be able to
> install just kernel from Stretch and wait for the SEGFAULT, right?
> I think the backtrace will be the same anyway.

If I recall correctly, stretch doesn't have the tcache code.  If the
crash happened there as well, it's something else.

>>> SSLv3 and TLS code path looked quite distinct to cause the same problem.
>>> Based on info that SEGFAULTs are related to memory allocation in new
>>> libc and CPU performance I found
>>> http://51.15.138.76/patch/17499/
>>> where Wilco Dijkstra discuss some problems with tcache which "leads to
>>> various crashes in benchtests"
>> I was under the impression that this problem only occurs if one of the
>> tunables has an out-of-bounds value.  Do you set any tunables?

> No, I didn't even know they existed.
> I did not read the libc sources yet so I don't know what does the
> patch actually fixes neither if it helps with my problem.

Then the patch will not help to fix the crash.

(By the way, even if the crash goes away if you use a tunable to disable
the thread cache, it could still be timing-related.  It's definitely
possible that the faster malloc/free implementation exposes pre-existing
data races.)

Thanks,
Florian

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

[Florian Weimer]

* Roman Savochenko:

> Initial condition of the problem representing is a program in the
> single source code, built on-and for Debian 7, 8, 9, 10 with a result
> in the Live disks.

I think glibc 2.13 as shipped by Debian was not built with
--enable-experimental-malloc, so it doesn't use arenas.  This can
substantially decrease RSS usage compared to later versions.  You can
get similar behavior by setting the MALLOC_ARENA_MAX environment
variable to 1 or 2.

Debian 10 also adds a thread cache, which further increases RSS size.
See the manual

  


for details how to change thread cache behavior.

Thanks,
Florian

Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

[Florian Weimer]

* Roman Savochenko:

> Thanks you Florian, setting the environment MALLOC_ARENA_MAX=1 I have
> got the memory effectivity some better even than in Debian 7!

Is there a way to reproduce your results easily?  Upstream, we're
looking for workloads which are difficult to handle for glibc's malloc
and its default settings, so that we hopefully can improve things
eventually.

Thanks,
Florian

Re: Options for 64-bit time_t support on 32-bit architectures

[Florian Weimer]

* Simon McVittie:

> On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote:
>> Remaining usecases of i386 will be old binaries, some old Linux binaries 
>> but especially old software (including many games) running in Wine.
>> Old Linux binaries will still need the old 32bit time_t.
>
> Based on background from my contributions to the Steam Runtime:
>
> I don't have numbers, but you might be surprised how many Linux-supporting
> games are 32-bit. The Steam client itself is currently also 32-bit
> (with some 64-bit subprocesses); this is somewhat deliberate, to act as
> a canary for whether 32-bit code works at all, particularly when combined
> with graphics.
>
> The Steam Runtime (a LD_LIBRARY_PATH library bundle used to run Steam and
> Steam games) is built on an increasingly ancient version of Ubuntu, but
> it tries to use newer libraries of the same SONAME from the host system
> where available, which they often will be, because people who install
> Steam probably also install Wine, which has 32-bit dependencies. If those
> libraries have an incompatible ABI involving 64-bit time_t, and it is used
> at the ABI "surface" between a host-system library and a Steam Runtime
> library or the game, then 32-bit games, and the Steam client itself,
> will crash.

We could in theory bump soname for these libraries, but that has the
unfortunate side effect that it will likely leak to 64-bit
architectures, creating more work for everyone.

I don't see a good way to maintain those libraries with a single-ABI
approach.  So if that's an important use case, it would be a fairly
strong case against it, I think.

Options for 64-bit time_t support on 32-bit architectures

[Florian Weimer]

There is an effort under way to enhance glibc so that it can use the
Y2038 support in the kernel.  The result will be that more 32-bit
architectures can use a 64-bit time_t.  (Currently, it's x86-64 x32
only.)

Originally, the plan was to support both ABIs in glibc for building
new applications, similar to what is currently possible with
-D_FILE_OFFSET_BITS=64 for changing the size of off_t.  However, this
turned out to be difficult to implement, and so far, no one has posted
patches which appear to be reasonably correct and complete.

The latest proposal is a single-ABI mode for development:

  

Old binaries with a 32-bit time_t will continue to run, but new
binaries built against a current glibc will always use a 64-bit time_t
under this approach.

The consequence is that in order to build 32-bit-time_t libraries
(Gtk, for example), an old glibc needs to be kept around.  In
practice, it would probably mean that it is impossible to maintain a
set of 32-bit-time_t libraries in a classic distribution build
environment (with a unified buildroot and native builds).

I do not have a strong opinion about this because I personally do not
care about 32-bit architectures at all (sorry).  I would like to
solicit Debian's feedback on this matter.

Do you want to build 32-bit libraries (besides glibc) which are
compatible with legacy applications, with a 32-bit time_t, in the
future?  Or is a world where time_t is pretty much always 64 bit
something that would be acceptable?

Re: Options for 64-bit time_t support on 32-bit architectures

[Florian Weimer]

* Adrian Bunk:

> [ only speaking for myself ]
>
> On Thu, Jul 18, 2019 at 11:05:53PM +0200, Florian Weimer wrote:
>>...
>> The consequence is that in order to build 32-bit-time_t libraries
>> (Gtk, for example), an old glibc needs to be kept around.  In
>> practice, it would probably mean that it is impossible to maintain a
>> set of 32-bit-time_t libraries in a classic distribution build
>> environment (with a unified buildroot and native builds).
>>...
>> Do you want to build 32-bit libraries (besides glibc) which are
>> compatible with legacy applications, with a 32-bit time_t, in the
>> future?  Or is a world where time_t is pretty much always 64 bit
>> something that would be acceptable?
>
> So this is an ABI-incompatible change that would result in new Debian 
> architectures, similar to arm (OABI), armel (EABI softfp) and armhf 
> (EABI hardfp) being different Debian architectures for 32bit little 
> endian ARM?

Not quite.  glibc would still be able to run binaries from the old ABI
and the new ABI.  But under the proposal, you would have to use an old
glibc (missing new system call wrappers etc.) if you want to build
libraries that provide interfaces involving 32-bit time_t.

So in practice, it would likely mean a new Debian architecture, or a
de-facto ABI bump for i386 and armhfp.

For comparison, the original plan was to provide a macro, perhaps
-D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI
set is used (“dual ABI”).  Similar to the LFS support, with the
additional property that binaries built in either mode should continue
to work on kernels which predate support for the *_time64 system
calls.  The should also use the vDSO as before.  All these
requirements make an implementation quite hairy, hence the desire for
simplification.

> There are two current release architectures where it is at least 
> imaginable that they will still be around closer to the year 2038:
> i386 and armhf

Right.

> For i386 the last newly released 32bit-only hardware were some early
> Intel Atoms 10 years ago, and when the AMD Geode goes out of production
> soon there might be no hardware in production left.
> There are still surprisingly many people using Debian on 32bit-only
> hardware, but in 20 years this will have changed.

You have thankfully edited out the Intel Quark. 8-)

> Remaining usecases of i386 will be old binaries, some old Linux binaries 
> but especially old software (including many games) running in Wine.
> Old Linux binaries will still need the old 32bit time_t.
> Which options are viable from a Wine point of view?

I talked to a Wine developer in the office, and Wine doesn't directly
expose the time_t ABI to Windows binaries (which isn't suprising).
It's also already been ported to 32-bit systems with a 64-bit time_t.
I expect that this is not a determining factor.

> For armhf new hardware might be available long enough to come close
> to the year 2038, this might require a new architecture at some point.

The push for a 64-bit time_t definitely comes from the embedded 32-bit
processor direction.

For glibc, providing a dual ABI configurable at build time one or all
32-bit architectures probably does not make much of a different in
terms of overall effort.  This means that if we need to produce the
dual ABI for i386, armhfp will likely get it as well.

Re: Options for 64-bit time_t support on 32-bit architectures

[Florian Weimer]

* Adrian Bunk:

> On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote:
>> * Adrian Bunk:
>>...
>> For comparison, the original plan was to provide a macro, perhaps
>> -D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI
>> set is used (“dual ABI”).
>
> To me this would sound like more trouble than a clear break,
> similar to the mostly working dual OpenSSL 1.0 and 1.1 support
> in stretch.

Could be.  But it would enable keeping i386 at the old ABI while still
building the distribution with newer glibc versions with current
kernel headers (the libc-alpha discussion is evolving regarding the
precise nature of the enablement approach).

Other 32-bit architectures could opt to do the transition now.

>> Similar to the LFS support, with the
>> additional property that binaries built in either mode should continue
>> to work on kernels which predate support for the *_time64 system
>> calls.
>
> Debian does not support running on kernels older than the one in the
> previous stable release.
>
> E.g. Qt in Debian 9 unconditionally uses the getrandom syscall that is 
> not in kernel 3.16 in Debian 7.

The 64-bit system calls arrived in Linux 5.1, so I think the fallback
will be needed for quite some time.