GHOST: glibc vulnerability (CVE-2015-0235)

Updated -

Red Hat Product Security has been made aware of a critical vulnerability in the glibc library, which has been assigned CVE-2015-0235 and is commonly referred to as 'GHOST'. All versions of glibc shipped with all variants of Red Hat Enterprise Linux are affected.

Background Information

GHOST is a 'buffer overflow' bug affecting the gethostbyname() and gethostbyname2() function calls in the glibc library. This vulnerability allows a remote attacker that is able to make an application call to either of these functions to execute arbitrary code with the permissions of the user running the application.


The gethostbyname() function calls are used for DNS resolving, which is a very common event. To exploit this vulnerability, an attacker must trigger a buffer overflow by supplying an invalid hostname argument to an application that performs a DNS resolution.

Determining Vulnerability

As a Red Hat customer, the easiest way to check for the vulnerability and confirm remediation is the Red Hat Access Lab: glibc (GHOST) Detector. Please make sure that you have installed the correct version prior and if you are downloading the package for RHEL 4, you must be subscribed to the ELS channel or have downloaded the ELS version of the package. The RHEL 4 non-ELS subscription version will show a "vulnerable" message.


To eliminate the possibility of an exploit:

1. Update the glibc and nscd packages on your system using the packages released with the following errata:

2. Reboot the system or restart all affected services:

Because this vulnerability affects a large amount of applications on the system, the safest and recommended way to assure every application uses the updated glibc packages is to restart the system.

In case you are unable to restart the entire system after applying the update, execute the following command to list all running processes (not restricted to services) still using the old [in-memory] version of glibc on your system.

lsof +c0 -d DEL | awk 'NR==1 || /libc-/ {print $2,$1,$4,$NF}' | column -t

From the resulting list, identify the public-facing services and restart them. While this process may work as a temporary workaround, it is not supported by Red Hat and, should a problem arise, you will be requested to reboot the system before any troubleshooting begins.

Additional Information


Hello RedHat support,
We have multiple RHEL versions in our env, how we should process GHOST fixup, if we have running in parallel
5.1, 5.2, 5.4, 5.8, and 6.5
For 6.5 I see that yum should do the job, but what about outdated 5.x versions? Can we update only glibc, or firs we have to update to latest 5.x branch?

You only need to update glibc

Is it affected? Not in the list of errata in the article.
Installed glibc version(s)
- glibc-2.5-81.el5_8.2.i686: vulnerable

This system is vulnerable to CVE-2015-0235.
Please refer to for remediation steps
[root@coalmont86 chuach]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.8 (Tikanga)

Yes, it's packages needs to be updated.

What about this? Not in the list.

Installed glibc version(s)
- glibc-2.12-1.80.el6.x86_64: vulnerable
- glibc-2.12-1.80.el6.i686: vulnerable

This system is vulnerable to CVE-2015-0235.
Please refer to for remediation steps
[root@coalgood81 rightaccess]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.3 (Santiago)

Hi RedHat team,

we don't have satellite server and internet on server's
Is there any way to download and install these package?

rpm -q glibc


cat /etc/redhat-release

Red Hat Enterprise Linux Server release 6.4 (Santiago)

uname -a

Linux lnx-indusmed1 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64 x86_64 GNU/Linux

Download and install the following packages from the portal:
- glibc-2.12-1.149.el6_6.5.x86_64
- glibc-2.12-1.149.el6_6.5.i686
- glibc-common-2.12-1.149.el6_6.5.x86_64
- glibc-devel-2.12-1.149.el6_6.5.x86_64
- glibc-headers-2.12-1.149.el6_6.5.x86_64
- nscd-2.12-1.149.el6_6.5.x86_64

If you just want to update your system regarding GHOST vulnerability :
yum update glibc* -y && reboot

What is the correct CLI syntax to download the script for the glibc GHOST detector, running RHEL 7 x64 please.
Thank you

Hi Terry,

You can use, for example:

curl -u "username":"password" -o

Are RHEL 3 and RHEL4 systems vulnerable? If they are, when will a fix be available for them?


Hi Beverley, RHEL 3 ELS reached end of life on January 30, 2014 and is thus no longer supported; it will not receive any updates. A fix for RHEL 4 ELS is available via RHSA-2015:0101.

Sorry, when I click respond, I get a full page of code, anyway, I can download the script, locate it on the server but I'm unable to run it. The server returns: command not found, (capitals correct) I've logged in at sudo, tried ./ that others have posted. (Permission denied) or (No such file or directory) What is the default CLI command after retrieving the file using:
thank you

Hi Terry,

Did you make the script executable? The instructions are on the lab page.

$ chmod +x

We have EUS on our RHEL 3 servers. Doesn't that mean you fix secure vulnerabilities like this?


Beverley, RHEL 3 has been unsupported for one year exactly today. Please see our support policy:

When a product version reaches its end of life, we do not provide any updates for it.

The C code at named ghosttest.c seems a better test of the exploit. JUst saying...Trust but verify,.

Thanks Robert, Sorry to add new comments, I can't reply for some reason. So, I've made the script executable, and whn I run it, I get:
./ line 1: syntax error near unexpected token 'newline'
./ line 1: `'

Terry, so sorry to have misled you before. Unfortunately, you only downloaded a webpage telling you that you need to log in. Which is why you got that error when trying to run the script. Please, use the following command to download it:

curl -u "username":"password" -o

Substitute 'username' and 'password' with your Customer Portal credentials. This should download the script file properly. Just to be on the safe side, please run head -1 after you download it. It should show #!/bin/bash.

Then you need to make the file executable again, or just run it directly with:


Thank you very much. I learn from everything.
I'll post results when I'm done, hopefully will help the novice like myself!

The information in RHSA-2015:0090-1 ( pertaining which versions of glibc and nscd are needed to fix this issue are incorrect!

The document states to update to glibc-2.5-123.el5. Running the reveals:

[testusr@rhel5dev ~]# rpm -qa | sort | grep glibc
[testusr@rhel5dev ~]# rpm -qa | sort | grep nscd
[testusr@rhel5dev ~]# /home/testusr/glibc/
Installed glibc version(s)
- glibc-2.5-123.x86_64: vulnerable
- glibc-2.5-123.i686: vulnerable

This system is vulnerable to CVE-2015-0235.
Please refer to for remediation steps

What are the RHEL5 updates that actually patch this issue?

The fix is in "glibc-2.5-123.el5_11.1."

Hi Team,
All my servers are RHEL5.5 - I have tried downloading the errata RPMs and updating it (rpm -Uvh glibc-* nscd*), but facing the below library dependency issue. Can you please provide the "base URL" path for the repository configuration to update the glibc using "yum update".

Error :
error: Failed dependencies: is needed by nscd-2.5-123.el5_11.1.ia64 is needed by nscd-2.5-123.el5_11.1.ia64 is needed by nscd-2.5-123.el5_11.1.ia64 is needed by nscd-2.5-123.el5_11.1.ia64 is needed by nscd-2.5-123.el5_11.1.ia64 is needed by nscd-2.5-123.el5_11.1.ia64 is needed by nscd-2.5-123.el5_11.1.ia64 is needed by nscd-2.5-123.el5_11.1.ia64 is needed by nscd-2.5-123.el5_11.1.ia64 is needed by nscd-2.5-123.el5_11.1.ia64 is needed by nscd-2.5-123.el5_11.1.ia64

Please open a support case, attaching the sosreport from the server in question.

I realise that RHEL 3 has reached EOL. But we purchase "Red Hat Enterprise Linux Extended Life Cycle" support for these servers. I was under the impression that this meant we would still be able to get fixes for critical vulnerabilities. If this is not the case, what does extended life cycle subdcription give us?


RHEL 3 's extended life cycle support phase got over by January 2014. You can use ELS subscription for obtaining critical updates for RHEL4.

Refer the below url for more information

From the page I linked above, you can see that Extended Lifecycle Support (ELS) started on October 31, 2010 and ended at said January 30, 2014. As much as we'd like to support all of our products for ever, even the most extended support offerings have an expiration date, which means no more updates :-) Your best bet is upgrading to a newer version of RHEL. RHEL 4 currently offers ELS until March 31, 2017.

I have RHEL 4 servers but when i do up2date -l glibc it says that the server is already up to date but when running the script it says that it is vulnerable.
cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 9)
rpm -qa glibc

up2date -l glibc

Fetching Obsoletes list for channel: rhel-i386-es-4...

Fetching rpm headers...

Name Version Rel Arch

The following packages you requested are already updated:

Installed glibc version(s)
- glibc-2.3.4-2.57.i686: vulnerable

any ideas


Do you have Red Hat Enterprise Linux 4 Extended lifecycle support subscription ?. If not, then you need this subscription to access the latest updates.

Please contact Sales if you do not have the subscription . If you are not able to update the package inspite of having the ELS subscription, then please contact Red Hat Technical Support

I have a selection of servers that have no connection to the internet.
The O/S versions include 5.4 , 5.7, 6.0, 6.1, 6.3, 6.4, 6.5 and 6.6 so I have downloaded the
recommended packages from RHSA-2015:0090-1 & RHSA-2015:0092-1 and am using
"yum localinstall ..." to apply the security fix(es).

First off: Am I doing something stupid in the above approach or is it valid?

Some servers have worked fine but there seems to be something missing in that list as if I try
to patch a server running 2.6.32-279.el6.i686 then although it will (reasonably) not accept any
x86_64 rpms, it still requires glibc-common-2.12-1.149.el6_6.5 and there is no .i686 version listed.

Can anyone straighten me out on this please?



Hi Frank,

To answer your first question: there's nothing wrong in that approach.

Regarding the second question: if you trying apply updates on a 32bit version of RHEL, ensure the download the following dependencies:

Download and install the following packages from the portal:
- glibc-common
- glibc-devel
- glibc-headers
- nscd

And install them in one go, ie "yum locainstall glibc glibc-common....

Hi Sibu,
That worked fine - thanks!

Would this patch have any chance to cause apps (Oracle, Websphere, etc) to misbehave?

What sort of testing would be wise during patch rollout aside from the glibc/nscd version check?

Given a range of RH5 and RH6 systems, the onus is on me to assure the patch will do no harm to all current production apps, aside from the reboot. a statement from Redhat would be very helpful.

There can be application impacts if they are not compatible with the glibc-* upgrades.
This should not happen in most cases. The times that it could happen is if a very old glibc version is in use. We don't expect that there should be a problem, but if you are concerned please review the application compatibility guide:

Red Hat Enterprise Linux: Application Compatibility GUIDE

Last Friday, the packages for 2015:0101 were available through this search:

Now that search comes up empty. A search for RHEL v4 and glibc at that site also comes up emtpy. I have ELS access. I want to download the packages, not use up2date directly via RHN. Where can I get the RHEL v4 ELS updates for CVE 2015-0235?


I have a server that have no connection to the internet.

The O/S versions is 5.4 ,so I downloaded the recommended packages from RHSA-2015:0090


and I used to apply the security fix(es) to force the circular dependencies.

$ rpm -Fvh glibc*
$ rpm -Fvh nscd*

But it gave the errors bellow due to dependencies I think.

rpm - Fvh glibc*

attention: glibc-2.5-123.el5_11.1.i386.rpm: Entete V3 DSA signature: NOKEY, key ID 37017186
attention: package glibc = 2.5-123.el5_11.1 was already added, skipping glibc < 2.5-123.el5_11.1
erreur: Dependances requises:
glibc = 2.5-42 est necessaire pour (deja installé) nscd-2.5-42.i386

rpm -Fvh nscd*

attention : nscd-2.5-123.el5_11.1.i386.rpm: Entete V3 DSA signature : NOKEY, key ID 37017186
erreur; Dependances requises:
glibc = 2.5-123.el5_11.1 est necessaire pour nscd-2.5-123.el5_11.1.i386

What is the best way to apply those erradata and the command to do that?

Can anyone advise me on this please?


Hi Ismail,

Please try as below:

rpm -Fvh glibc*

It gives the same error as I mentionned on my first post

rpm -Fvh glibc*

attention: glibc-2.5-123.el5_11.1.i386.rpm: Entete V3 DSA signature: NOKEY, key ID 37017186
attention: package glibc = 2.5-123.el5_11.1 was already added, skipping glibc < 2.5-123.el5_11.1
erreur: Dependances requises:
glibc = 2.5-42 est necessaire pour (deja installé) nscd-2.5-42.i386

Hi Ismail,

Sorry there was a typo in my command. Please run the below:

rpm -Fvh glibc* nscd*

If the issue persist, please open a support case.


I managed to get the dependencies working with this command #yum localinstall *.rpm

but I got only one dependency missing with glibc-utils, the

Can you tell me what package contain this library?


Hello Salah,

Try this: # yum search libgd

It shows the following:

============================================================================ Matched: libgd ============================================================================
gd.i686 : A graphics library for quick creation of PNG or JPEG images
gd.x86_64 : A graphics library for quick creation of PNG or JPEG images
gnome-utils-libs.i686 : gnome-utils libraries
gnome-utils-libs.x86_64 : gnome-utils libraries


I have a problem performing the manual update, when i try to update, it shows conflict as below:-

rpm -q glibc
rpm -q glibc-common

rpm -ivh glibc-2.5-123.el5_11.1.i686.rpm
warning: glibc-2.5-123.el5_11.1.i686.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
error: Failed dependencies:
glibc-common = 2.5-123.el5_11.1 is needed by glibc-2.5-123.el5_11.1.i686

rpm -ivh glibc-common-2.5-123.el5_11.1.x86_64.rpm
from install of glibc-common-2.5-123.el5_11.1.x86_64 conflicts with file from package glibc-common-2.5-42.x86_64

What is the correct way to perform a manual update?

Thanks and regards,

As per the information that you have shown in your post, you need to download both 32bit and 64 bit version of glibc and 64 bit version of glibc-common

After downloading the above package use rpm -Uvh <pkgname1.rpm> <packagemam2.rpm> <packagename-3.rpm>

If you are still noticing any issues, then I would recommend you to contact Red Hat Technical Support

Hello Kwan,

Try rpm -Uvh instead of -ivh since the package is already installed

Please post "rpm -qa glibc" output so the packages installed and their architectures can be reviewed.

Please help!
We want to download glibc-devel-2.3.4-2.57.el4.2.i386.rpm, where can we find it ?
We has a ELS.

Can you contact Red Hat Technical Support so that we can provide you with the required download url

Hello Ranjith Rajaram
How can I contact Red Hat Technical Support ? By mail or by phone ?
I am a new one , so please show me some more detail information.


Via Web:
You should see "open a support case" option
Via Phone

download URL for glibc-devel-2.3.4-2.57.el4.2.i386.rpm

Please contact Technical support if you notice any dependency issues

Hello Ranjith Rajaram
Thanks a lot.
I accessed URL you listed, and found glibc-devel-2.3.4-2.57.el4.2.i386.rpm.

Hello Ranjith Rajaram
Now I have understood what I should do.
I downloaded all rpms that lised on for x86_64 platform.

Hi ,
I am facing issue while doping manual update ,

[root@opscenter opscenter]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.8 (Tikanga)
[root@opscenter opscenter]# uname -i

So I have downloaded and updated the x86_64 glibc packages with depencies..

[root@opscenter opscenter]# rpm -q glibc

[root@opscenter opscenter]# ./
Installed glibc version(s)
- glibc-2.5-81.i686: vulnerable
- glibc-2.5-123.1.x86_64: not vulnerable

This system is vulnerable to CVE-2015-0235.
Please refer to for remediation steps

Now the package with i686 showing vulnerable , So I have downloaded i686 glibc package and tried to install it but receiving below error,

[root@opscenter opscenter]# rpm -Uvh glibc-2.5-123.el5_11.1.i686.rpm --nodeps
warning: glibc-2.5-123.el5_11.1.i686.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing... ########################################### [100%]
package glibc-2.5-123.1.x86_64 (which is newer than glibc-2.5-123.el5_11.1.i686) is already installed

Kindly help me on the same .Thanks in advance.

You should never use nodeps especially when upgrading glibc packages.

Looking at this information

[root@opscenter opscenter]# rpm -q glibc

Looks like you have already upgraded the glibc package without resolving the dependencies

From where did you download glibc-2.5-123.1.x86_64 package ?. I did a quick search I can't seem to find it in our Red Hat customer portal

It would request you to contact Red HatTechnical support so that we can resolve the request as it needs a little bit of care

I have upgraded the dependencies packages also

[root@opscenter opscenter]# rpm -qa | grep glibc

I have upgraded the below mentioned packages,

[root@opscenter opscenter]# ls -ltr /usr/src/redhat/RPMS/x86_64/
total 87164
-rw-r--r-- 1 root root 5015812 Feb 10 13:40 glibc-2.5-123.1.x86_64.rpm
-rw-r--r-- 1 root root 627069 Feb 10 13:40 glibc-headers-2.5-123.1.x86_64.rpm
-rw-r--r-- 1 root root 2548275 Feb 10 13:40 glibc-devel-2.5-123.1.x86_64.rpm
-rw-r--r-- 1 root root 181401 Feb 10 13:41 nscd-2.5-123.1.x86_64.rpm
-rw-r--r-- 1 root root 142958 Feb 10 13:41 glibc-utils-2.5-123.1.x86_64.rpm
-rw-r--r-- 1 root root 17444754 Feb 10 13:41 glibc-common-2.5-123.1.x86_64.rpm

I have downloaded the sorce rpm from redhat ftp site only..


Not sure why you download the source package instead of directly downloading the relevant rpms (i386/x86_64) from the portal.

When you compiled the package, the version of the package has been changed. The compiled package is technically one version higher than what is shipped with RHEL5

This is why you are getting the following message

"package glibc-2.5-123.1.x86_64 (which is newer than glibc-2.5-123.el5_11.1.i686) is already installed"

So now you have downloaded the i686 version from the portal. Same way you could have downloaded the relevant x86_64 version from portal for RHEL5 instead of compiling it from source provided you are not including any other custom patches

There is an option --oldpackage which can be used with the rpm command. I wouldnt recommend to use it as of now as you might get other warnings

I would request you to contact Red Hat Technical support so that we can help you to revert the packages and upgrade the glibc i686 packages


As per Red Hat SLA, Red Hat does not provide support for issues that arises from the usage of custom compiled packages.

Support is not provided even if you use the source package provided by Red Hat. SLA for reference [Custom compiled rpms are considered as modified rpm's]

Hi Ranjith ,

Now we are doing it in the testing phase only . Once it gets upgraded correctly we will move to production.For this issue case has been raised.

So for all other servers we have to do manual upgrade only .

I have try to upgrade in different server without --nodeps option as given below,

$ rpm -Uvh glibc-2.5-123.el5_11.1.x86_64.rpm
warning: glibc-2.5-123.el5_11.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
error: Failed dependencies:
glibc-common = 2.5-123.el5_11.1 is needed by glibc-2.5-123.el5_11.1.x86_64

$ rpm -Uvh glibc-common-2.5-123.el5_11.1.x86_64.rpm
warning: glibc-common-2.5-123.el5_11.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
error: Failed dependencies:
glibc-common = 2.5-81 is needed by (installed) glibc-2.5-81.x86_64
glibc-common = 2.5-81 is needed by (installed) glibc-2.5-81.i686

So kindly guide us steps to do manual upgrade and also dependency packages issues.

Since you have raised a case, you will get further help from our Technical support. Lets dont use kbase comment option for support

This is what I would do

  1. rpm -qa --queryformat="%{name}-%{version}-%{release}.%{arch}\n" | grep glibc
    find all the glibc packages on the system
  2. Download all the relevant packages updates from the portal (both 64 bit and 32bit version) by comparing the existing packages
  3. rpm -Uvh .rpm
    .rpm packagesXXXX.rpm
    update the packages together

Hi Ranjith,

Thanks for the help. Successfully upgraded the packages.

rpm -qa |grep ^glibc

And also checked with GHOST script,

Installed glibc version(s)
- glibc-2.5-123.el5_11.1.x86_64: not vulnerable
- glibc-2.5-123.el5_11.1.i686: not vulnerable

Kindly let us know , Is the reboot is must.
Because we have to follow this for all production servers and it will cause more downtime. Or else any other way is there instead of reboot.

In the above kbase article, we have covered this topic under the heading "2. Reboot the system or restart all affected services"

I would recommend to reboot the system

It would be beneficial to update the tzdata package on the system to cover the leap second event as well

Hi Team,

We are facing below error on our environment after updating the glibc package.


Kongsberg.Intellifield.SiteCom.DatabaseFactory.DataLayerException: Native error: ORA-03113: end-of-file on communication channel

Redhat Case 01362449


Very less likely to be a glibc issue. Thank you for opening a support request


We have a internal yum repository which I have reposync'd to get all the latest updates

When we run yum update gblic on our Red Hat 6.5 clients

It only says glib version glibc-2.12-1.149.el6 which is reported as vulnerable

We need it to update to glibc-2.12-1.149.el6_6.5

Any ideas?

I have tried yum clean all and tried it on 2 different clients

Have you verified that the reposync has pulled all the latest packages

If the download path is /var/www/html, did you execute createrepo --update after reposync

example: createrepo --update /var/www/html

I have a RHEL 5.7 Server, a 5.2, a 5.9, etc. Did a "yum update glibc" on them all, and this package was installed: glibc-2.5-123.el5_11.1.x86_64.rpm. The script now reports that all the servers are not vulnerable anymore.
I've always thought that it was OK to install a RPM with a newer minor, as long it was in the same RHEL distro version. Example: Installing a 6_6 rpm in a 6_2 server.

But as I read this comments I find out that this is not advisable. But it can be done anyway!? God, this is so confusing!

Is there a patch available for glibc-2.5-117 for x86_64 RHEL server 5.10?


On your RHEL 5.10 system run the following command to determine if there is an update for glibc:

yum list update glibc

This should tell you if a patch is available. I observed on other versions including older 5.x versions that updates were available.

My server corrupted two times during glibc patching upgrading,The server stuck with segmentation fault and unable to boot.
Any body can share the reason

Please open a support case to investigate the issue.

Based on this articele could you clarify whether this will affect Apache webser.What temporaly solution can be done apart from patching.
We had an issue of segmentation fault during upgrading glibc package to RHEL 5.9(32BIT) and as a result OS corrupted.
It is impossible for us to get sosreport after system corrupted

Apache server is also affected. There are no temporary workarounds. We could try to recover the system from rescue mode. It would be better to contact Red Hat Technical Support

Correction: Apache is not directly affected but can be used to exploit the vulnerability in glibc , Any application that uses gethostbyname. If you have a php application hosted in your webserver that ends up calling gethostbyname() can be used by a remote attacker to exploit the glibc vulnerability

I used rpm -uvh xxx to upgrade the patch in rhel 5.9.When execute the command can see the status of the updating,But suddenly it is giving segmentation fault and as a result OS corrupted.Our server running with xen package installed and two vm on the physical server.

Kia, this is not something anyone can troubleshoot with you via a knowledgebase article. Please open a support case.

Hi ,
I had sementation fault issue during glibc upgrade .
This is the affected server(Linux myedu3fe1 2.6.18-371.9.1.el5xen #1 SMP Tue May 13 06:59:31 EDT 2014 i686 i686 i386 GNU/Linux).This is a VM

This is server abled to updated sucessfully(Linux myedu3db2 2.6.18-402.el5PAE #1 SMP Thu Jan 8 06:43:53 EST 2015 i686 i686 i 386 GNU/Linux).This is physical server
Is there any difference between causing segmentation fault.