[Top][All Lists]

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

[lwip-devel] [bug #57374] Assertion "this needs a pbuf in one piece!" fa

From: Erik Ekman
Subject: [lwip-devel] [bug #57374] Assertion "this needs a pbuf in one piece!" failed
Date: Mon, 29 Jun 2020 18:20:36 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

Follow-up Comment #2, bug #57374 (project lwip):

I managed to reproduce this by applying your patches to  lwIP ver2.1.0.RC1.

It is sending a big UDP packet (payload 15377 byte), and the outgoing pbuf is
defined at level PBUF_RAW in triple_driver.c.
No space for UDP and IP headers is reserved in front of the UDP data. UDP must
then allocate new pbuf to put in front.

ip6 frag must then split this one large pbuf into a queue of good size
packets. it allocates a new pbuf for link+ip6+frag header and chains a chunk
of data to each one.

the assert seems meant to check the newly allocated rambuf instead of p (which
is the fragmented payload) is long enough, as rambuf is used directly after as
an IPv6 header:

    rambuf = pbuf_alloc(PBUF_LINK, IP6_HLEN + IP6_FRAG_HLEN, PBUF_RAM);
    if (rambuf == NULL) {
      return ERR_MEM;
    LWIP_ASSERT("this needs a pbuf in one piece!",
                (p->len >= (IP6_HLEN)));
    SMEMCPY(rambuf->payload, original_ip6hdr, IP6_HLEN);
    ip6hdr = (struct ip6_hdr *)rambuf->payload;
    frag_hdr = (struct ip6_frag_hdr *)((u8_t*)rambuf->payload + IP6_HLEN);

When it crashes, the newly allocated rambuf has len 38, and the remaining user
data has len 37. (IP6_HLEN=40)


Reply to this item at:


  Message sent via Savannah

reply via email to

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