[lwip-devel] [bug #64424] PKTINFO race condition - ipi_ifindex may not be initialized

[Christian Reese]

URL:
  <https://savannah.nongnu.org/bugs/?64424>

                 Summary: PKTINFO race condition - ipi_ifindex may not be
initialized
                   Group: lwIP - A Lightweight TCP/IP stack
               Submitter: chreese
               Submitted: Thu 13 Jul 2023 08:53:36 PM UTC
                Category: IPv4
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: 2.1.3


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Thu 13 Jul 2023 08:53:36 PM UTC By: Christian Reese <chreese>
If a UDP packet is received early enough (with recvmsg), you'll still
successfully get the PKTINFO from the cmsg ancillary data, but the ipi_ifindex
member of the in_pktinfo struct will be 0 (uninitialized) instead of the
correct interface ID. All other data, however, is initialized in this case -
everything besides ipi_ifindex. Eventually (usually by the following packet)
you'll get ancillary data that includes a valid ipi_ifindex - just not always
the first time. So it appears to be a race condition where lwIP is not always
immediately ready to provide the network interface ID the packet was received
on, and gives 0 instead.

The LWIP_NETBUF_RECVINFO option is enabled. A socket is created with the
IP_PKTINFO sockopt enabled and subscribed to a multicast address, at which
point it begins receiving UDP packets. Receive events are detected via
lwip_select - whenever they occur, lwip_recvmsg is used to receive the packets
- then the cmsg ancillary data is processed. If this all happens early enough
immediately after network initialization, the aforementioned defect occurs.

Codebase where the defect was initially seen, along with relevant locations:
https://github.com/ETCLabs/sACN/tree/v3.0.0.21
https://github.com/ETCLabs/sACN/blob/v3.0.0.21/src/sacn/sockets.c#L544
https://github.com/ETCLabs/sACN/blob/v3.0.0.21/src/sacn/sockets.c#L544
https://github.com/ETCLabs/sACN/blob/v3.0.0.21/src/sacn/sockets.c#L366

In the case of the above code, the defect results in the netint of the initial
packet being reported as netint 0, with all following packets reporting the
correct non-zero netint ID.







    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?64424>

_______________________________________________
Message sent via Savannah
https://savannah.nongnu.org/