Simple fuzzing found an integer overflow in the dec2tnef library. This allocation from Attachment::setDataFromAttachment() doesn't verify that the attacker controlled value doesn't wrap: .text:000227B8 8D 42 01 lea eax, [edx+1] .text:000227BB 89 85 68 FF FF+ mov [ebp+var_98], eax .text:000227C1 8B 83 CC FF FF+ mov eax, ds:(_ZSt7nothrow_ptr - 42CFCh)[ebx] .text:000227C7 89 44 24 04 mov [esp+4], eax .text:000227CB 8B 85 68 FF FF+ mov eax, [ebp+var_98] .text:000227D1 C1 E0 02 shl eax, 2 .text:000227D4 89 04 24 mov [esp], eax .text:000227D7 89 95 5C FF FF+ mov [ebp+src], edx .text:000227DD 89 8D 58 FF FF+ mov [ebp+var_A8], ecx .text:000227E3 E8 54 22 FE FF call __ZnajRKSt9nothrow_t ; operator new[](uint,std::nothrow_t const&) That's (count + 1) * 4, without any checking that will succeed. The attached testcase reaches this code on Symantec Scan Engine, I'm not sure which other products use this code. (gdb) bt #1 0x07e88816 in Attachment::setDataFromAttachment(Item&) () from definitions/Decomposer/libdec2tnef.so #2 0x07e88abc in Attachment::setAttribute(Item&) () from definitions/Decomposer/libdec2tnef.so #3 0x07e8a1b4 in TNEFObject::getAttachments(_IO_FILE*, MList&) () from definitions/Decomposer/libdec2tnef.so #4 0x07e6c1d6 in CTNEFArchive::Open(char const*) () from definitions/Decomposer/libdec2tnef.so #5 0x07e6ae5f in CTNEFEngine::OpenArchive(CTNEFArchive*, bool*) () from definitions/Decomposer/libdec2tnef.so #6 0x07e6b8c0 in CTNEFEngine::Process(IDecomposerEx*, IDecContainerObjectEx*, IDecEventSink*, unsigned short*, char*, bool*, bool*) () from definitions/Decomposer/libdec2tnef.so #7 0x063d07b5 in CDecomposer::DecProcess(IDecObject*, IDecEventSink*, IDecIOCB*, unsigned short*, char*) () #8 0x063d13cb in CDecomposer::Process(IDecObject*, IDecEventSink*, IDecIOCB*, unsigned short*, char*) () More: https://bugs.chromium.org/p/project-zero/issues/detail?id=819