lwIP - A Lightweight TCP/IP stack - Bugs: bug #59831, tcp_output : Null dereferencing
You are not allowed to post comments on this tracker with your current authentication level.
bug #59831: tcp_output : Null dereferencing
Submitter: | Jonathan D <jona> | ||
Submitted: | Wed 06 Jan 2021 10:22:43 AM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | Crash Error | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | Planned Release: | None |
lwIP version: | git head |
Jump to the original submission
Mon 18 Jan 2021 09:37:29 PM UTC, comment #7: |
Evan Lojewski <meklort> |
Mon 18 Jan 2021 09:09:25 PM UTC, comment #6: Yes, the problem is not that FreeRTOS does task switching, the problem is that other tasks access tcp internals.
|
Erik Ekman <yarrick> |
Mon 18 Jan 2021 08:51:00 PM UTC, comment #5: Re comment #3:
|
Simon Goldschmidt <goldsimon> |
Mon 18 Jan 2021 08:27:51 PM UTC, comment #4: By "Another tasks was executed between this line 1328 and line 1382", I mean that FreeRTOS can switch tasks when the time allowed for one tasks is elapsed : https://www.freertos.org/implementation/a00005.html
|
Jonathan D <jona> |
Mon 18 Jan 2021 08:00:49 PM UTC, comment #3: What do you mean that "Another tasks was executed between this line 1328 and line 1382" ?
|
Erik Ekman <yarrick> |
Mon 18 Jan 2021 05:25:23 AM UTC, comment #2: I've also run into this issue when attempting to integrate lwip into one of my projects.
|
Evan Lojewski <meklort> |
Wed 06 Jan 2021 10:24:53 AM UTC, comment #1: The crash looks also very similar to the one described there :
|
Jonathan D <jona> |
Wed 06 Jan 2021 10:22:43 AM UTC, original submission:
We are developing a device with LwIP and FreeRTOS.
|
Jonathan D <jona> |
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.
Follows 1 latest change.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2021-01-06 | jona | Attached File | - | Added LwIP_null_dereferencing_crash.diff, #50666 |
Powered by Savane 3.13-02a9.
Corresponding source code
comment #5:
It's possible that this is related, however what I'm seeing is also causing this issue here.
If you take a look at the tcp_out.c file:
https://git.savannah.nongnu.org/cgit/lwip.git/tree/src/core/tcp_out.c#n1328
useg = pcb->unacked;
if (useg != NULL) {
useg is beign set to pcb->unacked. Following this, there is a check for null, which implies that useg can be null.
On line 1382, we then check pcb->unacked for null, and not useg for null. These should be the same, so long as pcb was not modified by another thread.
https://git.savannah.nongnu.org/cgit/lwip.git/tree/src/core/tcp_out.c#n1390
So, the linters are only triggering this because two different variable names are being used and checked for null. I think if the following line checked useg instead, then the linter would be happy:
Note that this would also reduce the probability of the issue being triggered by the OP, but would not necessarily fix their issue.
After that analysis, I would agree that these are two seperate issues
1) the way the code is written is causing confusion to both pclint and clang-analyzer
2) The OP is running into an because multiple threads accessing tcp routines that modify internals (presumable).