Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1482798 - Illegal instruction in SHA1_Update() when used by chronyd
Summary: Illegal instruction in SHA1_Update() when used by chronyd
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nss-softokn
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kai Engert (:kaie) (inactive account)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1507938 1519148 (view as bug list)
Depends On:
Blocks: x86Tracker
TreeView+ depends on / blocked
 
Reported: 2017-08-18 06:11 UTC by Tomasz Torcz
Modified: 2017-12-02 21:22 UTC (History)
12 users (show)

Fixed In Version: nss-softokn-3.34.0-1.0.fc27 nss-softokn-3.34.0-1.0.fc25 nss-softokn-3.34.0-1.0.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-27 21:23:51 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 1400603 0 P1 RESOLVED Reorganize AES-GCM source code based on hw/sw implementation 2020-07-05 01:08:13 UTC

Description Tomasz Torcz 2017-08-18 06:11:22 UTC
Description of problem:
Recently I noticed 'chronyd' aborts during startup with Illegal Instruction. When run under 'gdb', there error happens in SHA1_Update() function inside libfreeblpriv3.so:

(gdb) run -d                              
Starting program: /usr/sbin/chronyd -d

Program received signal SIGILL, Illegal instruction.                                 
0xb7ac2aea in SHA1_Update () from /lib/libfreeblpriv3.so                             

(gdb) bt                                  
#0  0xb7ac2aea in SHA1_Update () from /lib/libfreeblpriv3.so                         
#1  0x80017ef2 in HSH_Hash (id=1, in1=0x800446a0 "2\263$|m\273\230P\177J\265R\270\367`\016\016L\340\301\001\001\001\001", in1_len=20, in2=in2@entry=0xbfffea94 "",        
    in2_len=in2_len@entry=48, out=out@entry=0xbfffeac8 "\200A\004\200\276g", out_len=out_len@entry=64) at hash_nss.c:84                                                   
#2  0x80029bb9 in generate_ntp_auth (auth_len=64, auth=0xbfffeac8 "\200A\004\200\276g", data_len=48, data=0xbfffea94 "", key_len=<optimized out>, key=<optimized out>,    
    hash_id=<optimized out>) at keys.c:361                                           
#3  KEY_GenerateAuth (key_id=key_id@entry=1, data=data@entry=0xbfffea94 "", data_len=data_len@entry=48, auth=auth@entry=0xbfffeac8 "\200A\004\200\276g",                  
    auth_len=auth_len@entry=64) at keys.c:392                                        
#4  0x8002a02a in determine_hash_delay (key_id=1) at keys.c:112                      
#5  KEY_Reload () at keys.c:254           
#6  0x80002cbd in main (argc=2, argv=0xbffff464) at main.c:529        


Hardware is 32bit
Vendor ID:           AuthenticAMD
CPU family:          6
Model:               8
Model name:          AMD Sempron(tm)
Stepping:            1


Apparently there is some miscompilation in libfreeblpriv3.

Version-Release number of selected component (if applicable):
chrony-3.2-0.3.pre1.fc27.i686
nss-softokn-freebl-3.32.0-4.fc27.i686

Comment 1 Tomasz Torcz 2017-08-20 08:21:32 UTC
Also in dmesg:
[309771.607302] traps: chronyd[20326] trap invalid opcode ip:b73cdaea sp:bfbdd090 error:0 in libfreeblpriv3.so[b73ca000+6d000]

Comment 2 Daiki Ueno 2017-08-21 09:18:40 UTC
(In reply to Tomasz Torcz from comment #0)
> Description of problem:
> Recently I noticed 'chronyd' aborts during startup with Illegal Instruction.

Does this only happen with NSS 3.32.0, not with 3.31.0?

Comment 3 Tomasz Torcz 2017-08-21 17:36:49 UTC
It happens with nss-3.31.0-6.fc27.i686.rpm, too.

Comment 4 z117 2017-08-26 10:45:10 UTC
I have the same problem with Fedora 26 on Pentium III:
(dmesg example)
[  113.768573] traps: rpm[1014] trap invalid opcode ip:b6cb1aca sp:bfd6fea0 error:0 in libfreeblpriv3.so[b6cae000+6d000]
[  165.212819] traps: dnf[1050] trap invalid opcode ip:b5207aca sp:bf8778c0 error:0 in libfreeblpriv3.so[b5204000+6d000]
[  184.468669] traps: rpm[1055] trap invalid opcode ip:b6cc9aca sp:bfcb99c0 error:0 in libfreeblpriv3.so[b6cc6000+6d000]
[  287.889120] traps: rpm[1127] trap invalid opcode ip:b6c17aca sp:bfbd8530 error:0 in libfreeblpriv3.so[b6c14000+6d000]
[  633.854490] traps: dnf[1146] trap invalid opcode ip:b5265aca sp:bfd777c0 error:0 in libfreeblpriv3.so[b5262000+6d000]
[  835.699086] traps: curl[1160] trap invalid opcode ip:b5d86aca sp:bfdeaa80 error:0 in libfreeblpriv3.so[b5d83000+6d000]
[  886.525060] traps: rpm[1240] trap invalid opcode ip:b6b84aca sp:bfad5970 error:0 in libfreeblpriv3.so[b6b81000+6d000]
[  886.725567] traps: rpm[1244] trap invalid opcode ip:b6b68aca sp:bf8650f0 error:0 in libfreeblpriv3.so[b6b65000+6d000]

Downgrading nss-softokn-freebl-3.32.0-1.2.fc26.i686 to nss-softokn-freebl-3.30.2-1.0.fc26.i686 solves the issue.

Comment 5 Daiki Ueno 2017-08-28 07:56:25 UTC
Would it be possible to check which instruction is actually used, with "x/i <address>" in gdb?

Comment 6 Tomasz Torcz 2017-08-28 14:08:28 UTC
Program received signal SIGILL, Illegal instruction.
0xb7afcaea in SHA1_Update (ctx=0x80044c40, dataIn=0x800446a0 "2\263$|m\273\230P\177J\265R\270\367`\016\016L\340\301\001\001\001\001", len=20) at sha_fast.c:101

gives

(gdb) display/i 0xb7afcaea
1: x/i 0xb7afcaea
=> 0xb7afcaea <SHA1_Update+58>:	paddq  %xmm2,%xmm0


According to http://www.felixcloutier.com/x86/PADDQ.html, it is SSE2 instruction. This CPU has

Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall

Only SSE1.

I don't think we agreed to require SSE2 on i686.

Comment 7 Bob Relyea 2017-08-28 20:32:28 UTC
Davide Repetto's comment was clobbered: restoring it.

--- Comment #1 from Davide Repetto <red> ---
Something similar may have happened to centos in the past:
https://bugs.centos.org/view.php?id=11074

Comment 8 Bob Relyea 2017-08-28 20:46:04 UTC
Now that I look at David's comment, It has to do with AES_GCM speedups which looked at the CPU bits to determine if they speedups were doable, but didn't look to see if the OS could save and restore the SSE3 registers. THE SHA1 code is straight C code (except some byte swap macros which don't use SSE2), so it sounds like we need to tweak the compiler options to make sure it's not generating SSE2 instructions.

Comment 9 Eugene Kanter 2017-09-10 14:53:46 UTC
Same problem here. What makes matters almost catastrophic is that rpm and dnf can't be used any more and one will have to update package by other means, for example by mounting via sshfs, when new nss-softokn build is available.
Attempt to downgrade to the previous version also fails as no lower nss-tools version available.

Comment 10 Jeff Backus 2017-09-11 17:16:34 UTC
Hi all, I apologize for my confusion. Has this been resolved? 

FYI, I've also added this to the x86 tracker bug.

Comment 11 Tomasz Torcz 2017-09-11 17:18:44 UTC
No, it hasn't, Jeff.

Comment 12 Daiki Ueno 2017-09-12 13:47:05 UTC
(In reply to Tomasz Torcz from comment #6)

> (gdb) display/i 0xb7afcaea
> 1: x/i 0xb7afcaea
> => 0xb7afcaea <SHA1_Update+58>:	paddq  %xmm2,%xmm0
[...]
> I don't think we agreed to require SSE2 on i686.

Thank you for investigating this.

(In reply to Bob Relyea from comment #8)
> Now that I look at David's comment, It has to do with AES_GCM speedups which
> looked at the CPU bits to determine if they speedups were doable, but didn't
> look to see if the OS could save and restore the SSE3 registers. THE SHA1
> code is straight C code (except some byte swap macros which don't use SSE2),
> so it sounds like we need to tweak the compiler options to make sure it's
> not generating SSE2 instructions.

I think I managed to disable SSE2 in freebl, at least for the SHA-1 code.  The upstream enabled the -mpclmul compiler option globally, which seems to imply the compiler generates SSE2 code.

The current fix is to limit the effect of -mpclmul to AES and GCM:
http://pkgs.fedoraproject.org/cgit/rpms/nss-softokn.git/tree/nss-softokn-disable-sse2.patch?h=f27

Comment 13 Fedora Update System 2017-09-12 13:49:42 UTC
nss-softokn-3.32.0-7.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-d924f2b4ba

Comment 14 Fedora Update System 2017-09-12 19:57:59 UTC
nss-softokn-3.32.0-7.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d924f2b4ba

Comment 15 Eugene Kanter 2017-09-13 02:06:21 UTC
Will there be an identical package for fc26?

Comment 16 Eugene Kanter 2017-09-13 03:27:14 UTC
on a F26 system with sse2 CPU I downloaded http://mirror.math.princeton.edu/pub/fedora/linux/updates/testing/27/SRPMS/n/nss-softokn-3.32.0-7.fc27.src.rpm and rebuild using
mock -v --rebuild nss-softokn-3.32.0-7.fc27.src.rpm
then mounted disk on a F26 without sse2 system using sshfs
# sshfs root.x.x:/ /mnt
then copied rebuilt packages and installed them

# rpm -r /mnt -Uvh /mnt/root/{nss-softokn-freebl-3.32.0-7.fc26.i686.rpm,nss-softokn-3.32.0-7.fc26.i686.rpm}

rpm started working but dnf still fails, but in a different function:

Stack trace of thread 4410:
                #0  0x00000000b51afa54 gcmHash_Update (libfreeblpriv3.so)

Comment 17 Eugene Kanter 2017-09-13 03:57:43 UTC
> The current fix is to limit the effect of -mpclmul to AES and GCM:
> http://pkgs.fedoraproject.org/cgit/rpms/nss-softokn.git/tree/nss-softokn-
> disable-sse2.patch?h=f27

Dump of assembler code for function gcmHash_Update:
   0xb5247a20 <+0>:	sub    $0x3c,%esp
   0xb5247a23 <+3>:	mov    %ebx,0x2c(%esp)
   0xb5247a27 <+7>:	mov    0x48(%esp),%ebx
   0xb5247a2b <+11>:	mov    0x40(%esp),%edx
   0xb5247a2f <+15>:	mov    %esi,0x30(%esp)
   0xb5247a33 <+19>:	mov    %edi,0x34(%esp)
   0xb5247a37 <+23>:	xor    %edi,%edi
   0xb5247a39 <+25>:	lea    0x0(,%ebx,8),%esi
   0xb5247a40 <+32>:	movd   %edi,%xmm0
   0xb5247a44 <+36>:	movd   %esi,%xmm1
   0xb5247a48 <+40>:	mov    0x50(%edx),%esi
   0xb5247a4b <+43>:	punpckldq %xmm0,%xmm1
   0xb5247a4f <+47>:	movq   0x64(%edx),%xmm0
=> 0xb5247a54 <+52>:	paddq  %xmm1,%xmm0


Is there a problem with mock environment or a package?

Comment 18 Daiki Ueno 2017-09-13 04:07:19 UTC
(In reply to Eugene Kanter from comment #16)

> rpm started working but dnf still fails, but in a different function:
> 
> Stack trace of thread 4410:
>                 #0  0x00000000b51afa54 gcmHash_Update (libfreeblpriv3.so)

It's a separate issue (maybe bug 1485656).  As I indicated in comment 12, I didn't disable optimizations in AES and GCM code because it triggered test failures.

Comment 19 Eugene Kanter 2017-09-13 15:53:02 UTC
(In reply to Daiki Ueno from comment #18)
> (In reply to Eugene Kanter from comment #16)
> 
> It's a separate issue (maybe bug 1485656).  As I indicated in comment 12, I
> didn't disable optimizations in AES and GCM code because it triggered test
> failures.

The sentence

>The current fix is to limit the effect of -mpclmul to AES and GCM

is hard to interpret and there is no mentions of any filed tests.

I updated bug 1485656 with current assembler dump. Thank you.

Comment 20 Daiki Ueno 2017-09-15 16:01:43 UTC
(In reply to Eugene Kanter from comment #19)

> I updated bug 1485656 with current assembler dump. Thank you.

Thank you.  In the end I came up with a patch to disable SSE2 even in AES-GCM:
https://github.com/ueno/nss/commit/385ae89cce762030769c7613bd0c81ec7e171bc3

The package is now building in:
https://koji.fedoraproject.org/koji/buildinfo?buildID=971248

Comment 21 Bob Relyea 2017-09-15 16:54:58 UTC
Daiki, The "c" compiled versions of AES-GCM shouldn't automatically use SSE2. There are assembler files that use SSE2 instructions if the processor and OS support it (detected at runtime). 

Upstream may have some issues when running Firefox under certain VM's with the unconditional flag.

bob

Comment 22 Daiki Ueno 2017-09-15 18:49:39 UTC
(In reply to Bob Relyea from comment #21)
> Daiki, The "c" compiled versions of AES-GCM shouldn't automatically use
> SSE2. There are assembler files that use SSE2 instructions if the processor
> and OS support it (detected at runtime). 

Well, it does.  See Eugine's backtrace in comment 17.  Since this upstream commit:
https://hg.mozilla.org/projects/nss/rev/cd068f7ce6ae11120f8e4427aa2e8ac35a69e764
all freebl source files are now compiled with "-mpclmul -maes" and that implies that GCC generates SSE2 instructions to optimize other portions of code.  I tried to disable it with -mno-sse2, but then I got compilation errors in gcm.c and rijndael.c.

Comment 23 Eugene Kanter 2017-09-16 03:46:41 UTC
I recomplied nss-softokn-3.32.0-8 on F26 and dnf is now working again.

Comment 24 Jeff Backus 2017-09-17 15:35:57 UTC
Hi all, thanks for continuing to try to resolve this.

I apologize for my ignorance, but has Daiki's patch resolved this? Are we waiting on a fix for freebl? Are we looking for testers? Thanks for your patience!

Comment 25 Daiki Ueno 2017-09-22 10:38:05 UTC
(In reply to Jeff Backus from comment #24)
> Hi all, thanks for continuing to try to resolve this.
> 
> I apologize for my ignorance, but has Daiki's patch resolved this? Are we
> waiting on a fix for freebl? Are we looking for testers? Thanks for your
> patience!

Although the fix has been merged in upstream, the final version of the patch touches the C code quite a bit.  So I would like to postpone this to the next rebase of the NSS packages, rather than cherry-picking the patch.

For those who are willing to test, I prepared scratch builds for F27 and F26:
https://koji.fedoraproject.org/koji/taskinfo?taskID=22019235
https://koji.fedoraproject.org/koji/taskinfo?taskID=22019362

Any feedback would be appreciated.

Comment 26 Ralf Corsepius 2017-10-07 04:05:57 UTC
(In reply to Daiki Ueno from comment #25)

> For those who are willing to test, I prepared scratch builds for F27 and F26:
How to test this? Do you have a simple test case?

My real word case to expose the nss_softokn issues so far had been to launch thunderbird on a PIII, but this isn't actually "handy".


> https://koji.fedoraproject.org/koji/taskinfo?taskID=22019235
> https://koji.fedoraproject.org/koji/taskinfo?taskID=22019362
> 
> Any feedback would be appreciated.
I am observing SIGILLs, which I believe are related to nss-softokn with when launching thunderbird.

gdb coredump traceback from thunderbird-52.3.0-1.fc27.i386 w/ nss-softokn-3.33.0-1.0.fc27.i686:
...
#
Core was generated by `/usr/lib/thunderbird/thunderbird'.
Program terminated with signal SIGILL, Illegal instruction.
...
#0  0xb76fbcd9 in __kernel_vsyscall ()
#1  0xb76da7f2 in raise () from /lib/libpthread.so.0
#2  0xb3708488 in nsProfileLock::FatalSignalHandler (signo=4, info=0xbfcd544c, context=0xbfcd54cc)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/toolkit/profile/nsProfileLock.cpp:181
#3  <signal handler called>
#4  0xa6517b4a in SHA1_Update () from /lib/libfreeblpriv3.so
#5  0xa65e8399 in sftkdb_passwordToKey.isra.2 () from /lib/libsoftokn3.so
#6  0xa65e96bf in sftkdb_ChangePassword () from /lib/libsoftokn3.so
#7  0xa65cac7b in NSC_InitPIN () from /lib/libsoftokn3.so
#8  0xb024fc4e in PK11_InitPin () from /lib/libnss3.so
#9  0xb3547b0c in nsPK11Token::InitPassword (this=0x99e47be0, initialPassword=...)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/security/manager/ssl/nsPK11TokenDB.cpp:299
#10 0xb0b83fc4 in NS_InvokeByIndex () from /usr/lib/thunderbird/libxul.so
#11 0xb13d6bb4 in CallMethodHelper::Invoke (this=0xbfcd5d88)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:2058
#12 CallMethodHelper::Call (this=0xbfcd5d88)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1377
#13 XPCWrappedNative::CallMethod (ccx=..., mode=<optimized out>, mode@entry=XPCWrappedNative::CALL_METHOD)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1344
#14 0xb13dc24c in XPC_WN_CallMethod (cx=cx@entry=0xaf3ae000, argc=1, vp=0xa9012910)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1000
#15 0xb4177af9 in js::CallJSNative (args=..., native=<optimized out>, cx=0xaf3ae000)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/js/src/jscntxtinlines.h:239
#16 js::InternalCallOrConstruct (cx=0xaf3ae000, args=..., construct=construct@entry=js::NO_CONSTRUCT)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/js/src/vm/Interpreter.cpp:459
#17 0xb4177cf1 in InternalCall (cx=cx@entry=0xaf3ae000, args=...)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/js/src/vm/Interpreter.cpp:504
#18 0xb416ae16 in js::CallFromStack (args=..., cx=0xaf3ae000)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/js/src/vm/Interpreter.cpp:510
#19 Interpret (cx=cx@entry=0xaf3ae000, state=...)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/js/src/vm/Interpreter.cpp:2922
#20 0xb4177540 in js::RunScript (cx=cx@entry=0xaf3ae000, state=...)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/js/src/vm/Interpreter.cpp:405
#21 0xb4177a48 in js::InternalCallOrConstruct (cx=cx@entry=0xaf3ae000, args=..., construct=construct@entry=js::CONSTRUCT)
    at /usr/src/debug/thunderbird-52.3.0-1.fc27.i386/mozilla/js/src/vm/Interpreter.cpp:477
...


# cat /proc/cpuinfo 
...
model name	: Pentium III (Coppermine)
stepping	: 6
...
flags		: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pse36 mmx fxsr sse cpuid

Comment 27 Ralf Corsepius 2017-10-07 04:15:15 UTC
FWIW: chronyd doesn't seem to expose this issue for on the same HW:

# /usr/sbin/chronyd -d
2017-10-07T04:11:18Z chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND +ASYNCDNS +IPV6 +DEBUG)
2017-10-07T04:11:18Z Frequency 147.166 +/- 1.016 ppm read from /var/lib/chrony/drift
2017-10-07T04:11:18Z Using right/UTC timezone to obtain leap second data
2017-10-07T04:11:24Z Selected source 195.186.1.101
2017-10-07T04:11:24Z System clock TAI offset set to 37 seconds

chrony-3.2-1.fc27.i686
nss-softokn-freebl-3.33.0-1.0.fc27.i686
nss-softokn-3.33.0-1.0.fc27.i686

Comment 28 Daiki Ueno 2017-10-09 06:07:26 UTC
(In reply to Ralf Corsepius from comment #26)

> > https://koji.fedoraproject.org/koji/taskinfo?taskID=22019235
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=22019362
> > 
> > Any feedback would be appreciated.
> I am observing SIGILLs, which I believe are related to nss-softokn with when
> launching thunderbird.
> 
> gdb coredump traceback from thunderbird-52.3.0-1.fc27.i386 w/
> nss-softokn-3.33.0-1.0.fc27.i686:
> ...

While the suggested scratch builds are based on 3.32.1, you are testing 3.33.0, where we reverted the downstream patch to disable SSE2 (see comment 25 for the reason).

The fix is expected to land in Fedora with our rebase to NSS 3.34.

Comment 29 Ralf Corsepius 2017-10-10 06:02:56 UTC
(In reply to Daiki Ueno from comment #28)
> (In reply to Ralf Corsepius from comment #26)
> 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=22019235
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=22019362
> > > 
> > > Any feedback would be appreciated.
> > I am observing SIGILLs, which I believe are related to nss-softokn with when
> > launching thunderbird.
> > 
> > gdb coredump traceback from thunderbird-52.3.0-1.fc27.i386 w/
> > nss-softokn-3.33.0-1.0.fc27.i686:
> > ...
> 
> While the suggested scratch builds are based on 3.32.1, you are testing
> 3.33.0,
0.33.0 was pulled in by dnf. I had not expected you to revert your patches and had not checked details.

However, I happened to have local copies of the binaries from 
https://koji.fedoraproject.org/koji/taskinfo?taskID=22019235
around. 

Result: Unlike with 0.33.0, thunderbird doesn't crash on my PIII and appears to work.

> where we reverted the downstream patch to disable SSE2 (see comment
> 25 for the reason).
Sigh ... This is not helpful for me ;)

> The fix is expected to land in Fedora with our rebase to NSS 3.34.
Will this happen before f27 release?

Comment 30 Florian Weimer 2017-10-31 14:28:50 UTC

*** This bug has been marked as a duplicate of bug 1507938 ***

Comment 31 Florian Weimer 2017-10-31 14:29:44 UTC
Note that nss-softokn-3.33.0-1.1.fc26 is affected as well, so this bug impacts the Fedora 26 release, too.

Comment 32 Florian Weimer 2017-10-31 14:30:40 UTC
*** Bug 1507938 has been marked as a duplicate of this bug. ***

Comment 33 Fedora Update System 2017-11-15 14:58:13 UTC
nss-3.34.0-1.0.fc27 nss-softokn-3.34.0-1.0.fc27 nss-util-3.34.0-1.0.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-24169bbb2d

Comment 34 Fedora Update System 2017-11-15 14:58:37 UTC
nss-3.34.0-1.0.fc26 nss-softokn-3.34.0-1.0.fc26 nss-util-3.34.0-1.0.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-552febe596

Comment 35 Fedora Update System 2017-11-15 14:58:58 UTC
nss-3.34.0-1.0.fc25 nss-softokn-3.34.0-1.0.fc25 nss-util-3.34.0-1.0.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-15b7f781f0

Comment 36 Ralf Corsepius 2017-11-15 19:19:22 UTC
I gave the fc27 and fc26 versions of nss-*3.34.0-1.0 a try on my PIII and they did not trigger the SIGILLs I was facing with *-3.33*.

Comment 37 Fedora Update System 2017-11-15 22:43:36 UTC
nss-3.34.0-1.0.fc25, nss-softokn-3.34.0-1.0.fc25, nss-util-3.34.0-1.0.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-15b7f781f0

Comment 38 Fedora Update System 2017-11-15 23:53:50 UTC
nss-3.34.0-1.0.fc27, nss-softokn-3.34.0-1.0.fc27, nss-util-3.34.0-1.0.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-24169bbb2d

Comment 39 Fedora Update System 2017-11-16 14:17:20 UTC
nss-3.34.0-1.0.fc27 nss-pem-1.0.3-6.fc27 nss-softokn-3.34.0-1.0.fc27 nss-util-3.34.0-1.0.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-24169bbb2d

Comment 40 Fedora Update System 2017-11-16 17:20:09 UTC
nss-3.34.0-1.0.fc26, nss-softokn-3.34.0-1.0.fc26, nss-util-3.34.0-1.0.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-552febe596

Comment 41 Fedora Update System 2017-11-17 18:53:49 UTC
nss-3.34.0-1.0.fc27, nss-pem-1.0.3-6.fc27, nss-softokn-3.34.0-1.0.fc27, nss-util-3.34.0-1.0.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-24169bbb2d

Comment 42 Fedora Update System 2017-11-27 21:23:51 UTC
nss-3.34.0-1.0.fc27, nss-pem-1.0.3-6.fc27, nss-softokn-3.34.0-1.0.fc27, nss-util-3.34.0-1.0.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 43 Fedora Update System 2017-12-02 08:02:45 UTC
nss-3.34.0-1.0.fc25, nss-softokn-3.34.0-1.0.fc25, nss-util-3.34.0-1.0.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 44 Daiki Ueno 2017-12-02 10:10:31 UTC
*** Bug 1519148 has been marked as a duplicate of this bug. ***

Comment 45 Fedora Update System 2017-12-02 21:22:11 UTC
nss-3.34.0-1.0.fc26, nss-softokn-3.34.0-1.0.fc26, nss-util-3.34.0-1.0.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.