kern/168190: pfil hook leaving ip_len in wrong byte order (ipfw?)

[Daniel Hartmeier]

During the investigation of the PR

  panic when using pf and route-to (maybe: bad fragment handling?)
  http://lists.freebsd.org/pipermail/freebsd-pf/2012-May/006577.html

we found that under some circumstances the ip_len in an mbuf ends up
in the wrong byte order, eventually triggering an m_copym panic,
variations of which were reported before (without resolution).

Adding a patch to assert the correct byte order in various places

  http://www.benzedrine.cx/fbsd-byteorder.diff

produced a panic in ipfw's pfil hook

  panic: ipfw_check_hook:281 ASSERT_HOST_BYTE_ORDER 45056 176
  ipfw_check_hook() at ipfw_check_hook+0x511
  pfil_run_hooks() at pfil_run_hooks+0xf1
  ip_output() at ip_output+0x6de
  ip_forward() at ip_forward+0x19e
  ip_input() at ip_input+0x680
  swi_net() at swi_net+0x15a

i.e. ip_len is in host byte order during pfil_run_hooks(), which calls
ipfw_check_hook(), where ip_len is converted to net byte order.

Then ipfw_chk() is called (no other rules but a default allow), and
back at the end of ipfw_check_hook(), ip_len is converted back to host
byte order.

But here the assert fails: after the conversion, ip_len is still in
net byte order!

I tried to find an explanation of how either ipfw_check_hook() or
ipfw_chk() could possibly swap the byte order another time in between
those two checks, but I couldn't find any.

May I please ask an ipfw developer to take a look and review the
analysis so far?

Joerg Pulz might be available for further questions or patches.

Thank you!

Daniel