This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: NULL pointer deref on error path in _ssl debughelpers.c
Type: Stage: resolved
Components: SSL Versions: Python 3.9
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: christian.heimes Nosy List: Alexander Riccio, christian.heimes
Priority: normal Keywords:

Created on 2020-03-26 21:56 by Alexander Riccio, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (2)
msg365114 - (view) Author: Alexander Riccio (Alexander Riccio) * Date: 2020-03-26 21:56
At line 138 in debughelpers.c, ssl_obj, which was set to NULL on line 122, is dereferenced. 

I think the original intent was to actually bubble the error up through the ssl object.

Full function:

static void
_PySSL_keylog_callback(const SSL *ssl, const char *line)
    PyGILState_STATE threadstate;
    PySSLSocket *ssl_obj = NULL;  /* ssl._SSLSocket, borrowed ref */
    int res, e;
    static PyThread_type_lock *lock = NULL;

    threadstate = PyGILState_Ensure();

    /* Allocate a static lock to synchronize writes to keylog file.
     * The lock is neither released on exit nor on fork(). The lock is
     * also shared between all SSLContexts although contexts may write to
     * their own files. IMHO that's good enough for a non-performance
     * critical debug helper.
    if (lock == NULL) {
        lock = PyThread_allocate_lock();
        if (lock == NULL) {
            PyErr_SetString(PyExc_MemoryError, "Unable to allocate lock");
            PyErr_Fetch(&ssl_obj->exc_type, &ssl_obj->exc_value,

    ssl_obj = (PySSLSocket *)SSL_get_app_data(ssl);
    if (ssl_obj->ctx->keylog_bio == NULL) {

    PyThread_acquire_lock(lock, 1);
    res = BIO_printf(ssl_obj->ctx->keylog_bio, "%s\n", line);
    e = errno;

    if (res == -1) {
        errno = e;
        PyErr_Fetch(&ssl_obj->exc_type, &ssl_obj->exc_value, &ssl_obj->exc_tb);
msg391310 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2021-04-17 19:40
The issue has been fixed by fbf94af2af3c09493481b8559b84f6e9f0628c37 in on 2020-Jun-21.
Date User Action Args
2022-04-11 14:59:28adminsetgithub: 84260
2021-04-17 19:40:27christian.heimessetstatus: open -> closed
resolution: fixed
messages: + msg391310

stage: resolved
2020-03-26 21:56:53Alexander Ricciocreate