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
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

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
  •  

    There are 100 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.

    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.9