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

Submitted by:  None
Submitted on:  Fri 08 Sep 2006 08:28:51 AM UTC  
 
Category: pbufsSeverity: 3 - Normal
Item Group: Faulty BehaviourStatus: Fixed
Privacy: PublicAssigned to: Kieran Mansley <kieranm>
Open/Closed: ClosedPlanned Release: None
lwIP version: None

(Jump to the original submission Jump to the original submission)

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

Checked in, closing.

Kieran Mansley <kieranm>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 21 Mar 2007 12:55:55 PM UTCkieranmStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Mon 12 Mar 2007 10:29:50 AM UTCgoldsimonStatusFixed=>In Progress
      Open/ClosedClosed=>Open
    Wed 28 Feb 2007 01:46:21 PM UTCkieranmStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Mon 26 Feb 2007 01:01:40 PM UTCkieranmAssigned toNone=>kieranm

    Back to the top


    Powered by Savane 3.1-cleanup1