Asan container overflow when reading configuration file

[jkosberg]

I'm using the source for v2.4.0 and I'm seeing a container overflow when building with address sanitizer enabled:

#0	0x0000000311ca31a8 in __asan::AsanDie ()
#1	0x0000000311cbe7a0 in __sanitizer::Die ()
#2	0x0000000311ca109c in __asan::ScopedInErrorReport::~ScopedInErrorReport ()
#3	0x0000000311ca03d8 in __asan::ReportGenericError ()
#4	0x0000000311c95d10 in __asan_memcpy ()
#5	0x000000010cb6b4b0 in OpenColorIO_v2_4::ColorSpace::getAllocationVars at /build/mb/git/adobe/thirdparty/OpenColorIO/src/OpenColorIO/ColorSpace.cpp:305
#6	0x000000010ccb5f8c in OpenColorIO_v2_4::(anonymous namespace)::save at build/mb/git/adobe/thirdparty/OpenColorIO/src/OpenColorIO/OCIOYaml.cpp:3356
#7	0x000000010cc5826c in OpenColorIO_v2_4::(anonymous namespace)::save at build/mb/git/adobe/thirdparty/OpenColorIO/src/OpenColorIO/OCIOYaml.cpp:5097
#8	0x000000010cc5367c in OpenColorIO_v2_4::OCIOYaml::Write at build/mb/git/adobe/thirdparty/OpenColorIO/src/OpenColorIO/OCIOYaml.cpp:5151
#9	0x000000010cbb81d0 in OpenColorIO_v2_4::Config::serialize at build/mb/git/adobe/thirdparty/OpenColorIO/src/OpenColorIO/Config.cpp:4937
#10	0x000000010cbb8a84 in OpenColorIO_v2_4::Config::getCacheID at build/mb/git/adobe/thirdparty/OpenColorIO/src/OpenColorIO/Config.cpp:4882
#11	0x000000010cbb8564 in OpenColorIO_v2_4::Config::getCacheID at build/mb/git/adobe/thirdparty/OpenColorIO/src/OpenColorIO/Config.cpp:4861
#12	0x000000010cb43100 in OCIOW::OCIOConfiguration::OCIOConfiguration at MediaCore/OCIOModules/OCIOWrapper/Src/OCIOConfigurationFileManager.cpp:238
#13	0x000000010cb47a18 in OCIOW::OCIOConfiguration::ValidateOCIOConfigurationFile [inlined] at MediaCore/OCIOModules/OCIOWrapper/Src/OCIOConfigurationFileManager.cpp:220
...
<more stack here redacted because has our internal company calls, but can share more if needed>

This is reported as a container overflow issue here

With all the manual memory copying happening into that vector, I'm not surprised an overflow happens. Instead it should be:

        std::vector<float> allocationvars; 
        allocationvars.resize(cs->getAllocationNumVars());

It's important that the vector's capacity can handle the size of memory that's going to be copied into it by the manual memcpy. Otherwise this is always at risk of a container overflow if the vector's capacity is different than the size (which can happen if the vector starts as 0 elements and a memcpy tries to copy in 3, like what I encountered in my container overflow debug case locally.

It looks to me like there is a similar risk here as well.