Potential double-free vulnerability in j2k.c

[20urc3]

Hi, If I'm not wrong there might be a potential double-free vulnerability in openjpeg/src/lib/openjp2/j2k.c

OPJ_BYTE *new_header_tile_data = (OPJ_BYTE *) opj_realloc(p_j2k->m_specific_param.m_encoder.m_header_tile_data, l_mco_size);

if (! new_header_tile_data) {
    opj_free(p_j2k->m_specific_param.m_encoder.m_header_tile_data);
    p_j2k->m_specific_param.m_encoder.m_header_tile_data = NULL;
    p_j2k->m_specific_param.m_encoder.m_header_tile_data_size = 0;
    opj_event_msg(p_manager, EVT_ERROR, "Not enough memory to write MCO marker\n");
    return OPJ_FALSE;
}

The code is attempting to reallocate memory for the p_j2k pointer using the opj_realloc function. If the allocation is successful, then the opj_realloc call will free the old memory pointed to by p_j2k. However, the subsequent opj_free call will attempt to free the same memory that was just freed by opj_realloc. This will result in a double free vulnerability, as the memory will be freed twice and will no longer be accessible.

To fix this bug, the opj_free call should verify that p_j2k isn't null before freeing it again.

[rouault]

If the allocation is successful, then the opj_realloc call will free the old memory pointed to by p_j2k

yes

However, the subsequent opj_free call will attempt to free the same memory that was just freed by opj_realloc.

Wrong... The opj_free() is only called if new_header_tile_data == NULL, that is if the realloc failed

This will result in a double free vulnerability, as the memory will be freed twice and will no longer be accessible.

No

To fix this bug, the opj_free call should verify that p_j2k isn't null before freeing it again.

No again. p_j2k is already dereferenced before this piece of code, and has nothing to do with a potential double-free.

Please study C a bit more before creating false positive issues... Reports about vulnerabilities are more convincing when accompanied with a reproducer