[riot-notifications] [RIOT-OS/RIOT] gnrc_sock_udp: Possible Race condition on copy in application buffer (#10389)

crest42 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.

#### Description
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)

Further debugging:
- 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

#### Versions
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
       mips-mti-elf-gcc: missing
             msp430-gcc: missing
   riscv-none-embed-gcc: missing
                  clang: clang version 7.0.0 (tags/RELEASE_700/final)

Installed compiler libs
   arm-none-eabi-newlib: "3.0.0"
    mips-mti-elf-newlib: missing
riscv-none-embed-newlib: missing
               avr-libc: "2.0.0" ("20150208")

Installed development tools
                  cmake: cmake version 3.12.4
               cppcheck: missing
                doxygen: 1.8.14
                 flake8: missing
                    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
             coccinelle: missing

<!-- 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...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20181114/97e01c3c/attachment.html>

More information about the notifications mailing list