Invalid Data From ReadFile Function

Question

I have come across some invalid data from the ReadFile method.

Background###

I am one of the maintainers of the following golang project:
https://github.com/prysmaticlabs/prysm

Recently one of our users running on windows 10 came across an interesting crash.

Initially we assumed that it might have been a bug in the application, however upon examining the code and the
accompanying stack trace that possibility seemed much less likely. The panic happened in a core library of the go language.
https://golang.google.cn/pkg/bufio/

This library is used for mostly i/o operations and at the time that the panic was hit, it was reading from a network socket. The panic appeared on this line:
https://golang.google.cn/src/bufio/bufio.go#L238

If you look at the code, given the underlying reader is providing accurate information the panic shouldn't be possible at all. The underlying reader being an active TCP connection would lead to here:
https://golang.org/src/internal/poll/fd_windows.go#L408
https://golang.org/src/syscall/syscall_windows.go#369
https://golang.org/src/syscall/zsyscall_windows.go#1001

Underlying Method: https://golang.org/src/syscall/zsyscall_windows.go#141
Actual call to kernel: https://golang.org/src/runtime/syscall_windows.go#336

Win32Api method:
https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile

Some more relevant data:

• User had a network outage at around the same time, which seems pretty relevant to the issue and might have triggered the issue. It
  appears that their router went offline for a while.
• The size of the buffer passed into ReadFile is 4096, however when the method returns lpNumberOfBytesRead is actually 4308 . nNumberOfBytesToRead is also set as 4096, so the fact that the number of bytes read is larger than the maximum possible value should be impossible.
• User has the following specifications below:
  
  
• This has only been observed once, so there is no easy way to reproduce the bug easily. It might be possible to mimic network outages
  and try to constantly read from an active tcp connection in order to reproduce the bug. Let me know if any other data would be helpful.