buglwIP - A Lightweight TCP/IP stack - Bugs: bug #17645, pbuf_header() corrupts pbuf chain...

 
 

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

bug #17645: pbuf_header() corrupts pbuf chain if header_size_increment is out of payload range

Submitter:  None
Submitted:  Fri 08 Sep 2006 08:28:51 AM UTC
   
 
Category:  pbufs Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  kieranm
Open/Closed:  Closed Planned Release:  None
lwIP version:  None

Jump to the original submission

Wed 21 Mar 2007 12:55:55 PM UTC, comment #7: 

Checked in, closing.

Kieran Mansley <kieranm>
Group Member
Wed 21 Mar 2007 12:00:35 PM UTC, comment #6: 

But I now notice there are other cases doing the same thing.  I will update pbuf_header() to cope with ROM and REF types without asserting, and get all callers to check the return value.

Kieran Mansley <kieranm>
Group Member
Wed 21 Mar 2007 11:58:03 AM UTC, comment #5: 

I've fixed udp_send() to not call pbuf_header() for cases that will fail.

Kieran Mansley <kieranm>
Group Member
Mon 12 Mar 2007 10:32:42 AM UTC, comment #4: 

I forgot to say, the first part of the check is right (the check if increment_magnitude <= p->len) AND necessary, although it also should return 1 instead of asserting.

Simon Goldschmidt <goldsimon>
Group administrator
Mon 12 Mar 2007 10:29:50 AM UTC, comment #3: 

Kieran,

I've reopened this bug because the fix does not work.

e.g. udp_send() checks the return value of pbuf_header(). If it's != 0, it allocates a new pbuf and chains it in front of the old one. If you now udp_send() a PBUF_REF, your fix asserts, although the original behaviour is ok.

The right solution would be to check and return 1 if impossible. This implies that all functions calling pbuf_header() MUST check the return value!

Simon Goldschmidt <goldsimon>
Group administrator
Wed 28 Feb 2007 01:46:21 PM UTC, comment #2: 

Fix checked in, but not well tested.  Please review and report any problems.

Kieran Mansley <kieranm>
Group Member
Mon 26 Feb 2007 01:01:40 PM UTC, comment #1: 

I think adding an assertion to the effect that inc <= len would be a good idea.

Kieran Mansley <kieranm>
Group Member
Fri 08 Sep 2006 08:28:51 AM UTC, original submission:  

If you allocate a pbuf chain and you call pbuf_header(pbuf, inc) with 'inc' > than 'len' of the first pbuf, the first pbuf in the chain will get corrupted ('payload' points to a region after the original data which does not belong to the 'packet'); the second pbuf will remain untouched. Also, 'tot_len' will be OK while 'len' of the first pbuf will get negative (and since len is an u16_t, it will be around 65530...)

Possible solution: check the header_size_increment parameter against the len value of the given pbuf before doing anything!

Anonymous

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by kieranm (Posted a comment)
  •  

    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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-03-21 kieranm StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2007-03-12 goldsimon StatusFixed In Progress
        Open/ClosedClosed Open
    2007-02-28 kieranm StatusNone Fixed
        Open/ClosedOpen Closed
    2007-02-26 kieranm Assigned toNone kieranm

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code