buglwIP - A Lightweight TCP/IP stack - Bugs: bug #59468, null pointer dereference of lwip...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #59468: null pointer dereference of lwip function ip_reass_free_complete_datagram

Submitted by:  Wenqiang Li <silentdawn>
Submitted on:  Tue 17 Nov 2020 12:47:52 AM UTC  
Votes:  100  
 
Category:  Security-related Severity:  3 - Normal
Item Group:  Crash Error Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
lwIP version:  git head

Mon 27 Sep 2021 05:41:04 AM UTC, comment #2: 

I get a similar error on line 199 where p != NULL but p->payload = NULL. I can replicate this with a large ping: ping -s 5000 and then wait for the ip_reass_remove_oldest_datagram() to get called.

Doesn't look like ipr contains the full datagram either. In my case, this only happens for >3 fragments.

Prateek Tathicherla <ptath1>
Sat 03 Apr 2021 12:31:06 PM UTC, comment #1: 

The attached test file is just a bunch of raw Ethernet packets concatenated together (no pcap format). Can you upload a fixed version?

Erik Ekman <yarrick>
Project Member
Tue 17 Nov 2020 12:47:52 AM UTC, original submission:  

The lwip function ip_reass_free_complete_datagram() is used to free a datagram (struct ip_reassdata) and all its pbufs. It's called by the function ip_reass_tmr() timely or the function ip_reass_remove_oldest_datagram() to clear oldest datagram.

When trying to build struct ip_reass_helper *iprh, then function ip_reass_free_complete_datagram() dereference the pointer ipr->p->payload as below.
https://github.com/STMicroelectronics/STM32CubeH7/blob/beced99ac090fece04d1e0eb6648b8075e156c6c/Middlewares/Third_Party/LwIP/src/core/ipv4/ip4_frag.c#L178.
However, it doesn't check if ipr->p is a null pointer and there is a chance it could be. This will lead to a null pointer dereference bug.

It could be reproduced by the attached file as a pcap package.

To patch it, the function ip_reass_free_complete_datagram should check if ipr->p is null firstly.

Wenqiang Li <silentdawn>

 

Attached Files
file #51976:  test_ping.pcap added by ptath1 (16KiB - application/octet-stream - I get a similar error on line 199 where p != NULL but p->payload = NULL. I can replicate this with a large ping: ping -s 5000. Doesn't look like ipr contains the full datagram either. In my case, this only happens for >3 fragments.)
file #50288:  testcase0.txt added by silentdawn (4KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ptath1 (Updated the item)
  • -email is unavailable- added by ptath1 (Voted in favor of this item)
  • -email is unavailable- added by yarrick (Posted a comment)
  • -email is unavailable- added by silentdawn (Submitted the item)
  • -email is unavailable- added by silentdawn
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 100 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-09-27 ptath1 Attached File- => Added test_ping.pcap, #51976
    2021-09-27 ptath1 Carbon-Copy- => Added ptath1
    2020-11-17 silentdawn Attached File- => Added testcase0.txt, #50288
        Carbon-Copy- => Added -email is unavailable-

    Back to the top


    Powered by Savane 3.7