Closed Bug 303494 Opened 19 years ago Closed 19 years ago

SEC_LookupCrls(.., .., SEC_KRL_TYPE) returns CRLs, and SEC_LookupCrls(.., .., SEC_CRL_TYPE) returns nothing

Categories

(NSS :: Libraries, defect, P2)

3.10
x86
Windows 2000
defect

Tracking

(Not tracked)

RESOLVED FIXED
3.10.2

People

(Reporter: julien.pierre, Assigned: julien.pierre)

Details

Attachments

(1 file)

It's been reported to us that this API returns CRLs when a KRL was requested, and nothing when CRLs are requested . This happens only on Windows, when NSS is built with VC6 optimized . A debug build works fine . The problem is easily reproducible with crlutil -L -t 0 / crlutil -L -t 1 . SEC_LookupCrls does a token search, but I determined that softoken isn't at fault, because the bug still happens when I use a debug softokn3.dll with an optimized nss3.dll . Conversely, when I use a debug build, the bug happens once I replace nss3.dll with an optimized version . So, the bug is in the code from libnss . I have been looking for uninitialized variables all afternoon without success, using dbx on Solaris and purify on Windows . No luck. Building in the OPT.OBJD configuration also did not help . I managed to get symbols in my optimized build, but the resulting code is extremely hard to trace (the program counter jumps in non-linear order of source lines !). I changed the optimization level from -O2 to -O1 . At that point, SEC_LookupCrls started returned the CRL for *both* the SEC_CRL_TYPE and SEC_KRL_TYPE queries. I'm nearly convinced this is a code generation bug in VC6 . I'm using VC6 SP6 FWIW .
This is actually a bug in PK11_LookupCrls, but it is only triggered by the Microsoft VC6 optimizer . Here is the disassembly of the incriminating area. This is the output of the compiler with -O1, in the case where CRLs are always returned , regardless of the input argument : 249: /* 250: * Return a list of all the CRLs . 251: * CRLs are allocated in the list's arena. 252: */ 253: SECStatus 254: PK11_LookupCrls(CERTCrlHeadNode *nodes, int type, void *wincx) { 002421BD 55 push ebp 002421BE 8B EC mov ebp,esp 002421C0 83 EC 2C sub esp,2Ch 255: pk11TraverseSlot creater; 256: CK_ATTRIBUTE theTemplate[2]; 257: CK_ATTRIBUTE *attrs; 258: CK_OBJECT_CLASS certClass = CKO_NETSCAPE_CRL; 259: 260: attrs = theTemplate; 261: PK11_SETATTRS(attrs, CKA_CLASS, &certClass, sizeof(certClass)); attrs++; 002421C3 83 65 D4 00 and dword ptr [theTemplate],0 262: if (type != -1) { 002421C7 83 7D 0C FF cmp dword ptr [type],0FFFFFFFFh 002421CB 8D 45 FC lea eax,[certClass] 002421CE C7 45 FC 51 43 53 CE mov dword ptr [certClass],0CE534351h 002421D5 89 45 D8 mov dword ptr [ebp-28h],eax 002421D8 C7 45 DC 04 00 00 00 mov dword ptr [ebp-24h],4 002421DF 8D 45 E0 lea eax,[ebp-20h] 002421E2 74 17 je PK11_LookupCrls+3Eh (002421fb) 263: CK_BBOOL isKrl = (CK_BBOOL) (type == SEC_KRL_TYPE); 264: PK11_SETATTRS(attrs, CKA_NETSCAPE_KRL, &isKrl, sizeof(isKrl)); attrs++; 002421E4 8D 45 0F lea eax,[isKrl] 002421E7 C7 45 E0 58 43 53 CE mov dword ptr [ebp-20h],0CE534358h 002421EE 89 45 E4 mov dword ptr [ebp-1Ch],eax 002421F1 C7 45 E8 01 00 00 00 mov dword ptr [ebp-18h],1 002421F8 8D 45 EC lea eax,[creater] 265: } The problem is that isKrl is a temporary variable, declared within the if (type != -1) { } block . But we are taking its address and setting it in the template. Somehow, the optimizer decided not to initialize that variable which was dropping out of stack anyway ;) I guess in the -O2 case, the stack offset probably gets reused by some other variable later on. The fix is simply to declare isKrl at the top of the function .
Priority: -- → P2
Target Milestone: --- → 3.11
Attachment #191658 - Flags: review?(nelson)
Comment on attachment 191658 [details] [diff] [review] Move isKrl variable to function scope r=nelson.bolyard
Attachment #191658 - Flags: review?(nelson) → review+
Comment on attachment 191658 [details] [diff] [review] Move isKrl variable to function scope Good job. r=wtc.
Attachment #191658 - Flags: superreview+
I checked this in to the tip. Checking in pk11nobj.c; /cvsroot/mozilla/security/nss/lib/pk11wrap/pk11nobj.c,v <-- pk11nobj.c new revision: 1.6; previous revision: 1.5 done This bug has been around since 3.4 .
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
We had a customer request this for 3.10.2, so I checked this in to NSS_3_10_BRANCH . Changing target to 3.10.2 . Checking in pk11nobj.c; /cvsroot/mozilla/security/nss/lib/pk11wrap/pk11nobj.c,v <-- pk11nobj.c new revision: 1.4.8.1; previous revision: 1.4 done
Target Milestone: 3.11 → 3.10.2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: