View Issue Details

IDProjectCategoryView StatusLast Update
0010930CentOS-6curlpublic2016-07-23 04:54
Reporterpko Assigned To 
Status newResolutionopen 
Summary0010930: curl -> Illegal Instruction after centos 6.8 update
DescriptionAfter upgrading to centos 6.8, all https curl requests are failing:

% curl
Illegal Instruction
% echo $?

This is affecting some servers, but apparently not 100%. We've seen it so far on two separate servers. Downgrading curl, libcurl, and libcurl-devel to the versions provided in CentOS 6.7 fixes the problem.
Tags6.8, nss


2016-05-26 18:06

reporter   ~0026700

We were able to identify that AVX cpu flag is in charge here:

# cat /proc/cpuinfo | grep -i avx

It all started with PK11_Encrypt() function from /usr/lib64/ which belongs to nss-3.21.0-8.el6.x86_64 .

Some debug information:

Program received signal SIGILL, Illegal instruction.
0x00007ffff1100d60 in ?? () from /usr/lib64/
(gdb) bt
#0 0x00007ffff1100d60 in ?? () from /usr/lib64/
#1 0x00007ffff10fd998 in ?? () from /usr/lib64/
#2 0x00007ffff10c6b36 in ?? () from /usr/lib64/
#3 0x00007ffff10c70f3 in ?? () from /usr/lib64/
#4 0x00007ffff15cfaef in ?? () from /usr/lib64/
#5 0x00007ffff15d0551 in ?? () from /usr/lib64/
#6 0x00000031a3847fee in PK11_Encrypt () from /usr/lib64/
#7 0x00000031a24156e9 in ?? () from /usr/lib64/
#8 0x00000031a240f9b9 in ?? () from /usr/lib64/
#9 0x00000031a240fea2 in ?? () from /usr/lib64/
#10 0x00000031a2410267 in ?? () from /usr/lib64/
#11 0x00000031a2414c5c in ?? () from /usr/lib64/
#12 0x00000031a2415d7a in ?? () from /usr/lib64/
#13 0x00000031a2419bea in ?? () from /usr/lib64/
#14 0x00000031a241afd2 in ?? () from /usr/lib64/
#15 0x00000031a241bebf in ?? () from /usr/lib64/
#16 0x00000031a241e832 in ?? () from /usr/lib64/
#17 0x00000031a2425b75 in ?? () from /usr/lib64/
#18 0x00000031a24273af in SSL_ForceHandshake () from /usr/lib64/
#19 0x00007fffece4b868 in ?? () from /usr/lib64/
#20 0x00007fffece431c5 in Curl_ssl_connect () from /usr/lib64/
#21 0x00007fffece21b4b in Curl_http_connect () from /usr/lib64/
#22 0x00007fffece282f2 in Curl_protocol_connect () from /usr/lib64/
#23 0x00007fffece2e885 in Curl_connect () from /usr/lib64/
#24 0x00007fffece368c0 in Curl_perform () from /usr/lib64/

(gdb) x /i 0x00007ffff1100d60
=> 0x7ffff1100d60: vmovdqu (%rsi),%xmm0

The quick workaround is:


2016-05-26 20:32

reporter   ~0026702

fwiw this also seems to fix it for the session:


We're up to 5 servers experience this problem over the last 48 hours and it seems to be accelerating.


2016-05-27 07:58

reporter   ~0026705

Seems to be the same issue as the recent problem occurring between RHEL 6.8 and Xen Hypervisor:
(article available for RHEL subscribes only)

This fix works for me:
# yum downgrade nss nss-util nss-tools nss-sysinit
# yum install yum-plugin-versionlock
# yum versionlock add! nss-3.21.0-0.3.el6_7.x86_64 nss-sysinit-3.21.0-0.3.el6_7.x86_64 nss-tools-3.21.0-0.3.el6_7.x86_64 nss-util-3.21.0-0.3.el6_7.x86_64


2016-05-28 06:19

reporter   ~0026717

We had similar CURL problems. We additionally had problems with silent failures in WordPress admin dashboard pages - no logged errors and null output.

We are a tenant in an OpenStack hosting environment which is using KVM. Our upstream provider moved our instance to a newer hypervisor array and all of our problems disappeared.

The instance in question has been incrementally upgraded through multiple 6.x releases for the past two years on the old hypervisor without incident. There is definitely something in 6.8 which is "sensitive" perhaps to discrepancies between advertised CPU capabilities and what the VM is actually presented with.


2016-05-28 10:05

reporter   ~0026718

I'm using 6.8 on a 1&1 virtual machine. I had similar errors with WordPress admin pages, and https Wordpress pages.

I couldn't get yum to downgrade curl, so the fix I used:

rpm -Uvh --oldpackage ./curl-7.19.7-46.el6.x86_64.rpm ./libcurl-7.19.7-46.el6.x86_64.rpm
yum install yum-plugin-versionlock
yum versionlock curl
yum versionlock libcurl


2016-05-28 20:08

reporter   ~0026719

I had a similar issue with PHP-FPM crashing (dumping cores) whenever PHP was using CURL to setup connections.

A workaround was to set all CURL connections to use SSLv3 (instead of TLSv1 which seems to be causing issues: curl_setopt($this->_getResource(), CURLOPT_SSLVERSION, 3);

Also a simple command-line "curl" crashed, but was fixed by setting NSS_DISABLE_HW_GCM=1.

Both solutions were not acceptable for me. Instead, I downgraded the following 5 packages from the folder mentioned by @Ipcollier and this worked to get all PHP applications with CURL usage working again: nss, nspr, nss-sysinit, nss-tools, nss-util

2016-05-28 21:27

reporter   ~0026720

This appears to be effecting openjdk as well. Anyone have any crafty suggestions on how to temporarily address this (exporting the suggested variables didn't seem to have an effect (a shot in the dark I know but, it's pretty critical for me to get this working))? I'm seeing this manifested with this log entry in tomcat.

28-May-2016 13:49:41.427 SEVERE [http-nio-443-exec-12]$SocketProcessor.doRun
 java.lang.RuntimeException: Could not generate DH keypair
        at java.util.concurrent.ThreadPoolExecutor.runWorker(
        at java.util.concurrent.ThreadPoolExecutor$
        at org.apache.tomcat.util.threads.TaskThread$
Caused by: java.lang.RuntimeException: Could not generate DH keypair
        at Method)
        ... 7 more
Caused by: Unknown curve name:
        ... 19 more


2016-05-28 21:53

administrator   ~0026721

I don't have the issue on bare metal without avx support, upgraded from 6.7.

model name : AMD Turion(tm) II Neo N54L Dual-Core Processor
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp
 lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx1
6 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowpr
efetch osvw ibs skinit wdt nodeid_msr npt lbrv svm_lock nrip_save

[tru@n54l ~]$ rpm -q kernel nss nss-util nss-tools nss-sysinit
[tru@n54l ~]$ uname -a
Linux n54l.home 2.6.32-642.el6.x86_64 #1 SMP Tue May 10 17:27:01 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[tru@n54l ~]$ curl
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<H1>302 Moved</H1>
The document has moved

[tru@n54l ~]$ grep -i avx /proc/cpuinfo
[tru@n54l ~]$ echo $?


2016-05-31 13:50

reporter   ~0026730

We had the same issue after a 'yum update --disablerepo=epel' and then trying to do a regular update.

# yum update
Loaded plugins: fastestmirror
Setting up Update Process
Loading mirror speeds from cached hostfile
Illegal instruction

# tail /var/log/messages
May 31 11:08:03 smtpout2 kernel: yum[1514] trap invalid opcode ip:7ff1742afd60 sp:7ffd78372ed8 error:0 in[7ff17425d000+72000]

The machine is centos6 running as a virtual machine within xenserver. /proc/cpuinfo does not show avx support.

I setup a test box and was able to fully update it but excluded 3 packages so I still had these old versions :-
'yum makecache' worked fine. I used makecache as it forces the https connected to the epel repo which was the one causing the issue.
As soon as I updated 'nss' with the other two updating as required dependencies I had the same problem.

I fixed my broken box by downloading the old versions of nss manually and using 'rpm -Uvh nss*' to downgrade.


2016-05-31 19:36

reporter   ~0026735

Redhat hadn't post an update since friday.

Looks like a harder issue or a seldom issue.

Is it the AVX or the AES flag.
I had a few machines on XEN with a provider. And nss had the issue when AES flag was available. No AVX flags on any Xen host available to the virtual machines.


2016-05-31 20:23

reporter   ~0026737

I too fixed it by using the older versions of nss*. Clearly, a bug on the CentOS/RedHat side.

2016-05-31 22:47

reporter   ~0026739

We were able to solve our issue by recovering "/usr/lib64/" from a backup that we had from before the nss update and overwriting the current file. The system still thinks that it is running the latest version of nss as well so yum will not try to update nss until there is a newer version at which point the new version may have the fix we need.

On one of our servers we did not have a backup of "/usr/lib64/" so we used the file from a different server. Not sure if this is the best practice but it fixed our issue and we have not seen any other issue arise.


2016-06-01 10:31

reporter   ~0026740

We had this exact issue with a Rackspace Cloud Server, I did the following steps to downgrade my NSS to the EPEL 6.7 RElease

Also export NSS_DISABLE_HW_GCM=1 did work nicely

cd /root/
rpm -Uvh --force nss*

yum install yum-plugin-versionlock
yum versionlock add! nss nss-sysinit nss-tools


2016-06-02 18:45

reporter   ~0026758

I, too, can confirm that using any binary that makes a call to NSS segfaults with a message like the following:

git-remote-http[2882] trap invalid opcode ip:7f35c5784d60 sp:7ffe90e41a38 error:0 in[7f35c5732000+72000]

I am running CentOS 6.8 on a Xen hypervisor. I was able to resolve the issue by performing the following steps:

1) cd ~/
2) mkdir RPM-Downgrade; cd RPM-Downgrade
3) wget
4) wget
5) wget
6) wget
7) yum downgrade ./*.rpm

I verified services and applications are running as expected with the downgraded NSS, post-reboot.


2016-06-02 18:51

reporter   ~0026759

I forgot to state the following step in my notes above:

0) export NSS_DISABLE_HW_AES=1
[...] Proceed with steps 1 - 7


2016-06-06 09:24

reporter   ~0026795

We too have encountered an issue similar to that reported by We run Wildfly 10 application server ( on top of openjdk.

2016-05-26 15:15:48,363 ERROR [org.xnio.nio] (default I/O-1) XNIO000011: Task io.undertow.protocols.ssl.SslConduit$4$1@a54c7d5 failed with an exception: java.lang.RuntimeException: Could not generate DH keypair
        at io.undertow.protocols.ssl.SslConduit.doUnwrap(
        at io.undertow.protocols.ssl.SslConduit.doHandshake(
        at io.undertow.protocols.ssl.SslConduit.access$600(
        at io.undertow.protocols.ssl.SslConduit$4$
        at org.xnio.nio.WorkerThread.safeRun(
Caused by: java.lang.RuntimeException: Could not generate DH keypair
        at Method)
        at io.undertow.protocols.ssl.SslConduit$
        at java.util.concurrent.ThreadPoolExecutor.runWorker(
        at java.util.concurrent.ThreadPoolExecutor$
Caused by: Unknown curve name:
        ... 14 more

Using on an affected server shows "Protocol or cipher suite mismatch" at handshake simulations for following clients

Android 4.0.4
Android 4.1.1
Android 4.2.2
Android 4.3
BingPreview Jan 2015
Googlebot Feb 2015
OpenSSL 1.0.1l
YandexBot Jan 2015

Changing to an earlier version does not resolve the issue but downgrading openjdk back to does work.

yum --releasever=6.7 downgrade java-1.8.0-openjdk java-1.8.0-openjdk-headless
yum install yum-plugin-versionlock
yum versionlock java-1.8.0-openjdk java-1.8.0-openjdk-headless

This issue seems to be similar to one fixed in Fedora:


2016-06-10 16:20

reporter   ~0026844

***Absolutely no warranty/support on any of this***

I've pushed this nss-softokn RPMs into a repo for internal use based on the original Mozilla fix pushed back in 2013. (

If you use this repo with yum-plugin-priorities and set it higher priority than base and updates, you'll get nss-softokn updates from here and not have them reverted by CentOS updates. However, I will discontinue this repo if/when RH pushes a fix upstream, so priorities may mask those package updates once that occurs.


2016-06-24 12:49

reporter   ~0026964

not only did these work;
    export NSS_DISABLE_HW_AES=1;
    export NSS_DISABLE_HW_GCM=1;
    export NSS_DISABLE_HW_AVX=1;

but also this works;
    export NSS_DISABLE_HW_GCM=0;


2016-07-12 18:56

reporter   ~0027049

Red Hat has publicly released the fix to this issue.


2016-07-13 21:31

reporter   ~0027054

I think we can close this now.
    export NSS_DISABLE_HW_GCM=0;yum upgrade
which seems to have fixed the issue.


2016-07-15 21:34

reporter   ~0027066

Its fixed for me as well, with the latest nss updates.

2016-07-23 04:54

reporter   ~0027111

People who are still facing this issue, just run "NSS_DISABLE_HW_GCM=1 yum update", this will updated the NSS package to latest version in which the issue is already fixed.

Issue History

Date Modified Username Field Change
2016-05-26 15:10 pko New Issue
2016-05-26 18:06 Note Added: 0026700
2016-05-26 20:32 pko Note Added: 0026702
2016-05-27 07:58 kaz Note Added: 0026705
2016-05-28 06:19 razyr Note Added: 0026717
2016-05-28 10:05 lpcollier Note Added: 0026718
2016-05-28 20:08 jissereitsma Note Added: 0026719
2016-05-28 21:27 Note Added: 0026720
2016-05-28 21:53 tru Note Added: 0026721
2016-05-31 13:50 barritel-gblades Note Added: 0026730
2016-05-31 19:36 lixdeg Note Added: 0026735
2016-05-31 20:23 locojohn Note Added: 0026737
2016-05-31 22:47 Note Added: 0026739
2016-06-01 10:31 gavin-markup Note Added: 0026740
2016-06-02 18:45 applematt84 Note Added: 0026758
2016-06-02 18:51 applematt84 Note Added: 0026759
2016-06-06 09:24 akuusela Note Added: 0026795
2016-06-10 16:20 kstange Note Added: 0026844
2016-06-24 12:49 TimL Note Added: 0026964
2016-07-12 18:56 troyengel Note Added: 0027049
2016-07-13 21:31 TimL Note Added: 0027054
2016-07-15 21:34 devhen Note Added: 0027066
2016-07-20 16:24 sandalle Tag Attached: 6.8
2016-07-20 16:24 sandalle Tag Attached: nss
2016-07-23 04:54 Note Added: 0027111