Florian Weimer | 21 Apr 16:52 2015

Re: glibc 2.5 - patch for GHOST (CVE-2015-0235)

On 04/21/2015 04:47 PM, czezz wrote:
> Well, that was my initial idea.
> But as only I looked little bit deeper I realized I cannot go like that.
> Some of patches from your repository/link contain lines like following:
> glibc-rh947882.patch:diff -urN glibc-2.5-20061008T1257.orig/sysdeps/posix/getaddrinfo.c glibc-2.5-20061008T1257/sysdeps/posix/getaddrinfo.c
> glibc-rh947882.patch:--- glibc-2.5-20061008T1257.orig/sysdeps/posix/getaddrinfo.c      
2013-04-11 14:41:39.224166628 -0400
> glibc-rh947882.patch:+++ glibc-2.5-20061008T1257/sysdeps/posix/getaddrinfo.c    2013-04-11
15:30:32.186995962 -0400
> so, the script for building in your repository expects to have source files/some of source files in dir glibc-2.5-20061008T1257/
> where in Slackware's building script it is glibc-2.5/
> Of course I can re-tar and re-compress Slackware's source glibc but then I must modify all Slack's diff
files (which is in the end and idea).
> Im more worried that I have compared eg:
> glibc-rh645672.patch with glibc.CVE-2010-3856.diff.gz. They are similar but not identical...

Ah, I misunderstood you.  I assumed that you were attempting to backport
a single fix.  If you want to reach bug fix parity with a still-support
glibc (be it from Debian, Red Hat or SuSE), that is going to be a *lot*
more work.


Florian Weimer / Red Hat Product Security

Florian Weimer | 21 Apr 16:11 2015

Re: glibc 2.5 - patch for GHOST (CVE-2015-0235)

On 04/21/2015 04:08 PM, czezz wrote:

> I though that by replacing these patch list with the ones form you and also changing the source archive from
you I would make it...

No the only change you should make is to add yet another patch.  No
other changes.  Do not replace the tarball or remove the other patches.


Florian Weimer / Red Hat Product Security

Florian Weimer | 21 Apr 15:39 2015

Re: glibc 2.5 - patch for GHOST (CVE-2015-0235)

On 04/21/2015 03:27 PM, czezz wrote:
> Hi Florian,
> thank you for looking into this.
> I have removed and that did not help :/

Then it's a Slackware package build issue, and you need to ask on a
Slackware support list/forum for help, sorry.


Florian Weimer / Red Hat Product Security

Florian Weimer | 17 Apr 13:23 2015

Re: glibc 2.5 - patch for GHOST (CVE-2015-0235)

On 04/17/2015 11:30 AM, czezz wrote:

> thank you for reply and the link that u sent to me.
> This is basically what I need.
> I patched glibc-2.5-20061008T1257 successfully but during compilation (under Slackware) I get
following errors.

> connections.c: In function 'nscd_run_worker':
> connections.c:1730: warning: no return statement in function returning non-void
> connections.c: In function 'main_loop_epoll':
> connections.c:2178: error: 'inotify_fd' undeclared (first use in this function)
> connections.c:2178: error: (Each undeclared identifier is reported only once
> connections.c:2178: error: for each function it appears in.)

This is unrelated to the CVE-2015-0235 fix.  Can you build without the
CVE-2015-0235 patch?  If your backported patch is indeed to blame, it's
likely you picked the wrong patch to backport.


Florian Weimer / Red Hat Product Security

Christophe | 15 Apr 03:33 2015

MIPS and dynamic linking

Hi Folks,

I recently started to play around with a CI20 board [1] running
Wheezy/MIPS, and noticed some changes in the ELF format w.r.t. dynamic
linking information as compared to what I used to see on the OpenWRT

The MIPS binaries I have seen on the OpenWRT platform seemed to follow
the SysV ABI rev 3 [1].
The binaries on Wheezy/MIPS have some differences. For example, the
dynamic table now contains DT_JMPREL entries, and as far as I can
tell, it seems that  MIPS_GOTSYM is now used to identify R_MIPS_REL32

Is there any documentation about the current MIPS ABI as used by glibc
? Or alternatively, is there a document somewhere providing an
exhaustive list of the differences w.r.t. the SysV ABI rev 3 [1]  ?


Juan Manuel Torres Palma | 13 Apr 18:34 2015

Local binding for new files in nptl

Hello there!

I'm trying to add some functions (C11 threads) to the nptl folder,
being able to compile it, and see the code of the functions with
objdump, read the symbols with nm, etc.

However, when trying to build an application with this version of
libpthread.so, I'm getting linking error, basically undefined
references to all the functions created. After a bit of reseach I
found out that those symbols had local bindings, while all the
pthread_* symbols were global.

My symbols are all declared without static keyword, so I still don't
get why this is happening and I have been looking through the source
to find an explanation but I can't get it yet. I would really
appreciate if someone can show some light on this as I'm getting

Obviously, it's not a glibc bug or issue, but a lack of knowledge for me.

Thanks for your help.



Juan Manuel Torres Palma.
Computer Science Student at Universidad de Granada.

David Aldrich | 10 Apr 10:00 2015

dlopen with RTLD_NOLOAD returns handle for library that failed to load previously


We have observed what seems to be a bug in dlopen. The problem first appeared when we moved from glibc 2.5 to
glibc 2.12. We also observe it in glibc 2.19. We call dlopen to open a .so file. This call fails (returns
null) because of an unresolved symbol in the library. However a subsequent call to dlopen using the
RTLD_NOLOAD flag returns a non-zero handle. Our understanding is that a call to dlopen with RTLD_NOLOAD
can be used to test if a library is resident or not, so we expect it to return null if the load failed (and this
is indeed the behaviour in glibc 2.5). The example code at the bottom of this email shows the problem.

We are wondering if this could be due to the presence of STB_GNU_UNIQUE symbols, as we have seen reports of
this causing similar problems. If so is there any workaround for it?

Some background about our application: Our application needs to load a list of .so files that may depend on
each other in arbitrary ways. The dependencies are not known to the application. To do this we attempt to
load each .so file in turn. If a particular .so file fails (due to missing dependencies), we put it at the
back of the queue and try it again after trying all of the others. This continues until we have successfully
loaded all of them. We can rewrite this to avoid using the RTLD_NOLOAD option, but we still need a robust way
to check if a load attempt has succeeded or not, and we need to be sure that if a load attempt fails then the
system is still in a safe state to make another attempt at loading the same file later.

Best regards


Test case

In this test case, we build shared library lib.so from source file lib.cpp.  We also build application
main.out, which attempts to load lib.so and fails, but receives a non-zero handle from dlopen on the
second attempt, which is unexpected. Finally, I show the build script we used to build the library and application.
(Continue reading)

Florian Weimer | 7 Apr 18:11 2015

Re: glibc 2.5 - patch for GHOST (CVE-2015-0235)

On 04/07/2015 05:58 PM, Swati Kher -X (swkher - TALENT SPACE INC at
Cisco) wrote:
> Sorry - I meant backport for glibc-2.21 for RH7 not 2.5 for RH7 - but similar patch and backport

Hi Swati,

On <https://access.redhat.com/security/cve/CVE-2015-0235>, you can see
that this bug was addressed for Red Hat Enterprise Linux 7 via


Red Hat Enterprise Linux 7 source RPMs are only available to customers
with a valid subscription.  On such as system, you can execute

  yum-downloader --source glibc-2.17-55.el7_0.5

after enabling the source RPM repositories.  Fixed RPM binary packages
are available through the regular system upgrade mechanism.

Alternatively, the change has also been exported to git.centos.org and
is available here:


Note that this is a backport to 2.17, not a fix for glibc 2.21.  glibc
2.21 is not currently part of any supported Red Hat product.  The
upcoming community release of Fedora 22 will come with glibc 2.21, though.

If your interest in glibc backports is the result of requests from your
security team, I am willing to talk to them directly and explain them
(Continue reading)

Assaf Gordon | 6 Apr 21:12 2015

git clone error when using http://

Hello glibc developers,

A quick question:
The glibc git viewer ( https://sourceware.org/git/?p=glibc.git;a=summary ) mentions three possible
protocols to use:

However, the 'http' one fails with the following:
     $ git clone http://sourceware.org/git/glibc.git
     Cloning into 'glibc'...
     error: Unable to get pack index http://sourceware.org/git/glibc.git/objects/pack/pack-f89a10ccd2eca36b8bd9e4acb6ba1f90d777efcf.idx
     error: Unable to get pack index http://sourceware.org/git/glibc.git/objects/pack/pack-c37c29d274c26e076dfa0516f736ffb41b92d8a3.idx
     error: The requested URL returned error: 504 Gateway Timeout (curl_result = 22, http_code = 504, sha1 =    389ed28d1175b67ee5dcd40e69df912d4a1109b0)
     error: Unable to find 389ed28d1175b67ee5dcd40e69df912d4a1109b0 under http://sourceware.org/git/glibc.git
     Cannot obtain needed object 389ed28d1175b67ee5dcd40e69df912d4a1109b0
     while processing commit 9b5a06c242e640d4af84a031e96ca47bcf595caf.
     error: Fetch failed.
Which makes cloning anonymously behind a restrictive firewall a bit of a problem.

Is there an alternative URL to use with http? or a way around it?

  - Assaf

Przemek | 3 Apr 16:22 2015

select stops after first byte even when more bytes are available


I noticed this select behaviour and I am not sure if it is a bug. Can 
not understand why it happens.
Here is a small test program:

#include <stdio.h>
#include <sys/select.h>
    fd_set rfds;
    struct timeval tv;
    int retval;

    while (1)
       FD_SET(fileno(stdin), &rfds);

       retval = select(1, &rfds, 0, 0, 0);
       if (retval == -1)

       if (FD_ISSET(fileno(stdin), &rfds))
          printf("R:%02x\n", getc(stdin));
    return 0;

(Continue reading)

Ramana | 1 Apr 08:33 2015

Errors with make check of glibc v2.20 while cross compiling for powerpc


Probably the query
https://sourceware.org/ml/libc-alpha/2015-03/msg00841.html posted on
libc-alpha is more relavent here.

Thank you,
Venkata Ramanaiah N