You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I expected to see you allocating a buffer for the Windows API to load the data into, as requested by the Microsoft docs:
The application that calls the GetAdaptersAddresses function must allocate the amount of memory needed to return the IP_ADAPTER_ADDRESSES structures pointed to by the AdapterAddresses parameter.
I haven't been able to prove memory corruption, but we aren't using this functionality in production, or outside of a basic test script.
If the Microsoft docs are to be believed, when calling the API using this function, it will write the data structures into the next 15000 bytes of application memory, starting at the pointer address denoting the start of our 1 byte buffer slice, which should (as far as I can tell), lead to silent memory corruption.
The text was updated successfully, but these errors were encountered:
iamacarpet
changed the title
net: adapterAddresses() on Windows
net: adapterAddresses() buffer overflow on Windows
Jun 15, 2022
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes, code is still in the master branch
What operating system and processor architecture are you using (
go env
)?What did you do?
I'm trying to implement a more native interface for GetAdaptersInfo and I'm using your call for GetAdaptersAddresses as a starting point.
What did you expect to see?
I expected to see you allocating a buffer for the Windows API to load the data into, as requested by the Microsoft docs:
https://docs.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getadaptersaddresses#remarks
What did you see instead?
You are allocating a 1 byte buffer, while telling the Windows API the buffer is 15000 bytes in size.
I haven't been able to prove memory corruption, but we aren't using this functionality in production, or outside of a basic test script.
If the Microsoft docs are to be believed, when calling the API using this function, it will write the data structures into the next 15000 bytes of application memory, starting at the pointer address denoting the start of our 1 byte buffer slice, which should (as far as I can tell), lead to silent memory corruption.
The text was updated successfully, but these errors were encountered: