View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006694 | JEDI VCL | 00 JVCL Components | public | 2020-05-29 21:55 | 2021-09-04 14:24 |
| Reporter | wpostma | Assigned To | |||
| Priority | high | Severity | major | Reproducibility | random |
| Status | feedback | Resolution | open | ||
| Product Version | Daily / GIT | ||||
| Target Version | Fixed in Version | ||||
| Summary | 0006694: Jedi JVCL JvCsvDataSet Out of bounds memory access on Delphi 10.0, 10.1, 10.2, 10.3 | ||||
| Description | There 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 Reproduce | Too 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. | ||||
| Tags | No tags attached. | ||||
