lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #38210] ip reassembly while remove oldest datagram


From: Greg Renda
Subject: [lwip-devel] [bug #38210] ip reassembly while remove oldest datagram
Date: Fri, 28 Jun 2013 21:14:09 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:21.0) Gecko/20100101 Firefox/21.0

Follow-up Comment #1, bug #38210 (project lwip):

I've just run into this bug.  Here's what I think is going on. The problem
occurs when the reassdatagrams list contains IP_REASS_MAX_PBUFS (defaults to
10) datagrams and a new fragmented datagram arrives. If IP_REASS_FREE_OLDEST
is defined (which it is by default) the oldest datagram is attempted to be
freed by calling ip_reass_remove_oldest_datagram(). This function walks the
reassdatagrams list keeping oldest and prev pointers. The prev pointer is
bumped along at each iteration. The oldest pointer is set when the current
datagram does not match the incoming datagram and the current datagram is
older than the previous oldest (which, I believe, is always the case).
Normally, you run to the end of the list with oldest pointing to the last
entry and prev pointing to the previous entry. The bug happens when the last
entry does match the incoming datagram. In that case the oldest pointer does
not change but the prev pointer does, which ends up with oldest == prev. Then,
the oldest datagram is freed and the prev next pointer is updated to point to
the datagram's next pointer. But, since oldest == prev, this only messes with
the to-be-freed datagram and doesn't do anything to the true previous datagram
which will remain pointed to the newly freed datagram. Now the freed datagram
is re-allocated for the new, incoming datagram. You'll likely get the memory
that was just freed. The new datagram is then added to the start of the
reassdatagrams list. So now the last entry in the list points to the first
entry. Loop!

So, to reproduce the problem, send 10 datagrams with the fragment bit set but
with differing ids. Then send a single datagram with the fragment bit set with
the same id as the first datagram. I'll attach a script that does just this. 
I'll also attach a proposed fix.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?38210>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]