[Top][All Lists]

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

[lwip-devel] [bug #24517] IP reassembly crashes on unaligned IP headers

From: Simon Goldschmidt
Subject: [lwip-devel] [bug #24517] IP reassembly crashes on unaligned IP headers
Date: Fri, 10 Oct 2008 14:22:01 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; de; rv: Gecko/2008092414 Firefox/3.0.3


                 Summary: IP reassembly crashes on unaligned IP headers
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: goldsimon
            Submitted on: Fr 10 Okt 2008 14:21:56 GMT
                Category: IPv4
                Severity: 4 - Important
              Item Group: Crash Error
                  Status: In Progress
                 Privacy: Public
             Assigned to: goldsimon
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 
            lwIP version: 1.3.0



I don't know if this is a duplicate for #23309. Since we have a detailed
error description here (thanks to Ed), this one is easy to solve.

Ed Sutter described it on lwip-users, here's the mail:

Ok, I've spoken to a few folks off-line about this, and have narrowed it
down a bit further.  There's either a bug or I'm not configuring something

I'm running LWIP 1.3.0 on a Blackfin, which is picky about accessing longs
on long-word boundaries.  I have MEM_ALIGNMENT set to 4.  My network
occasional fragmented IP packets, and it causes the function
ip_reass_chain_frag_into_datagram_and_validate() to crash.

Here's the flow...
The packet is received and buffered up using pbuf_alloc() (with each payload
aligned on a 4-byte boundary) then that set of pbufs is passed to
The ethernet_input() function then sees that it is IP, increments the
pointer by 14 (size of ethernet header) and passes the pbufs to ip_input().
Note that at this point, the payload pointer is no longer aligned on a
boundary because the original 4-byte-aligned payload pointer is incremented
by 14.

Next, ip_input() sees that the packet is a fragment, so it calls ip_reass()
which then calls ip_reass_chain_frag_into_datagram_and_validate().  About 15
lines from the top, this function overlays a "helper" structure pointer on
the payload area (which is no longer 4-byte aligned).  The helper
first member is a pointer which is initialized to NULL, this causes the
because loading the pointer is a 4-byte-wide access, but the pointer is not
a 4-byte aligned address.

This is only seen on an alignment-sensitive processor when an fragment is
received.  I made a simple change to the helper structure to fix this (see
below); however, I would like to make sure that there isn't some other
configuration parameter that I should be setting to avoid this.

I changed this...

    struct ip_reass_helper {
      struct pbuf *next_pbuf;    <<<< this member access is not aligned
      u16_t start;
      u16_t end;

to this...

    struct ip_reass_helper {
        PACK_STRUCT_FIELD(u16_t start);
        PACK_STRUCT_FIELD(struct pbuf *next_pbuf);    <<<< now it is
        PACK_STRUCT_FIELD(u16_t end);

and my crash has disappeared.  Putting the 'start' member above the
pointer will naturally align the pointer, which as far as I can tell will
always be mis-aligned by 2 bytes when MEM_ALIGNMENT is set to 4.

Is this a valid fix or am I just configuring something incorrectly to cause
this crash?

Sorry for the verbosity!


Reply to this item at:


  Nachricht geschickt von/durch Savannah

reply via email to

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