lwIP - A Lightweight TCP/IP stack - Bugs: bug #57790, Fragmented UDP packets leads to...
You are not allowed to post comments on this tracker with your current authentication level.
bug #57790: Fragmented UDP packets leads to crash on reassembly
Submitter: | Jarno Malmari <jmalmari> | ||
Submitted: | Tue 11 Feb 2020 04:05:23 PM UTC | ||
Category: | IPv4 | Severity: | 3 - Normal |
Item Group: | Crash Error | Status: | Invalid |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | git head |
Jump to the original submission
Thu 24 Sep 2020 09:50:18 AM UTC, comment #13: |
Benjamin K <bkausbk> |
Thu 24 Sep 2020 06:49:31 AM UTC, comment #12: Maybe the time is better invested debugging the error you have instead of going to git head.
|
Simon Goldschmidt <goldsimon> |
Thu 24 Sep 2020 06:26:42 AM UTC, comment #11: I compared ip4_frag.c version 2.1.2 with git head and there were no relevant changes made. I ommited to further test that version since I already burned a full week in realizing that the bug was not in our product. I will put that on my todo list and if I get some time I will test it again.
|
Benjamin K <bkausbk> |
Wed 23 Sep 2020 08:27:55 AM UTC, comment #10: Re comment #9:
|
Simon Goldschmidt <goldsimon> |
Wed 23 Sep 2020 08:25:09 AM UTC, comment #9: I can confirm that bug. I'm using STM32F767II MCU with FreeRtos and LwIP 2.1.2. I'm not working with real hardware network interface but I've implemented a virtual network interface without any DMA access etc.
|
Benjamin K <bkausbk> |
Sun 16 Feb 2020 07:44:35 PM UTC, comment #8: Changed the summary of task #14807 to include IPv4 reassemly, so this can be closed.
|
Simon Goldschmidt <goldsimon> |
Thu 13 Feb 2020 07:55:24 PM UTC, comment #7: Yes, that's task #14807 (not a bug).
|
Simon Goldschmidt <goldsimon> |
Thu 13 Feb 2020 07:48:17 PM UTC, comment #6:
This is good to know. I assumed otherwise, so this is something I need to get back to. I won't be able to check it right away so feel free to close this for now.
|
Jarno Malmari <jmalmari> |
Wed 12 Feb 2020 09:25:36 AM UTC, comment #5:
|
Simon Goldschmidt <goldsimon> |
Wed 12 Feb 2020 08:55:34 AM UTC, comment #4:
Yes. My app is single threaded. The public example happened to be multi.
No udp api code is even needed. Simple loop running just the lwip stack is enough.
Sorry, I wasn't clear. I mean the lwip is given a pool that may be write only (that eth dma will read). For lwip input, a custom pbuf is allocated from external pool that may be read only (that eth dma wrote). I just wonder whether it's safe to assume lwip doesn't use pbuf payloads in a conflicting way under the hood.
|
Jarno Malmari <jmalmari> |
Tue 11 Feb 2020 07:40:59 PM UTC, comment #3: Are you at least sure it's not a threading issue?
|
Simon Goldschmidt <goldsimon> |
Tue 11 Feb 2020 07:22:46 PM UTC, comment #2:
|
Jarno Malmari <jmalmari> |
Tue 11 Feb 2020 06:28:41 PM UTC, comment #1: You won't get me to reproduce this with an H7 board, sorry.
|
Simon Goldschmidt <goldsimon> |
Tue 11 Feb 2020 04:05:23 PM UTC, original submission:
Test setup
Device under testRan into crash with custom ST H7 board. Reproducible with NUCLEO-H743ZI2.
Software
LwIP
Test run
DebugSource of hardfault is function ip_reass_free_complete_datagram, dereferencing invalid pointer p (p->payload).
Workaround
|
Jarno Malmari <jmalmari> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-02-16 | goldsimon | Status | None | Invalid | |
Assigned to | None | goldsimon | |||
Open/Closed | Open | Closed | |||
2020-02-11 | jmalmari | Attached File | - | Added lwipopts.h, #48393 |
Powered by Savane 3.13-758e.
Corresponding source code
Mentioning threading requirement is a good point, I will check that in detail. But I think I found at least one issue in my source:
In my interface low level input method:
struct pbuf* p = pbuf_alloc(PBUF_RAW, Msg->Size, PBUF_REF);
if (p != NULL) {
p->payload = GetPayloadBuffer(Msg);
p->len = Msg->Size;
if (Interface->input(p, Interface) != ERR_OK ) {
pbuf_free(p); // On fail, we have to free the buffer
} else {
CallbackResult = 1;
// buffer is already freed internally
}
}
My Msg was actually a stack variable, I was assuming that Interface->input() was blocking and that after that call the content of that stack variable gets cloned. However this isn't the case especially with PBUF_REF set.