View Issue Details

IDProjectCategoryView StatusLast Update
0002996Ham Radio DeluxeBugpublic2019-11-07 05:46
ReporterK7ZCZAssigned ToK7ZCZ 
PrioritynormalSeveritycrashReproducibilityhave not tried
Status closedResolutionfixed 
Product Version6.4.0.902 
Target VersionFixed in Version6.5.0.196 
Summary0002996: Rig Control: buffer overrun crashes reported in port enumeration during Connect dialog
DescriptionThe Microsoft Dashboard has started logging crashes for a buffer overrun on the stack while enumerating COM port devices. There are four such reports at the moment. One report is from Build 902, the other three are from 907. The 907 reports look like they're from a single customer machine; the 902 report is from a different machine.

From the call stack attached, we can see that the user has started the app and is using the new connection dialog. The call to EnumCOMPorts() is used to populate the list of available COM ports in the UI.

In that enumeration, the GS cookie is corrupted and the program traps the problem. There are several stack-based buffers in this fuction, and we'll need to investigate which one is being overrun to cause the trap and work to defend the code. Odds are there's an incorrect length being sent to one of the APIs called to retrieve device names or registry entries.
Steps To ReproduceNo repro steps, since this comes from the Microsoft Developer Dashboard.
TagsNo tags attached.
ModuleRig Control
Sub-ModuleRig Control
Testing Not Tested



2018-12-14 12:35


Mantis2996Stack.xlsx (14,305 bytes)


2018-12-14 17:09

developer   ~0006652

The enumeration code calls RegEnumValue() in a loop. Each iteration brings a new key/value out of the registry. It's conceivable that any particular iteration fails, so there's code inside the loop to see if the call worked.

If the call did work, the data is processed; we get a couple values from the registry, format them, and add them to an array with device names.

If the call didn't work, an error message is traced and the loop continues. Thing is, the continue statement skips the re-initialization of the buffer length parameters passed to the RegEnumValue() API. If the buffer sizes are too small, this API is documented to fail with ERROR_MORE_DATA after poking the required sizes into the values for length. The loop doesn't clear them, then calls again -- and the API would splash data over the given buffer and trash the GS security cookie.

I've fixed the loop to correctly reset the buffer lengths in the error case.

I've looked around and other RegKeyEnum() loops in the aplpication don't have this problem, so nothing else to fix.

Here's the change list:


2018-12-20 22:49

administrator   ~0006753

Taking the developer's opinion on this.

Issue History

Date Modified Username Field Change
2018-12-14 12:34 K7ZCZ New Issue
2018-12-14 12:35 K7ZCZ File Added: Mantis2996Stack.xlsx
2018-12-14 17:09 K7ZCZ Assigned To => K7ZCZ
2018-12-14 17:09 K7ZCZ Status new => resolved
2018-12-14 17:09 K7ZCZ Resolution open => fixed
2018-12-14 17:09 K7ZCZ Note Added: 0006652
2018-12-14 17:20 K7ZCZ Fixed in Version =>
2018-12-14 17:20 K7ZCZ Steps to Reproduce Updated View Revisions
2018-12-20 22:49 WA9PIE Status resolved => closed
2018-12-20 22:49 WA9PIE Steps to Reproduce Updated View Revisions
2018-12-20 22:49 WA9PIE Testing Not Started => Not Tested
2018-12-20 22:49 WA9PIE Note Added: 0006753
2019-01-16 22:04 WA9PIE Fixed in Version =>
2019-01-16 22:04 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2019-11-07 05:46 WA9PIE Fixed in Version =>