System.OutOfMemoryException when reading corrupt Word document

[Numpsy]

Related to #30, but blowing up in a different location:

if you try to open the file out_of_memory_2.zip (generated by SharpFuzz) with the current OpenMcdf, you get a System.OutOfMemoryException with the call stack:

at System.Collections.Generic.List`1.set_Capacity(Int32 value)
   at System.Collections.Generic.List`1.EnsureCapacity(Int32 min)
   at System.Collections.Generic.List`1.Add(T item)
   at OpenMcdf.CompoundFile.GetDifatSectorChain()
   at OpenMcdf.CompoundFile.GetFatSectorChain()
   at OpenMcdf.CompoundFile.GetNormalSectorChain(Int32 secID)
   at OpenMcdf.CompoundFile.LoadDirectories()
   at OpenMcdf.CompoundFile.Load(Stream stream)
   at OpenMcdf.CompoundFile..ctor(Stream stream)
   
Result Message:	System.OutOfMemoryException : Array dimensions exceeded supported range.

[jeremy-visionaid]

@Numpsy I haven't tried fuzzing v3 yet (#194), but if you want to test that file out there, that would be great!

[Numpsy]

I'll try to find some time to remember how SharpFuzz worked (last time I tried I had to run it on Ubuntu as it didn't work on Windows. That was quite a while ago though)

[jeremy-visionaid]

@Numpsy Looks like this works OK in 3.0, but 3.0 won't even allow getting as far as what causes the problem for 2.4 anyway. Essentially the header is corrupt (it states there are more difat sectors than what there actually are) but the approach to validating the file in 2.4 assumes the header is valid, or otherwise throws an OOM exception. I'm tempted to close this as it's already fixed in 3.0 and realistically unfixable for 2.4 (since fixing it would essentially entail a rewrite, and that's what 3.0 is). I could perhaps expose some mechanisms to corrupt the CFB data in various ways, but I'd rather do that as a wider task of coverage and fuzzing than worry about this specific case/file. WDYT?

[jeremy-visionaid]

Considering this one some more. By inspection for 3.0:

• If the stated difat chain length is too short in the header, then you will get an InvalidOperationException. I think I should just change this to a FormatException or similar which is more representative of the actual problem.
• If the stated difat chain length is too long, then the enumeration simply terminate earlier than expected, and the FAT chain will fail to move to required index for the position within a stream, and a FormatException will be thrown.
• If the difat chain points to somewhere beyond the length of the stream then an EndOfStreamException will be thrown.

So, I think 3.0 is fine on this front despite the file here not being able to excercise any of those conditions, but I will review to replace the invalid operation exception with something more appropriate.