Closed Bug 474777 Opened 15 years ago Closed 15 years ago

Wrong deallocation when modifying CRL.

Categories

(NSS :: Tools, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
3.12.3

People

(Reporter: slavomir.katuscak+mozilla, Assigned: alvolkov.bgs)

Details

Attachments

(1 file)

chains.sh: Create CRL for CA1DB
crlutil -G -d CA1DB -n CA1 -f CA1DB/dbpasswd
=== Crlutil input data ===
update=20090122131753Z
===
CRL Info:
:
    Version: 2 (0x1)
    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
    Issuer: "CN=CA1 Intermediate,O=CA1,C=US"
    This Update: Thu Jan 22 13:17:53 2009
    CRL Extensions:
chains.sh: #20: Revocation: Create CRL for CA1DB  - PASSED
chains.sh: Revoking certificate with SN 14 issued by CA1
crlutil -M -d CA1DB -n CA1 -f CA1DB/dbpasswd
=== Crlutil input data ===
addcert 14 20090122131754Z
===
crlutil(19142) malloc: ***  Deallocation of a pointer not malloced: 0x732f7374; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
CRL Info:
:
    Version: 2 (0x1)
    Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
    Issuer: "CN=CA1 Intermediate,O=CA1,C=US"
    This Update: Thu Jan 22 13:17:54 2009
    Entry (1):
        Serial Number: 14 (0xe)
        Revocation Date: Thu Jan 22 13:17:54 2009
    CRL Extensions:
chains.sh: #21: Revocation: Revoking certificate with SN 14 issued by CA1  - PASSED
Was there a core file?  Can we get a stack trace?
No core file. Even if there was error message, it finished successfully.
After adding CRL tests to CVS Tinderboxes began to fail with core:

(dbx) where                                                                  
  [1] _malloc_unlocked(0x40, 0x1, 0x3c, 0xbfb45000, 0x80469c0, 0xbfaaf633), at 0xbfac0d04 
  [2] malloc(0x3c), at 0xbfac0c63 
  [3] calloc(0x1, 0x3c), at 0xbfaaf633 
=>[4] PR_Calloc(nelem = 1U, elsize = 60U), line 475 in "prmem.c"
  [5] nss_ZAlloc(arenaOpt = (nil), size = 52U), line 892 in "arena.c"
  [6] nssArena_Create(), line 412 in "arena.c"
  [7] nssList_Create(arenaOpt = (nil), threadSafe = 0), line 125 in "list.c"
  [8] nssTrustDomain_FindCertificatesBySubject(td = 0x80b4870, subject = 0x8046b28, rvOpt = (nil), maximumOpt = 0, arenaOpt = (nil)), line 620 in "trustdomain.c"
  [9] NSSTrustDomain_FindCertificatesBySubject(td = 0x80b4870, subject = 0x8046b28, rvOpt = (nil), maximumOpt = 0, arenaOpt = (nil)), line 706 in "trustdomain.c"
  [10] CERT_CreateSubjectCertList(certList = (nil), handle = 0x80b4870, name = 0x80c74d4, sorttime = 1233852339595613LL, validOnly = 1), line 695 in "stanpcertdb.c"
  [11] SECU_FindCrlIssuer(dbhandle = 0x80b4870, subject = 0x80c74d4, authorityKeyID = (nil), validTime = 1233852339595613LL), line 4004 in "secutil.c"
  [12] FindSigningCert(certHandle = 0x80b4870, signCrl = 0x80c74a8, certNickName = 0x808b9e8 "CA0"), line 340 in "crlutil.c"
  [13] GenerateCRL(certHandle = 0x80b4870, certNickName = 0x808b9e8 "CA0", inCrlInitFile = 0x808c1e8, inFile = (nil), outFileName = 0x808b9f8 "CA0.crl", ascii = 0, slotName = (nil), importOptions = 0, alg = (nil), quiet = 0, decodeOptions = 0, url = (nil), pwdata = 0x8046c70, modifyFlag = 1), line 698 in "crlutil.c"
  [14] main(argc = 10, argv = 0x8046d28), line 1060 in "crlutil.c"

You can find core file on machine dositups in:
/export/tinderlight/data/dositups_32_DBG.474777/mozilla/tests_results/security/dositups.1/chains/Revocation
Old code was trying to de-allocate memory of the crlDER.data even if it was not allocated in the first place. This would be the case, when reading of the crl was done directly from cert/crl db.
Attachment #360781 - Flags: review?(nelson)
Comment on attachment 360781 [details] [diff] [review]
crlutil.c patch v1 - fix an attempt to deallocate unallocated data.  

r=nelson
Attachment #360781 - Flags: review?(nelson) → review+
committed.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.