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.