[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: Tue, 30 Jun 2020 14:33:14 -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 #6, bug #57374 (project lwip):

[comment #5 comment #5:]
> comment #3:
> >
> > According to the documentation, all outgoing packets are supposed to use
PBUF_RAM and the correct level (PBUF_TRANSPORT in this case).
> >
> Which allocation are you talking about here? I thought it would be correct
as it is?

This is about the allocation when sending UDP in the fuzzing code
(udp_app_fuzz_input() in triple_driver.c, merged into fuzz_common.c).

Changing it from PBUF_RAW there to PBUF_TRANSPORT stops it from crashing. But
it is probably just due to that the limits of different pbuf lengths move
around so that any pbuf being fragmented isn't too short.

Changing from PBUF_POOL to PBUF_RAM while keeping PBUF_RAW level also works,
since then it has a longer pbuf that the fragmentation code itself keeps track
of how much it has used (in the 'poff' variable) and p->len still is longer.

There is no problem with the allocation of rambuf in ip6_frag.c
it was just the check afterwards that checked the wrong pbuf.

This part is still a bit strange to me:
It seems that should be adjusting the rambuf instead of p as well.
Lots of packets are created, but it seems only one is sent. I am not that sure
this code actually works (I guess it would only happen for large UDPv6
packets), but it should not crash because of pbuf lengths anymore.


Reply to this item at:


  Message sent via Savannah

reply via email to

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