View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002996||Ham Radio Deluxe||Bug||public||2018-12-14 12:34||2019-11-07 05:46|
|Priority||normal||Severity||crash||Reproducibility||have not tried|
|Target Version||Fixed in Version||188.8.131.52|
|Summary||0002996: Rig Control: buffer overrun crashes reported in port enumeration during Connect dialog|
|Description||The 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 Reproduce||No repro steps, since this comes from the Microsoft Developer Dashboard.|
|Tags||No tags attached.|
Mantis2996Stack.xlsx (14,305 bytes)
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:
||Taking the developer's opinion on this.|
|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||=> 184.108.40.206|
|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||220.127.116.11 => 18.104.22.168|
|2019-01-16 22:04||WA9PIE||Project||3 - Current Dev List => Ham Radio Deluxe|
|2019-11-07 05:46||WA9PIE||Fixed in Version||22.214.171.124 => 126.96.36.199|