Problem: hoedown's block_attr may outlive the buffers that it is computed from.
Consider the following test case:
- Some text{@list #foo}
- More text. This needs to be sufficiently long, so that the work buffer
storing the list items is re-allocated.
When parsing the list in parse_list, hoedown creates a new attr buffer to store the list's attributes. This buffer is a read-only view into the original src buffer.
List items are then parsed by parse_list_item. This function creates its own work buffer and copies the list items into that work buffer.
When parse_list_item parses block attributes, it makes the original attr buffer point at data in its work buffer.
Once the list items have been parsed, the work buffer is freed. Now, attr points at data that is no longer valid.
Problematic places are:
parse_list, where attr is created as a read-only buffer
parse_attributes, where block_attr->data is set to the data attr which is going to be free'd.
Problem: hoedown's
block_attrmay outlive the buffers that it is computed from.Consider the following test case:
When parsing the list in
parse_list, hoedown creates a newattrbuffer to store the list's attributes. This buffer is a read-only view into the originalsrcbuffer.List items are then parsed by
parse_list_item. This function creates its own work buffer and copies the list items into that work buffer.When
parse_list_itemparses block attributes, it makes the originalattrbuffer point at data in its work buffer.Once the list items have been parsed, the work buffer is freed. Now,
attrpoints at data that is no longer valid.Problematic places are:
parse_list, whereattris created as a read-only bufferparse_attributes, whereblock_attr->datais set to the data attr which is going to be free'd.