[riot-notifications] [RIOT-OS/RIOT] gnrc_sock_udp: Possible Race condition on copy in application buffer (#10389)
notifications at github.com
Wed Nov 14 13:25:17 CET 2018
If your issue is a usage question, please submit it to the user mailing-list
users at riot-os.org or to the developer mailing-list devel at riot-os.org.
If your issue is related to security, please submit it to the security
mailing-list security at riot-os.org.
When using gnrc_sock_udp in my application after a certain amount of hosts in the network (and thus a certain amount of packets/s on a single host), the buffer content returned by sock_udp_recv is filled with garbage. My message format is defined to be 4 bytes + 4 bytes + 4 bytes + 4 bytes (message type, app src id, app dst id, length of the remainder data).
As an example: A message of type 11 always sends a static sized buffer with size 32 and thus the message "header" would look like this: 0x0000000b 0x00000001 0x00000002 0x00000020. (Second and third 4 bytes can differ)
Sometimes if many hosts are joining the network it happens very seldom that a single host instead read something like: 0x0000000b 0xfe80aaf0 0x00000000 0x00afbb20
Two intresting observations here:
The first 4 bytes always are correct.
The second 4 bytes always contains fe80something (Maybe i am just paranoid but this looks like the beginning of a link local ipv6 address)
- A Wireshark trace for a "broken" message shows that the data is sended corretly.
- Printing the first 16 bytes of all messages which had the expected length in the netdev_tap device showed a correct header
- Printing the first 16 Bytes of all messages which had the expected length in the sock_udp_recv function shows correct content when check is in the beginning of the function.
- When moving the check right before the memcpy into the application buffer the error disappears
- The Problem happens very seldom sometimes it takes 1k-2k udp messages until a faulty message triggers my asserts
#### Steps to reproduce the issue
Reading content from a udp socket and sending a lots (TBD) of messages. Testing the read buffer for correctness. Sadly no better way yet than try and wait.
#### Expected results
Content of buffer is correct
#### Actual results
Buffer content is garbage
Operating System Environment
Operating System: "Arch Linux"
Kernel: Linux 4.18.16-arch1-1-ARCH x86_64 unknown
Installed compiler toolchains
native gcc: gcc (GCC) 8.2.1 20180831
arm-none-eabi-gcc: arm-none-eabi-gcc (Arch Repository) 8.2.0
avr-gcc: avr-gcc (GCC) 8.2.0
clang: clang version 7.0.0 (tags/RELEASE_700/final)
Installed compiler libs
avr-libc: "2.0.0" ("20150208")
Installed development tools
cmake: cmake version 3.12.4
git: git version 2.19.1
make: GNU Make 4.2.1
openocd: Open On-Chip Debugger 0.10.0
python: Python 3.7.1
python2: Python 2.7.15
python3: Python 3.7.1
<!-- Thanks for contributing! -->
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications