93a034a7d7
Our CBB patterns do not make it safe to use a CBB after any operation failed. Suppose one does: int add_to_cbb(CBB *cbb) { CBB child; return CBB_add_u8(cbb, 1) && CBB_add_u8_length_prefixed(cbb, &child) && CBB_add_u8(&child, 2) && /* Flush |cbb| before |child| goes out of scoped. */ CBB_flush(cbb); } If one of the earlier operations fails, any attempt to use |cbb| (except CBB_cleanup) would hit a memory error. Doing this would be a bug anyway, since the CBB would be in an undefined state anyway (wrote only half my object), but the memory error is bad manners. Officially document that using a CBB after failure is illegal and, to avoid the memory error, set a poison bit on the cbb_buffer_st to prevent all future operations. In theory we could make failure + CBB_discard_child work, but this is not very useful and would require a more complex CBB pattern. Change-Id: I4303ee1c326785849ce12b5f7aa8bbde6b95d2ec Reviewed-on: https://boringssl-review.googlesource.com/8840 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> |
||
---|---|---|
.. | ||
asn1_compat.c | ||
ber.c | ||
bytestring_test.cc | ||
cbb.c | ||
cbs.c | ||
CMakeLists.txt | ||
internal.h |