Adding people who changed that test, though I know changes were long time ago.

Assigned to non-PST Chrome OS sheriff. I think this test might be caused by a Chrome OS CL...

Update suspicious point:

Refer to this unittest [1], in the beginning the vector<unit8_t>[1024] is allocated then resizing to 1023. In the end, it tries to access last byte of the allocated 1024 data. 

> If n is smaller than the current container size, the content is reduced to its first 
> n elements, removing those beyond (and destroying them).

Refer to reference of std:vector:resize above, the reduced 1 element (1024 -> 1023) would be destroyed. Thus the size of heap object would be from 1024 to 1023. Finally the access of index - 1023 exceeds the boundary of size (0 ~ 1022) and be caught by AddressSanitizer. 

Refer to original comment of unittest, it expected the heap object would be remained the same since resizing to smaller size. So index 1023 should be still accessible and wiped to 0 [2]. It seems this assumption is against the definition of std:vector:resize?

[1] https://chromium.googlesource.com/aosp/platform/external/libbrillo/+/master/brillo/secure_blob_unittest.cc#79
[2] https://chromium.googlesource.com/aosp/platform/external/libbrillo/+/master/brillo/secure_blob.cc#29

refer to "container-overflow" in the link [1], it shows the exact code snippet like this issue. But I don't know why it just appeared recently. Maybe the change of libc++ or any compiler.

[1] https://github.com/CppCon/CppCon2014/blob/master/Presentations/Sanitize%20your%20C%2B%2B%20code/Sanitize%20your%20C%2B%2B%20code%20-%20Kostya%20Serebryany%20-%20CppCon%202014.pdf

unassigned myself due to finish the sheriff this week.