Problem: When running AddressSanitizer on a software project that

AddressSanitizer SEGV when x509_name_ex_d2i() calls sk_STACK_OF_X509_NAME_ENTRY_pop_free() about aws-lc HOT 3 CLOSED

hunjmes commented on July 17, 2024

AddressSanitizer SEGV when x509_name_ex_d2i() calls sk_STACK_OF_X509_NAME_ENTRY_pop_free()

from aws-lc.

Comments (3)

hunjmes commented on July 17, 2024

Looks like a struct definition mismatch, in my build:

#11 sk_pop_free_ex (sk=0x604000061b18, call_free_func=0x7efd0423de30 <sk_STACK_OF_X509_NAME_ENTRY_call_free_func>, free_func=0x7efd0423dd10 <local_sk_X509_NAME_ENTRY_free>)
    at .../src/crypto/stack/stack.c:136
#12 0x00007efd0423e6ab in sk_STACK_OF_X509_NAME_ENTRY_pop_free (free_func=0x7efd0423dd10 <local_sk_X509_NAME_ENTRY_free>, sk=0x604000061b18)
    at .../src/crypto/x509/x_name.c:75

In frame 12:

(gdb) ptype sk.stack
type = struct stack_st {
    int num;
    char **data;
    int sorted;
    int num_alloc;
    int (*comp)(const void *, const void *);
}

-- this is 32 bytes.

But, in frame 11:

(gdb) ptype *sk
type = struct stack_st {
    size_t num;
    void **data;
    int sorted;
    size_t num_alloc;
    OPENSSL_sk_cmp_func comp;
}

-- this is 40 bytes (because it has two size_t's, replaced in frame 12 by ints).

from aws-lc.

hunjmes commented on July 17, 2024

Above comment might be a red herring. Looks like the code in question uses struct stack_st throughout, rather than C++ stack_st. The objects look like valid struct stack_st objects. I don't know why we're getting the SEGV from ASan.

Not looking into this further, at this time.

from aws-lc.

hunjmes commented on July 17, 2024

Looks like mem.c and ASan don't get along, unless AWS-LC package is compiled with OPENSSL_ASAN defined, see https://github.com/aws/aws-lc/blob/main/crypto/mem.c#L248 . So this is a known issue with a work-around, and not a bug.

from aws-lc.

Recommend Projects