View Issue Details

IDProjectCategoryView StatusLast Update
0006694JEDI VCL00 JVCL Componentspublic2020-05-29 21:55
ReporterwpostmaAssigned To 
PriorityhighSeveritymajorReproducibilityrandom
Status newResolutionopen 
Product VersionDaily / GIT 
Target VersionFixed in Version 
Summary0006694: Jedi JVCL JvCsvDataSet Out of bounds memory access on Delphi 10.0, 10.1, 10.2, 10.3
DescriptionThere are deep seated design problems in this component that I wrote back in about 1998-2001.

First TJvcsvdataset.TextBufferSize must be manually managed.

Secondly, even if the correct buffer sizes are set, you could define fields that would consume more memory than the text buffer.

IN many cases, the heap overwrites will be caught by the "magic" number (boy what a hack that was that I put that in there) getting overwritten.

In other cases it is not caught by that. We have seen production applications using this, trigger TPM errors in windows, hit malware and windows security check features, and other things.

Unfortunately I do not have time to find and fix all this so I would like to suggest that if someone can find and fix these, great, if not consider deprecating the component.

A better design to replace this component would:

1. use whatever dataset you want to be the in memory storage system.

2. use the csv parser from this current component only but not its dataset implementation.

3. Make the importer/exporter work only on other datasets, or in memory datasets.

4. Perhaps have a special adaptor to work with the FireDac Memory dataset which is rugged and will get updated/tested.

Other concerns I have are that there may be field types in Delphi's internal dataset model, or events that were never implemented for JvCsvDataSet. It needs a thorough audit before anyone should use it in production in a serious app.
Steps To ReproduceToo complex to give simple steps. But set up a dataset with about 8K of possible memory usage, per row, and set TextBufferSize to 4096.

Even without overflowing the dataset, there are some cases that rarely occur that are causing the heap to be corrupt, so I suspect that overflowing the text buffer is NOT THE ONLY bug to try to reproduce here.

Perhaps a more practical way to reproduce would be to make a demo app with SafeMM or something and test the heap integrity of this component. I do not have time to do this right now.
TagsNo tags attached.

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2020-05-29 21:55 wpostma New Issue