lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #58817] SNTP - MEMP_SYS_TIMEOUT memory pool exhaustion


From: Jon Welch
Subject: [lwip-devel] [bug #58817] SNTP - MEMP_SYS_TIMEOUT memory pool exhaustion when receive KOD packet
Date: Fri, 24 Jul 2020 07:23:58 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36 Edg/84.0.522.40

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

                 Summary: SNTP - MEMP_SYS_TIMEOUT memory pool exhaustion when
receive KOD packet
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: g7jjf
            Submitted on: Fri 24 Jul 2020 11:23:56 AM UTC
                Category: apps
                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: git head

    _______________________________________________________

Details:

There appears to be an issue when receiving SNTP Kiss Of Death packets. After
receiving several KOD packets, I started to see 'sys_timeout: timeout != NULL,
pool MEMP_SYS_TIMEOUT is empty' assertions displayed. 

Looking at SNTP.C, around line 536, we have two sys_untimeout functions calls
to cancel active timeouts when receiving a good packet. However, there isn't a
corresponding sys_untimeout(sntp_request) just before the sntp_try_next_server
call around line 553 when receiving a KOD packet. Since the timeout isn't
cancelled, this appears to reduce the memory pool which eventually results in
the assertion displayed above. Changing the code to :

    if (sntp_opmode == SNTP_OPMODE_POLL) {
      /* Kiss-of-death packet. Use another server or increase UPDATE_DELAY.
*/
      sys_untimeout(sntp_request, NULL);

      sntp_try_next_server(NULL);
    }

appears to solve the problem.





    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]