helpGnuTLS - Support: sr #108321, crq_apis coredump on 32-bit build...


sr #108321: crq_apis coredump on 32-bit build due to _gnutls_strdatum_to_buf NULL buf handling

Submitted by:  None
Submitted on:  Mon 10 Jun 2013 12:47:15 PM UTC  
Category: Core libraryPriority: 5 - Normal
Severity: 4 - ImportantStatus: Done
Privacy: PublicAssigned to: Nikos Mavrogiannopoulos <nmav>
Originator Email: -unavailable-Open/Closed: Closed
Operating System: GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Mon 10 Jun 2013 01:01:52 PM UTC, comment #1:

Correction: it is obvious why it doesn't crash on x86-64: on that platform, it so happens that the stack frame is deep enough in the call within crq_apis that the size passed in is zero. This is obviously not something we can ever rely on! :)

(Sorry I can't log in: my username and password are stored encrypted and only my Emacs knows how to decrypt them. My Emacs won't start due to a lack of GnuTLS! though I have a build underway to fix that...)

Mon 10 Jun 2013 12:47:15 PM UTC, original submission:

[Set to important on the grounds that writing to null pointers in security-sensitive code is a bad thing. Feel free to change it back if I guessed wrong!]

This is a 32-bit build on a 64-bit SSSE3-capable host. We see:

Core was generated by `./crq_apis'.
Program terminated with signal 11, Segmentation fault.
#0 0xf75f697a in __memcpy_ssse3_rep () from /lib32/
(gdb) bt
#0 0xf75f697a in __memcpy_ssse3_rep () from /lib32/
#1 0xf76fedf6 in _gnutls_strdatum_to_buf (d=d@entry=0xffd0d7c8, buf=buf@entry=0x0, sizeof_buf=sizeof_buf@entry=0xffd0d81c) at common.c:1774
#2 0xf7705152 in gnutls_x509_crq_get_challenge_password (crq=crq@entry=0x9aa99c0, buf=buf@entry=0x0, sizeof_buf=sizeof_buf@entry=0xffd0d81c) at crq.c:490
#3 0xf7713e0f in print_crq (format=GNUTLS_CRT_PRINT_FULL, cert=0x9aa99c0, str=0xffd0d820) at output.c:2344
#4 gnutls_x509_crq_print (crq=0x9aa99c0, format=format@entry=GNUTLS_CRT_PRINT_FULL, out=out@entry=0xffd0d91c) at output.c:2486
#5 0x080495b8 in doit () at crq_apis.c:190
#6 0x08048f84 in main (argc=<optimized out>, argv=0xffd0da34) at utils.c:155

The immediate cause, obviously, is that 'buf' is NULL. The ultimate cause is also obvious: print_crq() calls gnutls_x509_crq_get_challenge_password() with a NULL buf argument and an uninitialized size. How this works at all, ever, even on 64-bit platforms, is a mystery to me. A NULL buf is not documented as working, but since it is passed in by the API testsuite as well as by print_crq() it is clear that it's meant to work.

The obvious fix is to test buf for nullity in _gnutls_strdatum_to_buf(), as well as checking the size for validity, and return GNUTLS_E_SHORT_MEMORY_BUFFER and update the sizeof_buf if it's NULL as well as if it's short. This means you can set the size by passing in any size at all and a NULL buf, rather than requiring a zero size.

Fix attached.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by nmav (Updated the item)
  • -unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 23 Jul 2013 08:23:55 PM UTCnmavStatusNone=>Done
      Assigned toNone=>nmav
    Mon 10 Jun 2013 12:47:16 PM UTCNoneAttached File-=>Added 0001-A-NULL-buf-argument-to-_gnutls_strdatum_to_buf-shoul.patch, #28286

    Back to the top

    Powered by Savane 3.1-cleanup1